Node.js/Express Routing to a static file URL - file

I don't have a problem as such as I have a work-around. However the process of understanding and developing the work-around has highlighted what seems to me a fundamental gap in my knowledge (as a self-taught programmer, this happens a lot ;-) !) and I can't seem to find the answer to plug it anywhere.
Standard node.js/express setup with for example:
app.get('/index.htm', function (request, response) {
console.log("/index.htm");
});
app.get('*', function (request, response) {
console.log("*");
});
Why when the user connects directly to index.htm (by typing in the URL although I've not tried clicking on a link) does nothing fire ? The page is served no problem. The obvious use-case for this is to check if the user is authenticated prior to serving the static page.
FYI the workaround is to pass the user to a route such as "/authenticated" (which matches fine), do the check and then redirect and basically block everything else.
Thanks for educating me in advance ;-)
N
UPDATE to Raynos' question - yes (ignore the server/app variable name discrepancy).
// CREATE SERVER
var server = express.createServer();
server.configure(function() {
server.use(express.static(__dirname + '/public'));
server.use(express.logger());
server.use(express.errorHandler({dumpExceptions: true, showStack: true}));
// start of session stuff
server.use(express.cookieParser());
server.use(express.session({store: sessionStore, secret: 'secret', key: 'express.sid'}));
});
I've now found that the routing matches fine once you delete the static file i.e. in the original example, deleting index.htm means that the console will now log "/index.htm".
N

Just to bring some closure to this question:
Express static handler if it finds the file it will serve it and it won't let the other handlers to be called. If you remove it, then app.get('/index.htm' handler will be called. If you want to have a callback on all URLs just add server.use(function(req, res, next) {...}) before everything and that function will be called on all routers, make sure you call next if you want other middlewares or route handlers to be called.

Related

Request Deferrer with Service Worker in PWA

I am making a PWA where users can answer the forms. I want it to make also offline, so when a user fills out a form and does not have the internet connection, the reply will be uploaded when he is back online. For this, I want to catch the requests and send them when online. I wanted to base it on the following tutorial:
https://serviceworke.rs/request-deferrer_service-worker_doc.html
I have managed to implement the localStorage and ServiceWorker, but it seems the post messages are not caught correctly.
Here is the core function:
function tryOrFallback(fakeResponse) {
// Return a handler that...
return function(req, res) {
// If offline, enqueue and answer with the fake response.
if (!navigator.onLine) {
console.log('No network availability, enqueuing');
return;
// return enqueue(req).then(function() {
// // As the fake response will be reused but Response objects
// // are one use only, we need to clone it each time we use it.
// return fakeResponse.clone();
// });
}
console.log("LET'S FLUSH");
// If online, flush the queue and answer from network.
console.log('Network available! Flushing queue.');
return flushQueue().then(function() {
return fetch(req);
});
};
}
I use it with:
worker.post("mypath/add", tryOrFallback(new Response(null, {
status: 212,
body: JSON.stringify({
message: "HELLO"
}),
})));
The path is correct. It detects when the actual post event happens. However, I can't access the actual request (the one displayed in try or fallback "req" is basically empty) and the response, when displayed, has the custom status, but does not contain the message (the body is empty). So somehow I can detect when the POST is happening, but I can't get the actual message.
How to fix it?
Thank you in advance,
Grzegorz
Regarding your sample code, the way you're constructing your new Response is incorrect; you're supplying null for the response body. If you change it to the following, you're more likely to see what you're expecting:
new Response(JSON.stringify({message: "HELLO"}), {
status: 212,
});
But, for the use case you describe, I think the best solution would be to use the Background Sync API inside of your service worker. It will automatically take care of retrying your failed POST periodically.
Background Sync is currently only available in Chrome, so if you're concerned about that, or if you would prefer not to write all the code for it by hand, you could use the background sync library provided as part of the Workbox project. It will automatically fall back to explicit retries whenever the real Background Sync API isn't available.

