Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-29286

As a Platform UI User, I would like my session to be extended while I still use Platform UI

    XMLWordPrintable

Details

    Description

      Currently, when the User uses PlatformUI, his session might end unexpectedly. This happens because session refresh call to REST API happens only on specific actions (for example navigating). An example of the bad behavior - when the Editor writes/edits an Article for a long time, he will be forced out on publish.

      The customer requests that session would be extended as a User continues using it, or to advise a User that it will end.

      More information from the customer:

      So from my incomplete understanding of the backend code so far, sessions never get extended anywhere in eZ using the REST API. When they are created, they have a default timeout which, if the /refresh endpoint is not specifically called within this period, causes the session to expire and prevent the ‘renewal’ of a user’s logged in state. The /refresh endpoint actually creates a new session using the token contained in the existing, active one. If the existing session has timed out or been cleaned, this would fail and generate an HTTP error code.

      The CAPI provides a number of methods to determine whether a user is logged and to refresh a session in (SessionAuthAgent.prototype.isLoggedIn, UserService.prototype.refreshSession), and from my investigations so far these are generally invoked (other than by either explicitly logging in or refreshing a session) by a function called ezPlatformUiApp.checkUser.

      Crucially, the checkUser function is designed to check to see if the user has a session, and if so, refreshes it. However, this function in turn is only bound to run when switching between a view in the admin, so e.g. going from content structure to edit mode, dashboard, etc, where this method is invoked by the PlatformUI code among functions like showing and hiding side menu panes.

      The notification hub plugin, interestingly, checks to see if the user is still in possession of a valid login, but doesn’t have any logic to refresh the session if the user is logged in. Hence the constant /notifications API calls don't keep the user logged in. Changing this to use the checkUser callback might be a quick way of solving the issue.

      Attachments

        Activity

          People

            Unassigned Unassigned
            jacek.foremski-obsolete@ez.no Jacek Foremski (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: