I'm using Express to build a web site. I'm serving static files and have a REST API. For the static files I'm using the session middleware to restrict certain pages to logged in users. The downside to this is that the REST API has cookies in the HTTP header. Can I restrict certain routes to not use cookies? Is this what the mount function is for?
Well, if you're setting or requiring cookies, you must be using some sort of middleware function to do so (since there's nothing in Express per se that would do it). If you wrote the middleware function yourself, you just need to rewrite it to be a little more picky about when to set/require cookies. If you're using a pre-written middleware function, try putting it later in the stack than any route functions that shouldn't be requiring cookies (this will generally mean putting app.use(express.router); ahead of any app.use(...) call that invokes a cookie-dependent middleware function).
If this doesn't make sense to you, please post what you're doing (after stripping it down to a minimal test case).
Related
What are the benefits of using Express with GraphQL? All the advantages of GraphQL can also be used with a simple Node.js application without Express. As GraphQL has only one endpoint and no middleware concept like in case of Express, why would we want to use Express and not just Node.js?
Express uses the Node.js http module under the hood but through middleware provides a way for you to implement various features for your endpoint. For example, to process POST requests (which you would need to do for GraphQL), you would need to parse the request body into a usable format -- if you don't utilize Express and a middleware like body-parser, you'd have to do this by hand. The same goes for other common functionality you're likely to need, like CORS, session management, etc. -- why reinvent the wheel when there's a middleware for it?
GraphQL itself might not have a concept of middleware (although there is a library that effectively does just that), Express's middleware still applies to your GraphQL endpoint as a whole. That means you can set up middleware that is ran before the GraphQL endpoint. Outside of features already described above, this also allots you the opportunity to implement authorization logic for your endpoint. For example, you could prevent access to the entire endpoint to users that fail to provide an appropriate custom header.
In reality, your app may need more than just your GraphQL endpoint. Authentication is commonly handled outside of GraphQL by exposing one or more additional endpoints -- this is particularly true if you implement an OAuth flow for your app. Likewise you may interface with third-party services that utilize webhooks, which would require you to expose additional endpoints on your server specifically for that purpose. The same often goes for health checks, like those used by load balancers.
I use an Express backend with the nuxt.render middleware to consolidate my API, front-end and development environment. So far, everything is going great, but I had some concerns about security concerning my auth setup.
My backend injects its user session into Vuex through a Nuxt middleware. While this works great for restricting access, the source code of those files is always available with a direct GET method. (e.g. if /admin is protected, /_nuxt/admin.js will still be available and will contain the entire source code of that page). Worst even, because of the default preload links put in the head by Nuxt, they will be automatically fetched, even if not logged in.
I understand that there are not a lot of security concerns with this because my admin API calls enforce the auth on the server side, but sometimes (as it is my case), exposing the source code is not desirable.
I have come up with a solution that works great, while being not very elegant:
In nuxt.config.js, I set render.resourceHints = false. I wish I didn't have to do this to benefit from the prefetching of available routes, but there seem to be no way to restrict the selection of prefetched routes.
Before plugging next.render into the Express' middleware chain, I selectively restrict the page's source code. (e.g. app.get('/_nuxt/pages/admin.js', restrict), where restrict is a middleware that returns a 401 if not authenticated, or calls next() if it is. That prevents both XHR fetching and direct GET.)
I make a custom error.vue template, where I catch the error message Nuxt will throw if forced to access a route that the user shouldn't have access to, which looks like Loading chunk 1 failed, and normalize it to a "Forbidden" error page.
Is there a more pragmatic way of doing this that I miss, or is that outside the scope of what Nuxt.js provides at the moment?
Ember Simple Auth provides a route mixin that lets you authenticate certain routes in your application.
I'm working an app where essentially every route (except the login route) is authenticated. Is is possible to specify this in a single option somewhere, instead of having to include the mixin in each route?
No, that's not possible. The best solution is to add an internal route and move all routes (except the login and index routes) under that route. From the index route's beforeModel you could transition to the internal route when the session is already authenticated.
How do I implement CSRF protection using built-in Express middleware for HTTP GET requests?
For instance, user logout often made via GET request and actually change state of web application so it should be protected against CSRF.
Unfortunately, CSRF middleware ignores HTTP GET and doesn't export helpers to manually check token.
BTW, they now expose the way of explicitly setting which methods to ignore
app.use(csurf({ignoreMethods: ['HEAD', 'OPTIONS']}))
You could create a custom fork of the Connect CSRF middleware that would not ignore GET requests. The line that does so is here: https://github.com/senchalabs/connect/blob/master/lib/middleware/csrf.js#L76
However, don't do it. GET requests are safe and idempotent: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
In other words, no one is worried that a malicious web script might log them out from a site. The worry is that it could post spam in your name or transfer money out of your bank account. That's what you need CSRF to protect against. Lots more info here: http://en.wikipedia.org/wiki/Csrf
I am writing some middleware for express.js 2.5.8. The intention is to amend the request object with additional attributes based on the session. I have unit tested the middleware function. Now, I would like to perform some lower-level integration testing to confirm that the middleware is being used by the express server.
My typical approach to this would be to spy on the middleware function. However, this is not the most effective way of proving that the middleware is working as intended.
What I would like to do (if possible/feasible) is load the application, inject arbitrary session data (it does not need to be valid), request/visit a test route which sends the result of the middleware. From there, I can make assertions on that result.
I have been using supertest (superagent), zombie, and request for testing, each with varying degrees of success. What I am struggling with currently is the injection of session data into the request, in whichever form it will end up taking.
I would appreciate some guidance. What approaches have people used when testing this type of behavior?
By making the assumption that express middleware handling is not broken: Why don't you try to write an injection middleware that is responsible to inject the desired session data and place the injection middleware before your middleware function you want to test?
With this approach you don't test client code directly but isolate the injection in your injection middleware.