My app has a route /project/:id which is protected by an auth middleware that uses passport to allow visitors to authenticate with their slack account.
I'd like to use phantomJS to render /project/:id to pdf. I thought the best way to do this would be to create a route /print/:id (same auth middleware) which creates a phantom instance and uses the open method to request /project/:id.
When /print/:id is requested, the browser session is detected as normal, that's fine. But when phantom does the internal request, it's session is not authorised. The best option would appear to be copying the browser session onto the phantom session.
I note that phantom's open method allows a settings parameter, but I have no idea what properties on the request object would need to be passed in to that settings parameter.
I note there's a similar question regarding cookies but there's no clear solution there and if I understand correctly, recreating the cookie might be more appropriate for accessing a third party, when you don't have access to the session itself.
I infer from the question that you are the developer of the application and have PhantomJS on the same server as this project.
If that's true, the simplest and very reliable solution would be to check if a request for /project/:id was local plus if useragent is PhantomJS's and disable auth middleware that time.
Related
I'm using express-session to initialize a session and save the cookie. But the process of how the cookie is saved browser side is abstracted away and something of a black box to me, it just happens automatically. Can anyone point to a resource that explains how the client takes the cookie from the response and saves it in local storage? My front facing stack is composed of react, nextjs and urql client.
When you use express-session to initialize a session and save the cookie on the server, the client automatically receives the cookie in the response from the server and saves it in the local storage. This happens because the browser automatically includes the cookie in the request headers for any subsequent requests to the same domain, and the server uses the cookie to identify the user's session.
The process of how the cookie is saved in the local storage and included in the request headers is part of the underlying mechanics of the HTTP protocol and is handled automatically by the browser. It is not something that you need to worry about or configure when using express-session.
If you want to learn more about how cookies work in general, you can check out the following resources:
The official documentation for cookies on the Mozilla Developer
Network: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
A tutorial on cookies from the W3Schools website:
https://www.w3schools.com/js/js_cookies.asp
Im beginner in login system, i use session for it. I have implemented the login system with session checking, but only for GET Request because it can be accessed directly in browser address bar so i cannot be accessed directly in address bar before login.
My question is, is necessary to implement the session checking in POST Request too? Or just implement it into GET Request that can be accessed in address bar directly?
It is not necessary. id depend on the use case. If your frontend is different is in some other language like react, angular etc... then it will be directly handle by the state/browser storage.
Still if you need to implement through node side then express-session is a good option to choose. You can use the JWT token for calling the api through the request. On logout case just expire the tokens
I am quite new to Node.js and I have two problems I cannot seem to be able to solve nor find any solutions on the internet.
If I want to create a login function (I have everything setup already except the cookies part) I have to somehow get the servers response, set a cookie and send it (express).
Now I'm wondering how should I get into this to use the variable in the login function?
The login function accepts callback, request, response as parameters. I wanted to return a callback whether the cookie is set after setting it. But the problem occurs when I want to set the cookie. I have to use response.send() which results in an infinite loop.
Is it possible to visit for example localhost/mywebsite and still get the server to work instead of
localhost:8080? (8080 is port I'm listening to, as an example)
This is a wonderful guide on setting up authentication in Express using a tried-and-true authentication library called Passport. And here is a second guide using an enterprise-grade (there's a free version) library from Auth0 and it has a lot more features regarding identity.
Update
So once the user logs in, you could send a cookie like this: res.cookie(cookieObject).send(responseObject) - more on this here. It would then be the browser/client-side framework's responsibility to return the cookie with every request. You could use the cookieparser package from NPM to help parse cookies from the req object. Let us know if this helps.
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'm writing a unit test for a middleware that relies on persistent sessions in connect. (namely connect-mongo).
I'd like to create a fake session, but can't seem to figure out how.
I have a connect.sid cookie in my browser that I assume correlates to the _id in my sessions collection in some encrypted manner.
Here's what I tried:
I added in the cookieParser middleware and a session store to a server, then used the following request to send it up to the server (copied the key from chrome's dev tools panel):
var jar = request.jar(),
cookie = request.cookie('connect.sid=<REALLYLONGKEY>');
jar.add(cookie);
request({url : 'http://localhost:8585/',jar : jar},this.callback);
that correctly set the cookie on the server side, and I have verified that sessions are working.
However, the magic conversion from cookie to session didn't happen as I had hoped - what's the correct way to do this?
Setting the cookie on the server would only work if a session with that ID exists. Who created the session in the first place?
I can tell you what I did on my server. I wanted to create tests that simulate the client side and send requests to the server. I needed a way to authenticate the clients. My server allowed authentication based on Google OAuth. However, I did not want to go through the trouble of teaching the clients to sign into a Google account.
My solution was to implement an alternative method for signing in to my server - using nothing but a username. This feature is only enabled during testing and disabled for production. My test clients can now sign in without a problem. They receive the cookie 'connect.sid' as a result of the sign-in and send it back to the server in subsequent requests.
I too used request.jar() to create a cookie jar for my requests. I should note, however, that this is only necessary if you are simulating more than one client at the same time and need a separate cookie jar for each client.