Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-64976

Shibboleth logout suboptimal and logout implementation for RedisI

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Deferred
    • Icon: Minor Minor
    • None
    • 3.6.2
    • Authentication
    • MOODLE_36_STABLE

      The main problem here is that logout has been implemented only for file or db session.

      We are using Redis sessions. So I wanted to implement the logout for redis.

      I dived a little bit into it. Here are my findings : 

      When an idp wants to logout it call a soap web service in moodle passing to it a shibbolethid.

      Moodle has then to find the session with that shibboleth id and destroy it. The problem is that this shibbolethid is stored in the session itself. So moodle has to iterate over all the active sessions decode it and check if shibbolethid is the good one. This is suboptimal and can take a long time in a big platform  (we have platforms with more than 8000 active sessions).

       

      What I propose to do is the following :

      • Stores the association of shibloethid and sessionid at connection (auth/shibboleth/auth.php)
      • At logout use that correspondence to find sessionid

      With that correspondence it is then very easy to implements logout for Redis, Memcache, etc ...

      My question is what is  the better choice :

      • create a new table withe shibid - sid correspondence
      • store that that shibid directly in mdl_sessions table

      Myself I have a preference for the second option even if it is modifying a core table. 

      What do you guys think?

      Noel Dieschburg

            Unassigned Unassigned
            ndieschburg Noel Dieschburg
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.