Difference between app.use and app.get *in proxying*

I'm hoping to better understand the difference between express's app.get() and app.use().
I understand that app.use applies to all HTTP verbs.
I have also read that "app.use() adds middleware rather than a route"
I'd like to understand why this fact causes this behaviour...
I have an express API server that needs to proxy a React development web server.
This means that all routes that are not API routes have to be proxied.
When I proxy the routes like this, it works:
var proxy = require('express-http-proxy');
module.exports = function set_react_catchall_routes(app) {
/* Final route to send anything else to react server. */
app.get('*', proxy('localhost:3000'));
app.post('*', proxy('localhost:3000'));
}
But when I do this it does not work:
app.use('*', proxy('localhost:3000'));
Specifically, the "index" page is proxied and served up, with content like this:
<body>
<div id="root"></div>
<script type="text/javascript" src="/static/js/bundle.js"></script>
</body>
and the client requests the javascript react bundle, but then "nothing happens".
I'm reasonably sure that there aren't "other" HTTP requests involved when it does work (other than GET and POST) because none are logged.
So what would be the difference?
Try putting this logging at the top, it should help to clarify what's going on:
app.use(function(req, res, next) {
// req.path will be '/static/js/bundle.js'
console.log('path1: ' + req.path);
next();
});
app.use('*', function(req, res, next) {
// req.path will be '/'
console.log('path2: ' + req.path);
next();
});
app.all('*', function(req, res, next) {
// req.path will be '/static/js/bundle.js'
console.log('path3: ' + req.path);
next();
});
When you use app.use it will strip off the matching section of req.path. If you don't specify a path (logging section 1) it won't strip anything off. Similarly section 3 is using app.all (app.get, etc. all work the same way) which doesn't change req.path either. It's section 2 that's the kicker.
To understand why this happens consider this example:
var router = express.Router();
router.get('/profile', ...);
app.use('/user', router);
When a request comes in for /user/profile the app.use will strip off the /user part of the path. As far as router is concerned the path is just /profile.
To quote the docs, http://expressjs.com/en/4x/api.html#req.path
When called from a middleware, the mount point is not included in req.path.
The path for a call to app.use is a bit like a 'starts with' and anything that matches is thrown away. For * that matches everything so it throws away everything.
If you take a quick dive into the source code for express-http-proxy you'll see that it uses req.path to determine the path of the proxy request. If you just use app.use without a path it should work fine.
There are some other request properties that are similarly relevant to understanding app.use:
req.url is similar to req.path but with the query string included. Just like req.path it will have the section matching the mountpath removed by app.use. Note that the Express Request inherits the url property from Node's http.IncomingMessage so it isn't explicitly listed in the Express documentation.
req.originalUrl starts off the same as req.url but it will not be changed by app.use.
req.baseUrl is used to store the section of the path that has been removed by app.use.
See the documentation for req.originalUrl for more details on all three of these properties.

