Skip to content
Snippets Groups Projects
  1. Feb 14, 2020
  2. Dec 24, 2019
  3. Oct 01, 2019
  4. Sep 24, 2019
  5. Sep 16, 2019
    • Jaime Pérez Crespo's avatar
      Do not attempt to set the session ID for transient sessions · 8b4b2138
      Jaime Pérez Crespo authored
      It just doesn't make any sense. If we managed to get it from an existing cookie, it serves no purpose, as at this point we couldn't load the session anyway, and what we use to track users is the track ID, not the session ID. Additionally, since this is a transient session, we're not going to push the cookie to the browser (we might not even can do that), so it's really pointless to set the session ID.
      
      This, additionally, was causing that the Session class would be unable to initialize and register a transient session if the issue that forced us to use a transient in the first place was an issue with the session handler (e.g. missing PHP extensions or dependencies, or connection failure to the backend, etc). Under such circumstances, the code removed here will not work either, since the session handler will continue to fail to initialize. This would cause the exception handler to jump in, completely losing control of the execution, and making it impossible to display the error to the user (since the transient session creation is never completed, it cannot be used later where it is needed in the SimpleSAML\Error\Error class).
      
      This resolves #914.
      8b4b2138
    • Jaime Pérez Crespo's avatar
      Remove misleading phpdoc · 2748d2da
      Jaime Pérez Crespo authored
      This comment used to be true, but the behaviour was changed in 3c52b289 in order to purge old data more often.
      2748d2da
  6. Sep 04, 2019
    • Jaime Pérez Crespo's avatar
      Make sure expired data is actually purged · 3c52b289
      Jaime Pérez Crespo authored
      The SimpleSAML\Session::expireData() method did not mark the session as dirty when there was expired data on it, so if nothing else changed, the data was never actually purged. It was done like this by design, but in practice, it seems like sessions aren't modified as often, meaning they end up growing a lot with each state array that's stored on them, and expired data is never removed. We now check for expired data in the save() method (which is run every time a session is destroyed, if not manually) and if there is any, we mark the session as dirty, so that it is actually updated in the backend. Most of the time this will be transparent and have no visible performance hit, as it'll be run after the response is sent, during shutdown.
      
      This closes #1053
      3c52b289
  7. Aug 31, 2019
  8. Jul 08, 2019
  9. Jun 06, 2019
  10. Feb 03, 2019
  11. Jan 13, 2019
  12. Nov 02, 2018
  13. Oct 17, 2018
  14. Sep 26, 2018
  15. Aug 24, 2018
  16. Aug 22, 2018
  17. Aug 13, 2018
  18. Aug 06, 2018
  19. Aug 05, 2018
  20. May 31, 2018
  21. Apr 13, 2018
  22. Feb 02, 2018
  23. Jan 26, 2018
  24. Jan 04, 2018
  25. Nov 29, 2017
  26. Oct 19, 2017
  27. Jun 06, 2017
    • Jaime Pérez Crespo's avatar
      Fix a bug in the PHP session handler · ab344d88
      Jaime Pérez Crespo authored
      When unserializing the session fails, the handler should return null instead of false. Additionally, SimpleSAML_Session::load() should make sure that it got an instance of SimpleSAML_Session, to avoid any misbehaving handlers to generate an issue.
      
      This resolves #616.
      ab344d88
  28. Apr 01, 2017
  29. Mar 17, 2017
  30. Dec 05, 2016
Loading