Session Out
14 November, 2014
Hi Guys,
A customer is trying to extend to session timeout setting to last more than 12 hours. However, this is not happening.
They are logging users through the SOAP API. Does the parameter effect users logged in through the API?
Please advise?
Regards,
Nick
I�m still not managing to get Single Sign On sessions to last for more than 12 hours.
Unfortunately the previous answer that you gave me, which was to change the session-timeout value in Yellowfin�s web.xml is not sufficient for our needs.
When we log a user in, we do so using the �Single Sign On� functionality provided by Yellowfin, through the SOAP call LOGINUSERNOPASSWORD. This mostly works, except for the fact that the HTTP cookie returned by this call has an expiry of 12 hours. Even if we rewrite the expiry on this cookie before sending it back to the browser, the session still times out after 12 hours, indicating that this 12 hour timeout is genuine, and is coded somewhere inside the Yellowfin server. In other words, it is not merely a tolerable bug that the cookie has a 12-hour expiry. There is something deeper in the system that is marked with a 12 hour expiry time.
One discrepancy that one sees is that if you go to the Yellowfin admin console, and look at the �session management� window, then the sessions appear to have an expiry that coincides with the web.xml�s session-timeout value. In other words, this number is very high (because we set it high). However, there is clearly some other session expiry value somewhere in Yellowfin�s internal state, because if we return to the yellowfin website 24 hours later, then we get the message �Your session has timed out - please logon again�. This is despite the cookies on the browser still being valid, and the Yellowfin session management window indicating that the session still has a lot of minutes remaining.
To be clear, the call that returns these cookies is /logon.i4?LoginWebserviceId=. We make this call after making a SOAP request LOGINUSERNOPASSWORD.
A customer is trying to extend to session timeout setting to last more than 12 hours. However, this is not happening.
They are logging users through the SOAP API. Does the
Please advise?
Regards,
Nick
I�m still not managing to get Single Sign On sessions to last for more than 12 hours.
Unfortunately the previous answer that you gave me, which was to change the session-timeout value in Yellowfin�s web.xml is not sufficient for our needs.
When we log a user in, we do so using the �Single Sign On� functionality provided by Yellowfin, through the SOAP call LOGINUSERNOPASSWORD. This mostly works, except for the fact that the HTTP cookie returned by this call has an expiry of 12 hours. Even if we rewrite the expiry on this cookie before sending it back to the browser, the session still times out after 12 hours, indicating that this 12 hour timeout is genuine, and is coded somewhere inside the Yellowfin server. In other words, it is not merely a tolerable bug that the cookie has a 12-hour expiry. There is something deeper in the system that is marked with a 12 hour expiry time.
One discrepancy that one sees is that if you go to the Yellowfin admin console, and look at the �session management� window, then the sessions appear to have an expiry that coincides with the web.xml�s session-timeout value. In other words, this number is very high (because we set it high). However, there is clearly some other session expiry value somewhere in Yellowfin�s internal state, because if we return to the yellowfin website 24 hours later, then we get the message �Your session has timed out - please logon again�. This is despite the cookies on the browser still being valid, and the Yellowfin session management window indicating that the session still has a lot of minutes remaining.
To be clear, the call that returns these cookies is /logon.i4?LoginWebserviceId=
Hi Nick
You are correct.
It looks like in the past there has been a hard coded 12 hour timeout.
See the second box of the following link
Link
What I will do is contact the dev team to see if this older info is still valid or if there is now a work around.
Thank you
Mark
You are correct.
It looks like in the past there has been a hard coded 12 hour timeout.
See the second box of the following link
Link
What I will do is contact the dev team to see if this older info is still valid or if there is now a work around.
Thank you
Mark
Hi Nick,
We have not changed any session timeouts in later version.
Though from the sounds of your issue, I think the cookie itself could be expiring because of Tomcat itself, not YF.
Can you check your Tomcat session config:
Here is a post that may help with this: JSESSIONID Cookie with Expiration Date in Tomcat
Please let us know how it all goes.
Regards,
David
We have not changed any session timeouts in later version.
Though from the sounds of your issue, I think the cookie itself could be expiring because of Tomcat itself, not YF.
Can you check your Tomcat session config:
Here is a post that may help with this: JSESSIONID Cookie with Expiration Date in Tomcat
Please let us know how it all goes.
Regards,
David