Spring + Angular / IE gets 403 on PUT (others don't)

I have a spring webapp with spring security(3.2.3, so no CSRF protection) and angular.
In a controller i have a method like this one to update the users pw:
#RequestMapping("/accountinfo/password", method = arrayOf(RequestMethod.PUT))
#ResponseBody
#Secured("ROLE_USER")
open fun updateOwnPassword(user: User, #RequestBody password: String) {
val editedUser = user
editedUser.password = encoder.encode(password)
userRepository.save(editedUser)
}
The request is done via angular Service:
function changeOwnPassword(newPassword) {
return $http
.put('accountinfo/password', newPassword)
.then(function (response) {
return response.data
});
}
This works fine in every browser i tested with. Except if using IE 11.0.35 in a Citrix environment (Works outside of it,but can't see any specific configuration).
In that case i get 403 on the Request. When i change the method to POST it works fine again. I could do that for every function where i got this problem of course, but that doesn't seem like a clean solution.
As far as my research goes, i think it's something wrong with the way the browser writes the Request, but that's were i can't find out what to do.
EDIT:
I compared the request headers of both IE 11.0.35 inside and outside of Citrix and they seem exactly the same. The only difference is that the working version uses DNT=1 and the non-working version as WOW64 in the User-Agent attributes?
UPDATE:
I found out that it happens with DELETE too
Found the problem: The client sends the Requests through an additional Proxy that doesn't like PUT and DELETE and just cuts the session cookies off of it. We are adressing that problem with putting the tokens in the header in the future.

location.path() not redirecting to page

In node this is how I define my details route (render as jade and send).
app.get('/details', function(req, res){
jade.renderFile('details.jade', function(err, html){
if(err){
console.log(err);
}
res.send(html);
});
});
In jade with 'blah' is clicked then calls navigateToPath function with params.
a(ng-click="navigateToPath(date_obj_key, part)") blah
In angular, this function should go to this path. The url path changes in the browser but it does not REDIRECT to the page. Help (yes I am injecting the location service)
$scope.navigateToPath = function(date, part){
var path = '/details?date='+date+'&part_type='+part;
$location.path('/details').replace(); //also tried $location.url(path)
$scope.apply(); //also tried $scope.$apply and $rootScope.$apply as func
console.log($location.path());
}
I am using Fire Fox developer tools(F12) and put a break point on where I used $window.location in my project and looked at the values in $window.location and this what it shows:
It seems like this would work. for both a location in the same folder or sub-folder as well as going to a completely different web site.
$window.location = $window.location.origin + path
or
$window.location = <whatever website you want to go to>
In my case I was just using the $window.location to call a rest service to download a file that the user selected from a ui-grid while still staying on the same page. and this may have worked for me because my scenario is a bit different then what yours is I think. so all I had to do was
$window.location = "../../services" + "<path to my rest service>" + $scope.shortCode + "/" + $scope.wireInstSelectedRow.entity.fileName;
#shapiro I am not sure why this does not work
$location.path('/details').replace();
I tried the same thing originally in my project and based on the documentation: https://docs.angularjs.org/api/ng/service/$location It seems like that would work and what its supposed to be used for but what I noticed is it would put a '#' character in the url before it put the path I wanted it to take which was preventing it from going to that page. Anyhow for me it seems like as long as you are going to an html page that is in the same folder or sub-folder just doing
$window.location = <the path you want to go to>;
is a good solution... at least it did the trick for me. Hope this helps.

Laravel RESTful returning 301 state

Mates,
I'm developing a Backbone/Laravel application.
When I try to send a POST request to a certain resource, it returns me 301 status with no response, regardless that on the controller i'm printing a 'hello world', to check if it's getting to that point.
Here's some code...
public function store()
{
//
return 'hello world';
}
This is the routes.php
Route::group(array('before' => 'auth'), function()
{
Route::get('/', 'SitesController#index');
Route::resource('rooms', 'RoomsController');
});
So, when I make a POST request to
rooms
With some info to save, it gives me back 301 status with no response at all.
Any idea what am I doing wrong?
Thanks in advance!
Solved!
On backbone collection configuration, I had url parameter with '/' at the end.
rooms/
Deleted that slash and now it works fine.
Hope someone find's this helpful
(Adding this answer in case anyone has the same issue as me)
In my case I had a resource videos which gave the exact same problem. The reason was that I also had a directory on the server /videos/ (with files in it) which the server tried to point me to before it let Laravel direct it to the controller.
For some reason, posting to "image" in Laravel, even without a trailing "/" gives me a 301 Moved Permanently HTTP response.
I don't have an "image" folder in my public directory and still don't understand why the redirect occurs.
Changing the request to "foo" seems to work fine.
So if you found this page because you're trying to store an image restfully, try something like this:
Route::resource('api/image', 'ImageController');

Resources