I'm using Jetty's implementation for javax.servlet.http.HttpSession and I need to set expiration time in epoch time (unix time). I've googled it and didn't find any appropriate results. Is there any possibility to do so out of the box? Or is there any easy way to do this?
Sessions don't have an expiration time. They have an expiration timeout. After N time of inactivity, the session expires.
Because of this, you'll be looking at implementing your own logic if you want to have your session expire at specific "wall clock time".
A simple implementation that comes to mind would be to put an attribute in the session containing the time of expiration, then having a filter check that on the server side.
Related
According to this page we have the ability to set TTL for state when using Flink Statefun v2.1.0.
We also have the ability to bootstrap state, according to this page.
First question is, bootstrap documentation does not mention state expiration at all. What is the correct way to do bootstrapping on states that have TTL? Can someone point me to an example?
The second question is, what happens if I set some state as expire after writing in 1 day and then bootstrap that state using 6 months worth data?
Is the whole bootstrapped state going to expire after literally 1 day?
If so, what can I do to have it expire 1 day worth of data after 1 day passes?
Yes, if that data hasn't been modified since it was loaded, it will all be deleted after one day.
To expire one day's worth of data every day: After bootstrapping the state, you could send yourself a delayed message, set to be delivered one day later. When it arrives, delete the oldest data and send another delayed message.
We wrote some jquery and java code to support passing a cookie with the expected session expiration time to the client, which then prompts the user two minutes before to give them the chance to extend their session. If they fail to do so in time, they get forwarded on their next button click to a landing page.
Works great...most of the time. Every so often, a tester trying to test this will wait 4 minutes after the prompt comes up, click a button only to find that their session is still alive despite waiting 2 full extra minutes longer than they should have had to for the session to die.
Is the spec just not that precise with when sessions expire? Should we sort of blow this off as not a big deal? we're using ibm's websphere as our app server.
WebSphere has a setting called HttpSessionReaperPollInterval that controls this behavior.
Use this property to specify, in seconds, a wake-up interval for the
process that removes invalid sessions. The value specified for this
property overrides the default installation value, which is between 30
and 360 seconds, and ensures that the reaper process runs at a
specific interval.
https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/rprs_custom_properties.html
Although the property can be adjusted, it may still not make sense to change the default value in your scenario.
I assume you set the session expiration time to two minutes on the server. That is, not the cookie expiration time.
The session should expired after two minutes. However the session can come back alive (but empty) after expired if application (click button) called getSession(true) instead of getSession(false).
If this isn't the case, can you enable the session trace : com.ibm.ws.session.*=all
I am implementing a thread based application where i will be connecting to Alfresco continuously. I want to avoid a session timeout error so wanted to know at what interval should i clear the session or create a new one. And how long can i continue with the same instance of the session with me.
If you check the repository.properties you'll find the following property
# If authentication.ticket.ticketsExpire is true and
# authentication.ticket.expiryMode is AFTER_FIXED_TIME or AFTER_INACTIVITY,
# this controls the minimum period for which tickets are valid.
# The default is PT1H for one hour.
authentication.ticket.validDuration=PT1H
You can change this session to whatever you want, but it will be applied globally. I've max upped this to 24 hours, so you can decide for yourself.
The other way is implementing a pooling method with get's a new ticket after every hour.
Is there a way to find out how long the session of the user remains valid ( until it times-out)?
I would like to show this time on a page.
I know how to set the timeout, but could not find how to get the current time to time-out.
I think you should track the time with plain JavaScript in the browser and reset with every Ajax/WebSocket call.
You cannot track it at the server because to check the time you need to make a request and this will renew the session.
There is a getLastAccessedTime() on the session object, that might help.
From a servlet, how can I set a cookie that will never expire?
I have tried doing it like this:
Cookie cookie = new Cookie("xyz","");
cookie.setMaxAge(-1);
But when I do it this way, it expires as soon as the user closes the browser.
If you call setMaxAge() with a negative number (or don't call it at all), the cookie will expire at the end of the user's browser session. From the documentation:
A negative value means that the cookie is not stored persistently and will be deleted when the Web browser exits.
The typical approach for cookies that "never" expires is to set the expiration time some far amount into the future. For example:
cookie.setMaxAge(60 * 60 * 24 * 365 * 10);
Will set the expiration time for 10 years in the future. It's highly probable that the user will clear their cookies (or probably just get a new computer) within the next 10 years, so this is effectively the same as specifying that it should never expire.
Keep in mind that cookies don't actually have a concept of a "maximum age"; the way this is actually implemented is Java adds the specified number of seconds to the server's current system time, then sends that time as the expiration time for the cookie. So, large mismatches between server time and client time can complicate things a little - the best you can do (at least, easily) is ensure your server clock is set correctly and hope the clients' clocks are set.
Setting the maximum age: You use setMaxAge to specify how long (in seconds) the cookie should be valid. Following would set up a cookie for 24 hours.
cookie.setMaxAge(60*60*24);