Honor session.use_strict_mode for the built-in SessionHandler

[iliaal]

SessionHandler implements neither SessionUpdateTimestampHandlerInterface nor a validateId() method, so registering it leaves ps_validate_sid undefined and PS_VALIDATE_SID_FUNC(user) falls through to php_session_validate_sid, which reports every id as existing. With session.use_strict_mode=1, the new default in 8.6, session_set_save_handler(new SessionHandler, true) adopts an attacker-supplied id instead of regenerating it.

validateId() is now implemented on the class alongside the other methods that delegate to the wrapped module. A subclass that overrides open() without calling parent::open() never opened that module, so it cannot answer for the id and returns true, which keeps the behavior those handlers have today.

[Girgias]

The methods should just be implemented on the class. Rather than this nonsense.

[jorgsowa]

This would be automatically fixed in PHP 9 thanks to the deprecation (if it passes) https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_passing_a_sessionhandler_object_to_session_set_save_handler_which_does_not_contain_the_create_sid_and_validateid_methods

[iliaal]

Done in e13ba93. SessionHandler::validateId() now sits next to the other methods that delegate to the wrapped module, and the check in PS_VALIDATE_SID_FUNC is gone.

One guard was needed to get there: a subclass that overrides open() without calling parent::open() never opened the module it would validate against, so it returns true rather than vetoing the id. Without that, session_set_save_handler_class_002.phpt and _016.phpt lose their session data, since those subclasses replace storage and inherit the method.

[iliaal]

A deprecation would not change the 8.6 behavior though, the id is still adopted. Does it cover new SessionHandler itself? It has create_sid() but no validateId(), so as worded it looks like it lands on the deprecated side. e13ba93 adds the method, which settles that either way.