we have upgraded from WSO2 IS 5.0.0.SP1 to WSO2IS 5.1.0 and we're trying to fix the session expiration. Seems the users is logged in for long time.
On the logon screen we have the rememberMe checked by default (we want users to be persistent for approx 14h = 840m)
What I see is multiple timeout parameters in the identity.xml:
<SessionDataPersist>
<Enable>true</Enable>
<Temporary>false</Temporary>
<SessionDataCleanUp>
<Enable>true</Enable>
<CleanUpTimeout>841</CleanUpTimeout>
<CleanUpPeriod>30</CleanUpPeriod>
</SessionDataCleanUp>
<OperationDataCleanUp>
<Enable>true</Enable>
<CleanUpPeriod>30</CleanUpPeriod>
</OperationDataCleanUp>
</SessionDataPersist>
</JDBCPersistenceManager>
...
<TimeConfig>
<SessionIdleTimeout>840</SessionIdleTimeout>
<RememberMeTimeout>840</RememberMeTimeout>
</TimeConfig>
...
<PersistanceCacheTimeout>900</PersistanceCacheTimeout>
<SessionIndexCacheTimeout>900</SessionIndexCacheTimeout>
but seems the user is logged in even next day (24h)
Now checking the database for the session timeout we see the time_created is even placed far in future (3.5 days).
select session_id , session_type, time_created, operation, tenant_id from idn_auth_session_store where session_id='8d761e3d-c2c8-4a50-b58f-dc20822a0000'
8d761e3d-c2c8-4a50-b58f-dc20822a0000 | SAMLSSOSessionIndexCache | 1467171230156905138 | STORE | 0
Seems 1467171230156905138 is Wed, 29 Jun 2016 03:33:50 GMT
question is - has the time_created used as the expiration timestamp or is it somewhere wrongly converted? If it is used as the expiration date - where is it really configured?
Edit:
what I see from the code the value is (cannot we just use a simple ms timestamp?):
currentStandardNano = currentStandardNano + (currentSystemNano - FrameworkServiceDataHolder.getInstance().getNanoTimeReference());
this effectively move the timestamp in future for the value of the server's uptime. Is there a reason for it?
Thank you for any insight
This was identified as an issue in Identity server 5.1.0 and has been fixed for future releases. This has been discussed here.
Related
Assuming the following metric:
cpu_count{machine="srv1", owner="Alice", department="ops"} 8
cpu_count{machine="srv1", owner="Bob", department="ops"} 8
I'd like to be able to prevent starting a new time series on owner change. It should still be considered the same instance, but I would like to be able to look up by owner.
I don't particularly care if it matches only on my_metric{owner=~"Box"} or on both my_metric{owner=~"Box"} and my_metric{owner=~"Alice"}, I just need to make sure it does not count twice on my_metric{machine=~"srv1"} or my_metric{department=~"ops"}.
I'm willing to accept that using labels to group instances in this manner is not the correct approach, but what is?
When you add the label "owner" to this kind of metric I think you're trying to accomplish a kind of "asset management" which could be done better with some other tool developed specific to this goal. Prometheus isn't a suitable tool to keep the information of who is using each machine in your company.
Said that, every time the owner of a machine changes you could workaround this issue deleting the old data series using the REST API executing something like this:
curl --silent --user USER:PASS --globoff --request POST "https://PROMETHEUS-SERVER/api/v1/admin/tsdb/delete_series?match[]={machine='srv1',owner='Bob'}"
If you can change the code, it would be better to have a metric dedicated to the ownership:
# all metrics are identified a usual
cpu_count{machine="srv1", department="ops"} 8
# use an info metrics to give details about owner
machine_info{machine="srv1", owner="Alice", department="ops"} 1
You can still aggregate the information id you need it:
cpu_count * ON(machine,department) machine_info
That way, the owner is not polluting all your metrics. Still, you will have issues when changing the owner of a machine while waiting for the older metric to disappear (5 minutes before staleness).
I have not tried it but a solution could be to use the time at which the ownership changed (if you can provide it) as a metric value - epoch time in seconds.
# owner changed at Sun, 08 Mar 2020 22:05:53 GMT
machine_info{machine="srv1", owner="Alice", department="ops"} 1583705153
# Previous owner Sat, 01 Feb 2020 00:00:00 GMT
machine_info{machine="srv1", owner="Alice", department="ops"} 1580515200
And then use the following expression to get the latest owner whenever you need the current owner - only useful when owner has changed within the last 5 minutes:
machine_info == ON(machine,department) BOOL (max(machine_info) BY(machine,department) )
Quite a mouthful but it would approach what you want.
In my project, we want to test how our product behaves when the GPG key expires. So we want the key to expire in a really short time in order to repeat the test frequently.
Actually, the prompt message when generating the key clearly indicates that the minimal unit of expiration is "day":
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
But I still want to ask the question out just in case there is something that meets my need: Is it possible to set GPG key expiration time shorter than one day (say, an hour, or even minutes)?
If there is no such a way, I'll need to figure out how to repeat our test without having to wait for a whole day.
As far as I can tell, it is only documented in the source code, but you can just enter the datetime at the Key is valid for? (0) prompt using the form yyyymmddThhmmss.
For example, to set the expiry to 8 March 2099 at 9:34 AM (UTC), you would enter 20990308T093400. The time zone of your input is always interpreted as UTC, although you will see the confirmation in your local time zone, e.g. Key expires at Fri Mar 8 10:34:00 2099 +01.
As of version 2.1.20, you can also append a Z to the datetime to explicitly denote UTC, e.g. 20190308T093400 Z, but no other time zones are supported for entry.
I have 3 sessions -
1- USER
2- LANGUAGE
3- COUNTRY
When session expires - user is redirect to login and receive a message: "You are disconnected by inactivity"
Its ok. but..
MY ISSUE:
Because I lost session - I lost ALL 3 Sessions - and I don't know the LANGUAGE and COUNTRY of the user.
Then I Always print an English alert (default language)
What I want:
A way to control de timeout of each session. With this I can expires User Session first - and get the other two parameters to print the right language.
Is it possible?
I know how to expires - but ALL sessions..
tks!
Use cookies, so you can control the time, even if the user closes the browser
Response.Cookies("name_cookie")("language") = 1
Response.Cookies("name_cookie")("country") = 1
Response.Cookies("name_cookie").Expires = now + 365
there are 2 values in the config file for codeigniter session which i do not fully understand and hope someone can enlighten me, thanks.
# the number of SECONDS you want the session to last.
# by default sessions last 7200 seconds (two hours).
# Set to zero for no expiration.
$config['sess_expiration'] = 7200;
Q1) Will the application logout the user when the time(2 hrs after login) is up even though the user is still actively using the application?
# how many seconds between CI refreshing Session Information
$config['sess_time_to_update'] = 300;
Q2) Does this value affect the (Q1) senario?
The $config['sess_expiration'] is how long it will take before the session expires if there is no activity by the user on the session. $config['sess_time_to_update'] will update the expiration time every 5 minutes while the user is actively using the session.
So if the user logs in, has an expiration of 2 hours, and navigates around the site for 30 minutes and then leaves the site, they will have 2 hours from that point to visit again without needing to log in. If they do visit in those 2 hours, the expiration time will be reset to 2 hours from that point. If they don't visit again, they'll need to login.
Therefor if they are using the session they will not be logged out after 2 hours.
I have a ACL+auth driven app. Everything works fine but I discovered that user is logged out after a random period of time. After doing some research I discovered that the cookie set once doesn't change it's expiration date on page refresh. So it goes like this:
I set up manually expiration time to 1 minute (Security.level low (with some changes in cake/libs) and timeout 60)
19:00:00 - user loads the page - cookie is set up
19:00:05 - user logs in (cookie doesn't change the expiration date)
19:00:30 - page refresh (cookie doesn't change the expiration date)
19:00:55 - page refresh (cookie doesn't change the expiration date)
19:01:05 - page refresh - user is logged out... (cookie expired after 1 minute)
So the problem is the user gets logged out after 60 seconds from setting a cookie in instead of 60 seconds of inactivity. Does CakePHP deal with cookie files automatically? Or do I have to take care about it myself?
All I did is set up a cookie name in config/core.php and setup auth. I don't have any cookie handling function, but the cookie is created itself - correctly, just isn't updated
I had the same issue and countered it with the following code which is called on every page load and ajax call.
if(isset($_COOKIE[Configure::read("Session.cookie")])){
$session_delay = Configure::read("Session.timeout") * (Configure::read("Security.level") == "low" ? 1800 : 100);
setcookie(Configure::read("Session.cookie"), $_COOKIE[Configure::read("Session.cookie")], mktime() + $session_delay, "/");
}