Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
0 authors
  1. Feb 15, 2020
  3. Feb 14, 2020
  5. Dec 24, 2019
  7. Jun 06, 2019
  9. Feb 03, 2019
  11. Aug 05, 2018
  13. May 31, 2018
  15. Oct 19, 2017
  17. Apr 01, 2017
  19. Jul 02, 2016
    • Jaime Pérez's avatar
      bugfix: Stop SimpleSAML_SessionHandler::newSessionId() from initializing the session. · 4056af12
      Jaime Pérez authored 
      Historically, SimpleSAML_SessionHandler::newSessionId() has also created the session, sending the cookies to the browser. This is problematic both because given the name of the method one would not assume such behaviour, and also because even for transient sessions the handler would then try to set cookies. When we are using a transient session, it is likely to be because we cannot set cookies or because there was a temporary error when loading the session. If we try to set the cookies even for transient sessions, we could either get an error because cookies cannot be set, or overwrite the previous session cookies with transient ones, trashing a legitimate session in case a temporary error occurs.

As a side effect, this can also cause behaviours like the one described in issue #413. There's no point in trying to set the cookies when it's not possible, so we shouldn't even try, and save us the errors.

To fix this, we made SimpleSAML_SessionHandler::setCookie() abstract, forcing each extending class to implement it. The former implementation is moved to SimpleSAML_SessionHandlerCookie, and the SimpleSAML_SessionHandlerPHP gets a new method that starts the session, effectively sending the cookie. SimpleSAML_Session would then be responsible to call the setCookie() method of the session handler when creating a regular session, and skip it when creating a transient one. This introduces a bug, since SimpleSAML_Session was trying to set the auth token cookie calling the same setCookie() method in the session handler. We fixed that by using SimpleSAML\Utils\HTTP::setCookie() instead, in 8756835b.

This resolves #413.
      4056af12
  21. Oct 26, 2015
  23. Aug 04, 2015
  25. Apr 16, 2015
  27. Jul 09, 2014
  29. Sep 13, 2013
  31. Sep 05, 2013
  33. Jan 30, 2012
  35. Aug 10, 2011
  37. Aug 09, 2010
  39. Jul 07, 2010
  41. Feb 24, 2010
  43. Feb 15, 2010
    • Olav Morken's avatar
      Disable cookie secure-flag by default. · c4ae073b
      Olav Morken authored 
      This patch removes the autodetection of the secure flag for the cookie
based on whether the user is accessing simpleSAMLphp through https. The
reason for this is that the user can often access an SP through both
https and http. If the user starts with http, everything will work, but
if the user starts with https, the user will get two separate cookies,
one for https and one for http.

This patch introduces a new configuration option in config.php:

    /*
     * Set the secure flag in the cookie.
     *
     * Set this to TRUE if the user only accesses your service
     * through https. If the user can access the service through
     * both http and https, this must be set to FALSE.
     */
    'session.cookie.secure' => FALSE,

git-svn-id: https://simplesamlphp.googlecode.com/svn/trunk@2180 44740490-163a-0410-bde0-09ae8108e29a
      c4ae073b
  45. Dec 02, 2009
  47. Jun 12, 2008
  49. Jun 06, 2008
  51. May 13, 2008
  53. Mar 05, 2008
  55. Feb 08, 2008
  57. Jan 30, 2008
  59. Dec 18, 2007
  61. Nov 28, 2007