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.