Hi all, On Mon, Dec 5, 2016 at 10:44 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > > This RFC exposes session serializer interface to user space. It works > like user defined session save handler. > > Users are able to encrypt/validate session data transparently. e.g. > You can save encrypted session data to database, decrypt encrypted > data from database transparently. > > https://wiki.php.net/rfc/user_defined_session_serializer > Vote starts: 2016-12-05 Vote ends: 2016-12-19 UTC 23:59:59 > > Although we don't have consensus about number of votes to pass, I set > this RFC to require 2/3 votes. > > Questions are welcomed if you have. > Thank you for voting.
Since there is misunderstanding of this RFC, I'll explain some backgrounds and related topics. * What is session serializer? Session serializer serializes $_SESSION into string format, vice versa. Session serializer is implemented submodule and can have any kind of serialization method as long as it can convert array to string (encode), string to array(decode). Currently, we can only choose internally defined (C written) serializers, php_serialize (recommended), php (default) or php_binary, via php.ini setting. * What this RFC patch does? This patch opens serializer implementation to userspace. Users can write serialization method as PHP script. i.e. Users can use any serialization method, JSON/XML/etc. Since serializer handles array to string, string to array conversion, user may perform additional tasks such as validation, encryption, add/remove transparent data for session management, etc by PHP script. * Why serializer submodule was not exposed to user space until now? This is because of "register_globals". "register_globals" feature required "special serialization format" like php/php_binary serializers. We don't have "register_globals" now, so serializer can be exposed to users. * Save handler (OO API) can encrypt/decrypt. Why this is needed? First of all, the main objective of this RFC is to "open serializer implementation to user script". Without this patch, it requires dirty/inefficient hack to implement user defined serializer. Save handler should perform saving data, not converting session data into other format. This is the intended design. Conversion(serialization) is serializer's task. Session module provides procedural API also. This is mandatory for procedural API. * Why current OO API save handler should be deprecated? Current OO save handler API uses previously defined save handler, i.e. internal C written save handler sub module, as it's base object. Since C written save handlers are not expecting to be called by users abusive/wrong manner, we had many bug reports for this. Overriding open()/close()/etc is useless, moreover it's harmful. I suppose this design is chosen because serializer interface cannot be exposed to userspace due to "register_globals". Since we don't have "register_globals" now, we are better to deprecate obsolete and problematic API and replace it with new clean API. * What would be new OO API save handler? New OO API save handler will be pure PHP script save handler. Therefore, there will be no issues that old API had. i.e. No C written save handler can be called from user script. * With new OO API, encrypting session data cannot be possible? This is the one of the reason why this RFC is proposed. Encryption can be done with this RFC, both OO and procedural API. Session data conversion is serializer task in the first place. Encryption is better to be performed by serializer. * Why it does not use exception for error? Session module uses "errors", not "exceptions" basically. Session save handler uses "errors" also. We should avoid inconsistency in a module. Exception adoption will be addressed and exceptions will be used consistent manner by other RFC. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
