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.
Related
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.
we are in the process of building a new app in node.js with express that connects to our parse server backend. We have built native apps that already connect to our backend on iOS, Android and PHP. All of them have the ability to log in the user and store the session data securely.
I'ts my understanding that node.js doesn't really store sessions like for example in PHP you can store them as a file on the server or to memcache or redis and test against parse->currentUser() to check if its valid.
How does one do this with node.js? We cant store any session data in a cookie since thats not secure.
Is using express-sessions and redis a good way to handle this?
I'ts my understanding that node.js doesn't really store sessions like for example in PHP...
That's not a totally accurate understanding... it's more that Node.js doesn't really know or care how you handle your sessions. That's where frameworks like Express, and their modules express-session, come into play.
Is using express-sessions and redis a good way to handle this?
If you're using Express, yes. And, with that, you can use whatever session store you want, including Redis, Memcached, files, just like you're used to with PHP.
An approach that I've used in the past is to store your session ID in a cookie, but none of the session content. That will allow you to reconnect with a prior session, as long as it's still valid. You can also use LocalStorage if you want something a little more persistent than SessionStorage. If you want something really persistent, you can manually save your session data to your database, and have the user request it if their browser data has been cleared.
I am currently developing a node.js webapp, which can access a subversion server with a nice web UI.
To access the server I need authentication data. My first attempt was to store them with app.set('username', 'theo')and app.set('password', 'start'). Later I saw, that this is a very bad idea, because then, the authdata are going to be in the app settings until it restarts.
My question is now, how can I store data during a session over multiple requests using nodejs and express?
PS: A database is sadly no option...
Ok, I just oversaw it. The express module express-session was what I needed :)
This is my code now:
var session = require('express-session')
app.use(session({ secret: 'supersecret' }))
And when I need the session I jsut go with
req.session.username = 'theo'
Just if anybody has the same trouble like me :)
You may use "mamcached" for store your session information using nodejs. Thorough this you may help in integration with any web server session also.
You can also use REDIS to store the sessions, even if the express falls you will still have the sessions on REDIS and the users won't have to authenticate again.
You can also use redis for nodejs and predis package for php redis. It is very easy for you.
All the best..!!!
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.
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.