<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Share 'Session-Timeout' Logic in Alfresco Archive</title>
    <link>https://connect.hyland.com/t5/alfresco-archive/share-session-timeout-logic/m-p/304545#M257675</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Hello,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;there is no such code specific to the session timeout. When the session timeout is reached, the web application server will simply have "forgotten" who the user is, e.g. any authentication data contained in the session is lost. The next time the user navigates to a page, this will be noticed by the Surf framework and the user will be redirected to the login page as any unauthenticated user would.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;There is no way to determine reliably if the user is redirected to the login page because of a timed-out session. Sure, the client will likely submit a session cookie, but this could also be faked or be a session cookie from the last time the user accessed the page months ago.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;There are various places where an authentication check is performed and a redirect to the login page or an error might occur. The primary redirect to login-page is handled in the class org.springframework.extensions.surf.mvc.PageView, but any authentication error in any Share web script (or even client-side triggered AJAX requests) might also redirect to the root context of the Share web application with the cookie already gone. I.e. if an AJAX call fails due to session timeout, the client-side handling of the response will reload the page and this reload should already be lackig the now obsolete session cookie, preventing you from identifying this reload as a "session has timed out" case.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Regards&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Axel&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Sun, 27 Sep 2015 12:42:44 GMT</pubDate>
    <dc:creator>afaust</dc:creator>
    <dc:date>2015-09-27T12:42:44Z</dc:date>
    <item>
      <title>Share 'Session-Timeout' Logic</title>
      <link>https://connect.hyland.com/t5/alfresco-archive/share-session-timeout-logic/m-p/304544#M257674</link>
      <description>I've recently adjusted the Share session-timeout in the Share web.xml for a client. The client would like a message (similar to the one given on login failure via the "?error=true" doLogin argument) to appear when the user is redirected to the login page after exceeding the configured inactivity tim</description>
      <pubDate>Thu, 24 Sep 2015 15:34:16 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-archive/share-session-timeout-logic/m-p/304544#M257674</guid>
      <dc:creator>dswenson</dc:creator>
      <dc:date>2015-09-24T15:34:16Z</dc:date>
    </item>
    <item>
      <title>Re: Share 'Session-Timeout' Logic</title>
      <link>https://connect.hyland.com/t5/alfresco-archive/share-session-timeout-logic/m-p/304545#M257675</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;Hello,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;there is no such code specific to the session timeout. When the session timeout is reached, the web application server will simply have "forgotten" who the user is, e.g. any authentication data contained in the session is lost. The next time the user navigates to a page, this will be noticed by the Surf framework and the user will be redirected to the login page as any unauthenticated user would.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;There is no way to determine reliably if the user is redirected to the login page because of a timed-out session. Sure, the client will likely submit a session cookie, but this could also be faked or be a session cookie from the last time the user accessed the page months ago.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;There are various places where an authentication check is performed and a redirect to the login page or an error might occur. The primary redirect to login-page is handled in the class org.springframework.extensions.surf.mvc.PageView, but any authentication error in any Share web script (or even client-side triggered AJAX requests) might also redirect to the root context of the Share web application with the cookie already gone. I.e. if an AJAX call fails due to session timeout, the client-side handling of the response will reload the page and this reload should already be lackig the now obsolete session cookie, preventing you from identifying this reload as a "session has timed out" case.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Regards&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Axel&lt;/SPAN&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 27 Sep 2015 12:42:44 GMT</pubDate>
      <guid>https://connect.hyland.com/t5/alfresco-archive/share-session-timeout-logic/m-p/304545#M257675</guid>
      <dc:creator>afaust</dc:creator>
      <dc:date>2015-09-27T12:42:44Z</dc:date>
    </item>
  </channel>
</rss>

