Really weird authentication problem going on - hope someone can help!
The Domino Web Server Log database shows all the requests a particular user is making for pages in an application I look after. The application is XPages-based and the user is regularly pressing Save on the document she is editing (every few minutes). The save does a full update.
The LTPA token is valid for 30 minutes - I assume however that every time the user performs a full update, the 30 minute token is renewed?
However, when looking at the logs, a save of the document at 09:05 shows the Remote User by name, another save at 09:07 still shows the user by name. The next save at 09:11 shows the remote user by IP address instead, and when you look at the log entry in more detail, the server has replied with 401 UNAUTHORIZED (The client is not authorized to access data). This has of course caused the user's browser to lose the work they had open at the time.
The Cookie on each log entry shows :
LtpaToken=AAECAzUwOUI2RjRCNTA5Qjc2NTNDTj1Bbm5lIExhdm91ZS9PVT1VSy9PPVJVSyvsCs5c4tITD9elgI0BCN5CnZ0O; SessionID=DBDFDKDGTI
The same LTPA Token and session ID for entries where the save document worked, as well as where it failed.
Unsurprisingly, they have then refreshed the session by closing the web page and going back in to it following the error and they get a new LTPA token and session ID.
The LTPA Token validity setting of 30 minutes I refer to is defined by our admins in a Web SSO Configuration document for the server, in the "Server\Internet Sites" view in the NAB. It's the Token Expirations (Minutes) setting. Am I completely misunderstanding this setting - should the timeout be renewed everytime the user does a full submit to the server? Or is something else going on here?
I don't think the token is renewed. It times out no matter if the user is active or not.
You could increase the expiration timeout to a reasonable high value and then add a lower minimum timeout to ensure that sessions doesn't timeout too soon.
Here's an example where expiration is set very high and timeout is set to 2 hours:
Related
I'm developing a new web app with NodeJS and ReactJS and I'm using JWT for authentication. The client side sends a request to /login using axios.post(), the server checks the data entered by the user and returns an access token with an expiration time of 5 minutes and a refresh token. I use Redux to save tokens at the app level state. On next requests, the client side sends back the token to the server.
My questions are:
1) Is there a way to open multiple tabs and recover the state of the first tab opened and when the user logs out of a tab, he is logged out of all tabs? (Facebook uses this method)
2) Imagine I connect to the website at a friend's place and when I leave I forget to disconnect, is there a way to disconnect from all the devices when I get home? (Facebook uses that too)
3) Is it possible to automatically delete the tokens in the app level state after X seconds / minutes only when tabs are closed and continuously refresh the access token otherwise?
Thank you in advance
No answer to your post after 9 days. Too bad, let me help you out.
To get the closest representation of what you want i would use a SameSite Cookie.
They're always on all Tabs and you can also expire them after a period of time.
Cookie will get deleted and you'll be logged out.
In order to work with devices you can use a blacklist on your refresh tokens, although this is against the principles of JWT it is still a possibility.
SameSite Cookies spread over all tabs
The Cookie can be send with all requests in the header (use strict mode)
Deleting the Cookie results in a logout
Blacklisting the Refreshtoken JWT will result in a logout of the user aswell.
Would recommend you to read about the SameSite cookie (strict). You'll be surprised because there's not alot of people who know about it.
If i can be of any help feel free to contact me through DM.
Wondering how this is typically implemented. Examples of always logged in websites are StackOverflow, Facebook, and Twitter. It seems like you'd have to have a background job regenerating the session ID (assuming you store session by ID in a database) before the session expires (say you tell the cookie to expire in 5 minutes). So every 5 minutes every session would be regenerated to keep it logged in while also keeping it secure. But before going down that road I'd like to know if this is how others implement it or if there is a more standard approach.
As far as I know, this is how it is done in majority of websites.
A cookie is set with an access token and limited life(of course, if the user checks on'Keep me logged in'). If the user comes to visit the site within that timespan, he is logged in and a current session is generated(from the server). And, the cookie timespan is reinitialized to the pre-decided time.
Say for example: I log in to a website example.com and check its check box, to keep me logged in. Now, as soon as I click the login button and and validated by the server, the server generates a session(for current session) and a cookie(for future sessions), with a time limit of say 1 month. Now, If i come back on say 29th day and open example.com, I shall automatically logged in using the token set in the cookie. The cookie will send my info to the server and the server shall generate my current session. Most importantly, the server will reset the cookie to expire after one month.
If, I return to the website after 30 days, then the cookie will either force me to login again.
I hope my input would be of some help to you.
Im implementing a persistent cookie based on http://jaspan.com/improved_persistent_login_cookie_best_practice.
Question :
If a user tries to access a page. After the authentication is successful, the used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
When you generate a new cookie here, you need a cookie age, I put it as default of 1 month. So, every time the new cookie is generated, should I just put it as default(1 month) or should I store a field in my db which counts the expiry time(something like 1 month countdown). Whats the normal behaviour here ?
Another question, I feel that it is a bit overkill to remove the token and gerenate a new token to db everytime you visit a page. Is this operation as costly as I thought?
Add the expiry both server and client-side, otherwise a cookie grabbed by an attacker would be valid forever.
Changing the token is good and can help protect against the above scenario. Every page visit seems a bit excessive, and could have a performance impact if your site gets busy. How about refreshing it every 5 minutes or so?
I have a webserver (Nodejs+express+ passport) that uses passport for local authentication. Does anyone know if there is some kind of callback occurring when user closes the browser tab? I would like to be able to detect this because I am trying to save logout time stamps for those users that do not explicitly logout (i.e. by clicking log out).
Thank you!
I would have asked you to check the questions on SO first, but I think is no way to do it the way you are trying. Well, check these links: how to run code on window close or refresh and how to detect it was close
Basically you can't. This is one of the reasons why many applications show 'last login time' and not logout time to users, see if that works for you.
Regarding saving the logout time of a user: I would say do not store the value at all. The sessions should be allowed to expire based on configuration: users can be logged out even by staying inactive a long time. A logout time for such users may calculated later, based on their last activity time, (which you can store on each page load/call to your server, when you refresh the user's session timer) and the session timeout value. Now this can be calculated when the user logs in the next time, or using a background process.
You can store the lastActivityDate of the user, and assume that a user is considered offline after xx minutes.
You can try to execute a ajax call on window unload, but if the user has two open pages, and he closed one, the data will be false. It is also not certain that the request reaches the server.
You can set a very short expiration time on your session, and while a page is open, do a ajax regular ping to keep the session open.
How to get session timeout of Domino server in XPages-SSJS. I want to prompt user to save his/her data before session expires. Thanks
Servers only communicate with users when those users make a request to the server.
Because of this, servers cannot send information to the user if they haven't requested it.
For example:
A user requests a page from a server.
The server sends that page back to the user, and creates a session
for that user. The session is set to expire in 5 minutes.
Those 5 minutes are up, and in the meantime the user hasn't requested
any further pages. So the users session ends, but because the user
isn't making any requests, the server has no way of communicating this
to the user.
This is just the way that HTTP traffic is designed to work. There are ways around this however, and by altering the example above I will show you one of the easiest ways:
A user requests a page from a server.
The server sends that page back to the user, and creates a session
for that user. The session is set to expire in 5 minutes. The page that the
server sends back has a javascript setTimeout function which is set to fire off just before the session of the server expires.
Those 5 minutes are up, and again, the user hasn't requested
any further pages. So the users session ends and the server has no way of communicating this
to the user. However, javascript on the page knows that the session on the server is due to expire, and fires off an alert to tell the user to save their work.
In SSJS you can get the setting of the SessionTimeout with the following code:
facesContext.getApplication().getApplicationProperty("xsp.session.timeout", "30");
But this is a static value (in minutes). The session expires in X minutes (30 is default) after the last request of the current session.
Well the timeout is reset with every interaction between server and client. So what could be done is basically have a count down on the client side that resets after every new request. And that could also be used client side to trigger a save interaction for a defined time prior to the actual session timeout.
Whether this makes sense or not is debatable... Alternatively auto-saving could be implemented aswell.