Node.js express login cookie and URL - node.js

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.

Related

Where is google api auth data being stored in node?

So if I use the node he client how is auth information being passed around ?
In the photo frame example it checks form data using the express body parser for a user and is authenticated function call.
But then it also calls api functions and makes requests outside the browser.
Just curious what the process is storing and where and how it’s being passed around.
Obviously the application tells Google what it is with some use of the client ids but is there a token the application has access to as well once OAuth is finished identifying the specific user account and where is that ? And how does the connecting browser keep this between server calls ? The response headers seem empty of anything of that nature. Thanks in advance.

pass node express session to phantomjs open

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.

How do I tell the client they gave the wrong password?

I have a node.js web app, and I'm working on getting the user logged in and authenticated. I'm using pug to template things, mysql, and express.js.
I use bcrypt for hashing the password, and that's all working right. My problem lies with what to do when the password is incorrect, and how to tell that to the client, as the checking happens on the server.
Initially I was using socket.io, but I moved away from that. Then, I used a redirect to /login?error=true. Now that I'm using pug templating, it can't find the view. One solution would be to simply redirect to a whole new page, /loginfailure, but I feel like I should be able to accomplish this without redirects.
I see res.json(), but when I use that, the client side renders it and I end up with a blank page that's just the json that I sent. Is there a way to send json so I can do something with the json data client side, rather than have it just render the data?
What's the best way to send data from the server to the client, preferably not as a redirect?
I'm looking into AJAX now, and that seems like it has potential. The issue I'm having is that if I use res.send or res.json it still renders the data, rather than passing it to the callback of the ajax call. Suggestions?
Typically in express, and in whatever file you have your routes, you can implement an auth service to make sure that they are logged in to even see the rest of your api. Usually I'll give tokens to users, once they've been authenticated then I would let them see the rest. You can also use a service like ui-router and create states for your app, and if they don't have correct login credentials typically they would stay at the home page which would be the redirect. You could also alert them with a modal or something saying invalid email/password.

Node.js unit testing for session-specific middleware

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.

Are POST variables from an HTTPS POST logged by IIS?

I am investigating the best way to go about securing a webservice call for authenticating users. I have found several usefull posts already on stackoverflow which send me into the right direction. But as I am working for a client with limited resources, the solution should not become a two-month project.
The plan is to use a webservice method that only accepts POST requests using HTTPS. The variables (username and password) will be passed with the formcollection.
How secure would this be? I don't want these variables to appear in any logfiles.
By default, POST variables will not be logged in IIS logs. You could always add server-side code to access the variables and log them in such a manner, but the webserver will not log them by default.

Resources