I am building an app using expressjs, I want to use sessions where session data is stored in server-side and the cookie only contains the encrypted key to it. I seen a lot of examples that express does the same. But my problem is that they seem to use express.session where as Express docs doesn't specify any such middleware right now. It has cookieSession and I am not very sure as to what kind of sessions it provides.
I tried to search for the same, but could not find any suitable information, so this question. Please help me out.
If it only cookie-based encryption and holds all the data in the cookie only. Than I just wanted to know is it safe enough to be used. I know it can't be tempered and all. But still I get a feeling that the best option is the one I mentioned above.
If it the same as express session than I have one more question as to which session data-store should I use? I want it to be fast and also reliable(it doesn't get deleted). Basically my choice is between connect-redis and connect-mongo.
Please help me out.
I have found the answer why its not available in express docs because it comes from connect and its the same as connect.
Regarding the better option, I think its better option to store the data in server-side, though some might argue that its better to store client side for scalability...but you cant compromise security for scalability.
Related
We are using the Passport with express-session. when I develop features in my local, Server restarts which kills session every time I make changes to the code as I use nodemon. As a result, I have to login repetitively.
Here is my question:
Is there any way that I can config Passport to prevent logging in repetitively during development?
I'm thinking about:
(1) allow the session to survive during reloadings
(2) allow Passport to use cookie instead of cookie-session
(3) any other possible solutions will be appreciated
Yes you can. Just pick your favorite storage (you use the default memory storage, don't you?). The easiest way is to store sessions in a database (like MySQL or any other, maybe Redis) and with each restart all sessions will be stored safely in it.
You haven't provided any code in this question, but I am not going to be a stingy StackOverflow police officer and try to answer this as best as I can. I am expecting that you have sessions set up properly because you are not reporting any problems with data resetting when sending get requests to URL endpoints on your server.
You can actually set session data with the express session. Depending on what URL endpoint you would like to serve the data:
app.get('/url-endpoint', (req, res) => {
req.session.data-attribute = "data";
});
You can then serve this data however you like. I hope this answers your question. If this didn't answer your question, I would recommend editing the question and adding some code.
I'm learning Node.js, and I was wondering what is the best way to handle sessions.
It occurs to me that there are two main options: express-session, or cookie-session.
I did some research, and I've found that express-session is not the best way, since it stores all session information on the server, making it less scalable, but lots of tutorials were recommending it.
So, I am a little confused.
These two options are not comparable as they don't have the same functionality.
If you just want to set up a "volatile" session, with no need to store/verify any information server side, you can use cookie based session. This is just an improvement for the user experience (remember choices, preferences...)
On the other hand, if you need to keep some record about that user (authentication, history...), you will need to use a server side session, and a database. Any client side data (like cookie) could be modified by the user.
Note that the last option is not less scalable, it depends on the storage method, MemoryStore by default in express-session package, according to the documentation.
This package is powered by express team, so I guess it is robust enough for a production usage.
I'm tackling the design of my first API and am struggling somewhat with authorisation concepts - I was hoping some kind people could give me some advice!
What I'm building:
An API that will eventually be accessed by third party apps and a mobile app.
A web-based 'client' (first-party single page app) that will use the API. (Should this first-party app be 'a part' of the API, or a completely separate node app?)
Technology I plan to use:
Node
Express
Passport
Mongodb with Mongoose
I'm not wed to express or passport, they just seem like the best options and are well documented - bit I wouldn't want a potential solution to be dismissed because of alternative dependencies. Same with Mongoose, I actually prefer the look of Monk (or even just Mongojs), but every tut seems to use mongoose, so seems like the safest option for a node beginner.
Authenticating a user is simple enough (I've gone through the fantastic Beer Locker tutorial), what I'm struggling with is ongoing authorisation. Naturally I don't want the user to have to input a username and password with every request they make - should this information be stored locally and sent with every request? (if so, how? I can't find any info on handling an API with a session) or should I be working with tokens of some sort? The small amount of reading I did on 'Digest' authorisation (including the Beer Locker tutorial follow-up) made it seem like it had security issues, at least with the Passport implementation (this I don't fully understand, but seems to relate to hashing passwords, which passport doesn't do as standard, and only MD5 is supported even if it's added?).
I have built a working API that I can authorise with 'Basic' (directly, through Postman), so I have the foundations in place - authorisation works, I just need the tools to take that to the next step and add sessions into the mix!
I've been trying to get my head around this for a couple of days now, but I fear I'm too stuck in a more traditional local web-app workflow - the whole API thing is throwing me somewhat.
Any help is hugely appreciated, even if it's just pointing me at an appropriate tutorial - the above set of requirements must be quite common!
I have come accross this problem too...
I can only recommend doing this for the beginning:
http://scotch.io/tutorials/javascript/easy-node-authentication-setup-and-local
tell me if it helped :)
As I understand you have done the authentication and the only thing you have to do now is store somewhere that the current user is authenticated, his name, roles etc to use later with other requests. In the Passport you will do it in the function callback (instead of the "If this function gets called..." comment).
Now you have to decide, you have two options:
Store the user information (name, roles etc.) on your server (in a session) and give the user some long code which will identify his session for the next requests
to store the information on your server you may use for example the express-session middleware
it would be probably best to save the session identifier in a cookie, but read some security issues before
Give the user something that would prove to you he/she is authenticated and which name, roles etc. he/she has
you can generate a token, that contains the user information (name, roles etc.) that the user will send with every request. to know this token is legit, you will have to sign it. more on this is on jwt.io and you can use express-jwt middleware.
you dont have to care about storage of session with this one
the token can be placed to a cookie too, but same security issues apply. it is still considered better that localstorage (more here)
This is a question involving single page web apps and my question is in bold.
WARNING:
I'm hardly an expert on this subject and please correct me if I'm wrong in part of my understanding of how I think HTTP and WebSockets work.
My understanding of how HTTP restful APIs work is that they are stateless. We use tools like connect.session() to interject some type of state into our apps at a higher level. Since every single request is new, we need a way to re-identify ourself to the server, so we create a unique token that gets sent back and forth.
Connect's session middleware solves this for us in a pretty cool way. Drop it into your middleware stack and you have awesome-sauce sessions attached to each request for your entire application. Sprinkle in some handshaking and you can pass that session info to socket.io fairly easily, even more awesome. Use a RedisStore to hold the info to decouple it from your connect/express app and it's even more awesome. We're talking double rainbow awesome here.
So right now you could in theory have a single page application that doesn't depend on connect/sessions because you don't need more than 1 session (initial handshake) when it comes to dealing with websockets. socket.io already gives you easy access to this sessionId, problem solved.
Instead of this authentication work flow:
Get the email and password from a post request.
Query your DB of choice by email to get their password hash.
Compare the hashes.
Redirect to "OK!" or "NOPE!".
If OK, store the session info and let connect.session() handle the rest for the most part.
It now becomes:
Listen for a login event.
Get the email and password from the event callback.
Query your DB of choice by email and get their password hash.
Compare the hashes.
Emit an "OK!" or "NOPE!" event.
If OK, do some stuff I'm not going to think of right now but the same effect should be possible?
What else do we benefit from by using connect? Here's a list of what I commonly use:
logger for dev mode
favicon
bodyparser
static server
passport (an authentication library that depends on connect/express, similar to what everyauth offers)
The code that loads the initial single page app would handle setting up a static server and favicon. Something like passport might be more tricky to implement but certainly not impossible. Everything else that I listed doesn't matter, you could easily implement your own debug logger for websockets.
Right now is there really anything stopping us from having a single http based index.html file that encapsulates a websocket connection and doesn't depend on connect at all? Would socket.io really be able to make that type of application architecture work without setting up your own HTTP restful API if you wanted a single page app while offering cross brower support through its auto-magical fallbacks?
The only real downside at this point is caching results on the client right? Couldn't you incorporate local storage for that? I think creating indexable/crawlable content pages for search engines wouldn't be THAT big of a deal -- you would basically create a tool that creates static html files from your persistent database right?
Check out Derby and SocketStream.
I think what you're asking for is if it is plausible (using socket.io) to create a website that is a single static page with dynamically changing content.
The answer is "yes", it can work. Several node.js web frameworks already do this although I don't know of any that use socket.io.
Is a user able to edit localstorage (and sessionstorage) items? Specifically, would a malicious user be able to edit it like cookies can be edited?
I am researching session info for a web application I am writing, and I had the idea of using localstorage for some items. Yes, I have looked into session variables, and I am probably going to use them, but I was just wondering this and could not find it anywhere. My project is built with jQuery and PHP. The interface is completely driven by jQuery, and I am using localstorage for some other info--that is why I thought of it.
Thanks!
Yes he can, actually you should always assume that anything that is done on client side
can be altered, of course JavaScript as well.
If you want to make sure that something is not altered you can use some kind of cryptographic
signature on data and validate it on server side.