I am using COUCHDB built in Session API in my application. I now want to renew the session as every user logs in, also i do not want to give a long expiry time to the session.
I don't really understand your question. It doesn't make sense that you want to "renew the session as every user logs in".
The whole idea of a session is that it's a per-user-login session. Each user who logs in should trigger a POST /_session request to your CouchDB server, that will respond with an AuthSession cookie which is then what you send back in subsequent requests and that's your session cookie.
The next user who logs in should generate another POST /_session which will create a new session cookie for that user. So there's no renewal as every user logs in.
Now, the expiry on the session is set by the timeout setting in the [couch_httpd_auth] and defaults to 10 minutes. If you want it shorter than that then adjust that setting in your local.ini
So, finally, if you ever want to explicitly remove the session, eg. from a "logout" button, then you do that by sending a DELETE /_session request.
Related
An Oauth2 client application generated by Jhipster has a behaviour issue after some idle time. After a signed-in user has some idle time on the application, interaction with the application will lead to an undesired behavior such as a data isn't fetched from the database.
I have learned that user session data is stored in a form of a cookie on the front end. For the Vue front-end, searching
this.$cookie.set(
yields no result.
I do see JSESSIONID in a request header after a user signs into the application. So, I assume that the session id also is stored somewhere on the server. For every REST request, the server would verify the session id in the request header by comparing it with the session id on the server. When the session is time out, the server no longer has the session id. Any REST request from the point will lead to undesired behaviour in the current implementation. A filter is needed to verify a REST request session id with the server.
I have a look at the code in the security package as well as the security configuration. But, I don't see any code dealing with a user session.
How does the server work in this regard?
Update:
To deal with an invalid user session for a sign-in, I notice that the ExceptionHandlerExceptionResolver will handle the InsufficientAuthenticationException after refreshing a browser. Otherwise, the exception won't be handled. How to resolve this issue?
I'm using node/express.js with cookie-session in my application.
Currently, when a user logs in a cookie is stored in their browser with a value, for example: session: ABC123. If the user logs out, the cookie is deleted. When the user logs back in, the same cookie and value are stored in the browser session: ABC123.
I am getting the same session user_sid whenever i login.
i want to randomize the session user_sid every time the user logs in.
There is no notion of a session id with the cookie-session package.
In the typical scenario where the session data is stored on the server, a session id is generated that maps to a given user session data. This is this session id that is kept in the session cookie.
With the cookie-session package however, the session data itself is stored in the cookie - as opposed to on the server -, so there is no need for such a mapping or a session id at all. So in effect and unless the session data is actually updated from one session to another, the session cookie will be the same.
You want to call session.regenerate() when the user successfully login, that will do what you want and also address session fixation attack
I am using passport,passport-local in nodejs to authenticate user.By default passport allow multiple session per user.But I want to implement single session per user.How can I do that?
As far I know session will be alive forever until the user logs out. The logic can be used like you can save a login status logged_in in DB and check every time when the user try to login. If you get the status logged_in as true then you can deny that user to login.
I'm working in a cookie-less way to manage sessions in my project (expressjs), keeping all session data server side and using a token at client side (previously generated by the server) to validate the session on every request.
A new token will be created on user login and kept hide somewhere in the page, then, on every request this token will be written to the request header and validated server side. at this point server will search for the token in a session store, lets say redis, and get the session data if the token is found or respond with a message of session expired otherwise.
There are some things i'm considering for this:
Redis keys are created on user login with a settled expiration.
Every time session data is found in redis i have to 'touch' the key
so expiration time gets postponed.
Token will be validated along side with the ip address of the client so can't be used by other person.
My question is if this is can be considered a secure way to work with, and if there is anything i'm missing here. Thanks
OK, cookies are required for storing session. Express does it the ideal way.
In express session(not cookiesession) it is completely stored at the server, only a key is sent to the client. The whole session is serialized to a key which is then sent. I assume you want that user cannot tamper with the session cookies. You can use httponly cookies to prevent tampering. They are only handled by browser and cannot be accessed by user. This prevents cookie theft or session hijacking. You can enable httponly cookies with:
app.use(express.session({cookie: { path: '/', httpOnly: true}, secret:'password'}));
Still you should use some encryption to prevent eavesdropping of cookies. Use secure : true for that. You can also mention where you want to store the session with redis, mongo or simply in memory.
The request token validation that you mention is a technique commonly used to prevent Cross-site request forgery. It keeps changing the token dynamically to keep user from getting the token. You can use this in express with csrf middleware.
app.use(express.csrf())
IP matching will not work as IP of user can change over time.
When a user logs in, I give them a cookie named auth with a value that is a GUID, which expires in 2 weeks. I save the hashed GUID in the database with a salt of their userID and then date when it expires. When a user accesses the site, I check for the cookie and log them in if it matches and hasn't expired in the database.
At some point before the 2 weeks is up I was thinking about updating the row and increasing the expire date.How often do you do this? Every page request seems too often since I will be constantly writing to the user table.
I was also considering changing the auth cookie value at this time. The downside of this is you cannot be authenticated at multiple computers / browsers.
I could accomplish this via a session cookie, so that it this rewrite only happens once per session. When a user accesses a page, I check for a session cookie named authenticated. If it's not there, I give them a new auth cookie value and authentication session cookie and bump the expiry times in the DB and auth cookie. If it is, I just validate off of the auth cookie.
It seems like StackOverflow never changes their auth cookie until you log out and log back in. This seems to make it more vulnerable to session hijacking- if you get the auth cookie, you have access to the users account until they log in again. Since their auth cookie won't expire or change the user will not be logged out by you logging in.
Do you allow a user to log in from multiple locations/browers?
If not, how often do you change their authentication tokens?
It depends on the level of security, places where I have worked it normally has to be kinda high.
No we do not allow people to log in from multiple browsers.
We make people login again after 20 minutes of inactivity. Depending on how accurate you want to be on timing the person out determines how often you want to update the token. I've been places where it the expiration time is updated everytime the user sends a post back to the system.
Hrm I found all of my answers here. Looks like I need a join table >.<.
http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/