We are using alfresco 5.2.3 enterprise with ADF 3.4.0
The web.xml files in our both alfresco and share war has 60
And for ADF we have not found any session timeout settings or config.
So, ideally the session should not expire before 60 mins, but the customer is complaining that after remaining idle for around 15 mins, their session expires/logs out. They need to relogin.
So, what should be the ideal way to make the session valid for actual 60 mins and not just 15 mins.
I tried overriding the session timeout using the following link but it's not working:
Overriding alfresco timeout
Also tried setting the following property in alfresco-global.properties file with different values:
authentication.ticket.validDuration=PT1H
But does not work.
The same behaviour is noted when we use ADF url as well as Share url.
Share Url actually logs out the user, ADF url mostly invalidates the session so our custom actions do not appear against the documents if user remains idle for 15 mins.
NOTE: There is no SSO integration done for our project.
Any suggestions or pointers would be really helpful.
I tried out with multiple options:
authentication.ticket.ticketsExpire=true
to
authentication.ticket.ticketsExpire=false
authentication.ticket.expiryMode=AFTER_INACTIVITY
to
authentication.ticket.expiryMode=DO_NOT_EXPIRE
authentication.ticket.useSingleTicketPerUser=false
to
authentication.ticket.useSingleTicketPerUser=true
But, none of the above settings after restart give any impact on the behaviour. So, this session timeout settings are mostly carried forward from the proxy server or load balancer settings and applied here.
Related
I have used the WSO2 API manager in my company. When I change the settings of the available methods (scopes) or the available authorisation methods (application level security), the application of these settings takes up to 15 minutes (I tested the work of the methods through postman). This is a lot for running tests.
I followed the recommendation to change the timeout in the deployment.toml
[apim.cache.resource]
enable = true
expiry_time = "900s"
There were no such settings in my config, but I added them and change for 60s. After the reboot, the settings were applied instantly (not even after 60 seconds). However, after a while, the settings were applied again after 15 minutes. I disabled the cache altogether, but it didn't help the as well. Settings are applied quickly only the first time after restarting WSO2. Has anyone had the same problem?
In WSO2 APIM if you update an API, the resource cache gets invalidated and the changes are reflected within a few minutes. If you want to apply the changes quickly you can restart the server and check the flow.
The default cache size of any type of cache in a WSO2 product is 10,000 elements/records. Cache eviction occurs from the 10001st element. All caches in WSO2 products can be configured using the <PRODUCT_HOME>/repository/conf/deployment.toml file. In case you have not defined a value for default cache timeout under server configurations, the defaultCacheTimeout of 15 minutes will be applied which comes by default.
[server]
default_cache_timeout = 15
Please refer https://apim.docs.wso2.com/en/3.0.0/administer/product-configurations/configuring-caching/ for further details on caching.
I would like to know whether session data persistence
<SessionDataPersist>
<Enable>true</Enable>
<RememberMePeriod>..</RememberMePeriod>
<CleanUp>
<Enable>true</Enable>
<Period>..</Period>
<TimeOut>..</TimeOut>
</CleanUp>
<Temporary>false</Temporary>
</SessionDataPersist>
which is available as part of WSO2 IS SP1 is only applicable when Remember me option is selected? Is there any other config where we manage these session timeouts?
Regards,
Cijoy
If you do not enable the session persistence, WSO2IS invalidates the SSO session after 15 minutes inactive time and the value is not configurable as it is the cache invalidation time. WSO2IS 5.0.0 just stores the SSO session in caches which is not correct and which can leads to lot of issues. Then WSO2IS 5.0.0 SP1 introduces the session persistence. So; currently there is no configuration to define the session timeout explicitly. But timeout can be happened, when these session can be deleted.
Therefore timeout can be achieve with cleanup task but it is not an inactive time out.
<CleanUp>
<Enable>true</Enable>
<Period>10</Period>
<TimeOut>60</TimeOut>
</CleanUp>
CleanUp.Period defines the time period among two consecutive cleanups in minutes. By default it is 1 day.CleanUp.TimeOut defines the timeout value of session data in minutes. By default it is two weeks.
For an example if we consider the above configuration it means that the clean up task will run periodically with a period of 10 minutes.
And in a cleanup process it will remove all session data persisted before 60 minutes.
I have an classic ASP site on IIS(both IIS 6,and 8) and both perform the same. We've had this issue for years on IIS 5,6,7,8 and never could figure it out. I have a time out setting on the IIS application pool settings of 120 minutes. I do not have a session.timeout setting in any of the ASP code itself. I do have a Session.Abandon in the global.asa file, which works well.
Most of the time if a user is idle for > 120 minutes, it gives them a message that their session has timed out, expires the sessions and redirects them back to the login page.. this is how it should work and most of the time is does.
The issue I have is that about 5% of the time, some users seem to be able to keep the session alive beyond the 120 minutes. Some for days.
I'm wondering if anyone has any ideas what could cause this? Some ideas that I think could cause this??
I assume they keep their browsers open for days, but could a user that has a browser window open but sitting idle AND on another TAB of that same browser be active on other websites? Does that activity make the TAB with my application still active/not idle? I've tested this on several environments but not able to replicate.
Some type of software like a URL filter, proxy server or Antivirus could be causing their browser to not be idle?
Of course a user can keep the session idle if they use the app beyond the 2 hours, but it is rather unlikely they do this, especially for days.
Its hard to troubleshoot since the users are all customers. So I have no clue if its a certain browser, browser version, or their network environment.
Any ideas?
have you tried out to set the timeout in the Application_OnStart method in global.asa?
I had a similar problem, but in my case the session ended up before timeout.
After I set up timeout the problem was solved, just including this line:
Session.Timeout=20
Hope it helps.
I am using Tomcat 7.0, Spring 4.0.2, Web Module 3.0 in eclipse for my web application.
And I configured my session timeout in app/web.xml as well as tomcat/conf/web.xml.
<session-config><session-timeout>10</session-timeout></session-config>
I am sending one request called captureLastActiveTimeForCurrentFile after every 5 mins.
I need to ignore one request (suppose, captureLastActiveTimeForCurrentFile) from updating lastAccessedTime of session.
According http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Sessions (org.apache.catalina.core.StandardHostValve.ACCESS_SESSION) default behavior of tomcat is : every request that is associated with a session will cause the session's last accessed time to be updated if the request explicitly accesses the session.
I am not accessing session explicitly from request (HttpServletRequest object) captureLastActiveTimeForCurrentFile. So According to my understanding tomcat should invalidate session after 10 min from any request done which is accessing session explicitly. But In my case tomcat never invalidate session because I am sending captureLastActiveTimeForCurrentFile after every 5 mins. But according to docs it should be. Can Anyone help me to understand what is happening here? Thanks in advance.
EDIT : I found some discussion regarding this topic here. But still I am not getting actual problem.
I observe the following weird behavior. I have an Azure web role which is deployed on love Azure cloud. Now I click "Configure" in the Azure Management Portal and change the number of instances - the portal shows some "activity". Now I open the browser and navigate to the URL assigned to my deployment and start refreshing the page something like once per two seconds. The page reloads fine many times and then fro some time it will stop reloading - the request will be rejected, then after something like half a minute the requests are handled normally.
What is happening? Is the web server temporarily stopped? How do I change number of instances so that HTTP requests to the role are handled at all times?
When you change the configuration file, your current instance might be restarted. This might be the reason you met with, which your website didn't response in about 30 seconds.
Please have a look http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changing.aspx and check if it 's because of the role restarting.
What you are doing is manual. Have you looked at the SDK for autoscaling Azure?
http://channel9.msdn.com/posts/Autoscaling-Windows-Azure-applications
Check out the demo at the 18 minute mark. It doesn't answer your question directly, but its a much more configurable/dynamic way of scaling Azure.
Azure updates your roles one update domain at a time, so in theory you should see no downtime when updating the config (provided you have at least two instances). However, if you refresh the browser every couple of seconds, it's possible that your requests go always to the same instance due to keep-alive.
It would be interesting to know what the behavior is if you disable keep-alives for your webrole. Note that this will have a performance impact, so you'll probably want to re-enable keep-alives after the exercise.