Fixes issue https://github.com/simplesamlphp/simplesamlphp/issues/793

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.

This is related to #478.

Make exception message when setting secure PHP session cookies through an insecure channel coincident with the message in SimpleSAML\Utils\HTTP::setCookie().

Both SimpleSAML_SessionHandlerPHP::setCookie() and SimpleSAML\Utils\HTTP::setCookie() throw the SimpleSAML\Error\CannotSetCookie exception. Depending on why the error was generated, set the error code in the exception accordingly.

Revert "Set the session name explicitly in SessionHandlerPHP, even when we are using the default value."

This reverts commit cd6278cc.

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.

Add a method to SimpleSAMLphp_SessionHandlerPHP to restore a session existing previously to our own session. This can be used in SimpleSAML_Session to restore the PHP session status previous to calling our API, while also guaranteeing that our session is correctly saved. The documentation has been updated to reflect this and recommend how to deal with conflicting PHP sessions. This closes #244 and resolves #349.

Bugfixes: the PHP session handler only fetches the cookie configuration parameters if session_id() returns a non-empty ID. This won't happen if the application initialized a session previously, hijacking the session and causing all kinds of trouble. Instead, we need to detect if there's an active session, save its parameters and close it. After closing it, we can name a new session and set the cookie parameters.

Bugfix: when using PHP sessions, if there's already a session, session_id() will return the identifier of that session, not our session. In that case, we need to make sure it is our session so that we don't hijack the one of the application.

Avoid the PHP session handler to generate errors when we try to retrieve a session after the headers being sent to the browser.

It's obviously more secure and therefore better as a default.

git-svn-id: https://simplesamlphp.googlecode.com/svn/trunk@3275 44740490-163a-0410-bde0-09ae8108e29a