Note that there are some explanatory texts on larger screens.

plurals
  1. PONode js - user auth, what to store in session?
    primarykey
    data
    text
    <p>First of all, I did not find any similar questions or material that will be useful. I'm sorry if I missed something!</p> <p>Second of all, I'm not interested in ready solutions like <a href="http://passportjs.org/" rel="nofollow">node-passport</a> or <a href="https://github.com/ciaranj/connect-auth" rel="nofollow">connect-auth</a> or <a href="https://github.com/bnoguchi/everyauth" rel="nofollow">everyauth</a></p> <p>Now to the question. I'm using Redis to store the express session. My question is, when user is authenticating (i.e. after a post of username &amp; password was made and such user was found in the collection) what should I store in the session?</p> <ol> <li><p>I can store the whole user object (for example, the way it came from MongoDB). One disadvantage that I see, is that when user is being modified in the DB (he edited his profile), Ill have to "re-set" the user object in session. It gets even more complex if for example the user's profile is changed by administrator - in that case the session have no idea that the user was modified and its data needs to be refreshed from the DB hence the sessions is currently holding outdated user object that will be updated only the next time the user logs in.</p></li> <li><p>Create a collection of "hash => userid" and store in session only the hash. Then every request, call a middleware that will check (pseudo code below, omitted the check for non existing hash, in that case user might be considered as not logged in since the session expired):</p> <p>if(userhash in req.session) res.local.user = db.users.findById(db.sessions.findUserIdByHash(req.session.userhash));</p> <p>Well the obvious disadvantage of this method, is the additional collection (i.e. mongodb) or key => value (i.e. redis) storage for hash => userid which also requires some procedure to clean old session hashes (scheduled task\cron that will run and delete old expired hashes).</p></li> <li><p>Another solution similar to #2, instead of using 3-d party collection/key=>value storage, store the hash as part User object in MongoDB. This method however eliminates the extra collection/redis key value, but still required a scheduled task to clean old, expired sessions. And since expired session will probably be defined by "expire date" attribute, its easier to maintain 3-d party collection for active session, instead of putting session related data into User object in MongoDB (thus making the User object huge). </p></li> </ol> <p>I'm new to Node-js this why I ask. I also understand that there might be no correct answer, and or it might be bounded to personal preferences.</p> <p>Thank you!</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COA few questions for you... **1** What's the cost of inconsistency in your app? **2** How many users are you projecting and what hardware resources do you have? **3** What's the usage pattern? i.e. sparse but intense sessions, sporadic daily visits, etc. **4** Fresh code has a cost & risk, what makes you want to use your own solution rather than a module that's more mature?
      singulars
    2. CO@Richard Marr **1** What do you mean by inconsistency of the app? **2** The project is in early development stage, about users I can't tell you (the more - the better), lets say about 1k a day, about hardware - any modern hardware like amazon/heroku/nodejitsu. **3** I'd say sporadic daily visits. **4** **a)** ability to gain skills in nodejs **b)** I don't need most of the functionality 3d party modules offer like social networks login/oauth **c)** easier to integrate own solution than using 3d party module
      singulars
    3. COAs @josh3736 points out, this is really a question of what should go in a session, rather than being specific to Node. However, making architectural decisions based on what skills you'd like to learn is a bad approach. Learning an existing module may appear harder than writing your own, but every line of code you write is one that you have to maintain. It's a common reaction (and I've done it myself), but it's a mistake. The best advice I can offer is to use a mature module. If you feel like they're no good once you're more familiar then please do write your own, I'd love to see it.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload