Environment Spring Boot, Spring Session, Spring Security
Hi, I ma implementing session timeout in my spring boot application using the server.servlet.session.timeout=60 . Which means session must timeout after 1 minute of inactivity. Which is not happening. One of the causes would be that my application sends a HTTP GET request (/getCustomerCount() )every 1 second from the webpage (javascript scheduled).
Question : Does HTTP get request converts an IDLE session to be an active session which prevents the sessions to timeout.
If so, then how shall I timeout my application. I want the session idle/active logic to ignore the every second request /getCustomerCount(). Adn if user doesn't perform any task (other than per second request) then consider the session as IDLE and time it out after 60 seconds.
Is there any way in Spring Session, that session manager ignores a particular request while marking a session active and idle ?
Related
I have an unknown App consuming my Spring webservices.
The app set a timeout to every webservice calls.
The server regardless of the app timeout keeps processing.
Is there a risk of any other webservice call in receiving a misresponse (the response to the timed out webservice call)? How does Spring manages this? Doesn't HTTP protocol take care of this, given that each connection channel is open for a particular call to webservice and if broken there shouldn't be possible to retrieve the response?
As a developer, you should try to make all possible HTTP requests to your web server to be idempotent. It means that the client side has to be able to retry the failed request without new possible errors due to the inability to know the previous (timeout) request results.
The client side should handle the HTTP client timeouts himself and (by default) should treat the timeout error as a failure. Your clientside may repeat the request later and the server side should be able to handle the same request.
The solutions may vary for different tasks depending on complexity (from an INSERT statement to the database or scheduling a new CRON job avoiding duplication).
websocket session is wrapped in a http session and so when the http session timesout the websocket session also times out.
However, when only the first call is a http call which is based on session cookie and the rest of the time it is a direct established connection,
how does the connection ever close in case of a timeout?
Scenario - We have a reverse proxy that manages the validation check on the sessions. This means it intercepts each call and checks for the validity of the session.
In case the cookies have expired, it returns a 401.
Since I have integrated websockets to this system, the initial websocket call goes through this reverse proxy with a valid cookie, upgrades the request to websocket and thereafter
keeps sending messages directly. The reverse proxy is not aware of these direct messages sent over WS.
Now when the http session expires, the other calls being made to the system get a 401. However the WS connection above does not know about it at all and continues to send/receive messages.
In case of a logout, an invalidate is called on the http session and so all the bound objects are notified and I get a SessionDisconnectEvent. However in case of timeouts I have no indication at all.
How should I terminate the WS connection in such cases?
Stack - spring + sockJS + basic stomp
My observations are that all the websocket sessions that are bound to the http session are not terminated in case of logout. Only the one that initiated the logout gets the SessionDisconnectMessage.
In case of timeouts, there are no indications at all.
To handle timeouts, I make a call to the server soon after I get a message at the client side and look for a 401 on this call. If it returns a 401, I initiate a session close on the client side.
To handle logout, I maintain a map of the http session id and all the websocket sessions associated with it. When I receive a disconnect on any of the websocket sessions, I terminate all the other ws sessions associated with that http session.
In My application login and transactions after login are implemented using Mobilefirst 8.0. And I have implemented challenge handler and security test with 60 sec timeout for authentication. My application is getting a session timeout after 60 sec from the time of login even while doing transaction also.
How to reset session timeout for each request to server?
I need to set absolute session timeout (timeout the session regardless the user is active or not) in websphere liberty profile server for an application?
How do I do that ? I know inactivity timeout setting. But it is not the requirement, absolute timeout is the requirement.
Either you JAAS enable your application, activate the Lightweight Third Party Authentication (LTPA) and set the absolute time, regardless activity.
The default expiration time is 2 hours and is an absolute time, not based on user activities. After the 2 hours, the token expires and the user must log in again to access the resource. Liberty: Authentication
or
Just set the global session timeout in liberty to x seconds (which is for inactivity), and in your web application for each communication front it with a filter or something similar that checks the session getCreationTime and invalidate it if it exceeds x seconds. Also some good guide and reading here
In this case you will have session invalidity for both inactive and active users.
I have set the session timeout in my WebSphere as 3 Mins (Consider.Actual timeout I have set is 30 mins).I have kept my application open and just moving my mouse over the J2EE application and making some keypress which will not submit any pages.Even after 3 mins, the session of the application is retained.I need to confirm how the session is retained when some mouse move / keypress happens ? No request is being sent to server or no page submissions has been done.
The session timeout for my application is maintained only in server.
Thanks.
This sounds like it's due to WebSphere's use of the LTPA token for authentication. In summary:
When the web session expires a users credentials are not expired (you
are not forced to re-login). This is due to the WebSphere
implementation of LTPA tokens and more info on this is covered in the
IBM documentation.
When the LTPA token expires the users credentials
are expired (you are forced to re-login).
The web session timeout is
relative to user activity. That is, it resets to 0 when user activity
is detected.
LTPA token timeout is not related to user activity. It
will timeout after the amount of time from creation date no matter
what user activity is going on.
From http://www-01.ibm.com/support/docview.wss?uid=swg21078845:
Question 3
I want to force my users to re-login after a set "inactivity timeout" period. How is WebSphere Application Server supposed to work with regard to session timeouts and LTPA timeout.
Answer 3
See the answer to this question in item 9 of the following developerworks article:
http://www.ibm.com/developerworks/websphere/techjournal/1003_botzum/1003_botzum.html
From that link you learn:
9- I want to force my users to login again after a set "inactivity timeout" period. How is WebSphere Application Server supposed to work with regard to session timeouts and LTPA timeouts?
The WebSphere Application Server LTPA token expires based on the lifetime of the login session, not based upon inactivity. Thus, the WebSphere Application Server login session will not expire if the user performs no action for some period of time. However, the HTTPSession does expire based upon inactivity. If in your application you need to expire the use of an application based on idleness, you must explicitly code this in your application. You can capture when a user arrives with an expired session (really, a new session) and force them to login again if you think this is necessary. Keep in mind that doing this undermines Single Sign On across applications.
A second approach that is a slight variation on the first is to use HTTPSession.getLastAccessTime() to compute when the last client request occurred. If the time is too far into the past, you can of course fail the access and force a new authentication.
Either of these approaches can be made transparent to the application code through the use of servlet filters.
It should be noted that IBM Tivoli® Access Manager provides for lifetime- and idle-based authentication session timeouts.
Users often ask why WebSphere Application Server works this way. Why can't it timeout idle login sessions? The reason is because WebSphere Application Server is fundamentally a loosely coupled distributed system. Application servers that participate in an SSO domain don't need to talk to each other. They don't even have to be in the same cell. So, if you want to limit the idleness lifetime of an LTPA token (aka SSO token), you'd have to update the token itself with a last usage time on every request (or perhaps on the first request seen during a one minute interval). This means that the token itself would change frequently (meaning the browser would be accepting new cookies frequently) and that WebSphere Application Server would have to decrypt and verify the inbound token when it is seen to validate it. That could be expensive (WebSphere Application Server today only validates a token on the first use at each application server). It's not impossible to solve these problems with clever caching and such, but that's not how WebSphere Application Server works today.