Hi Marco,
On Wed, Aug 10, 2016 at 6:31 PM, Marco Pivetta <ocram...@gmail.com> wrote:
> The RFC mentions "Without session_create_id(), user has to implement their
> own bin_to_readable() in user land.".
> This pretty much makes it clear that a userland implementation is feasible,
> and thus it should indeed be implemented in userland when possible.
>
> That's my reasoning for voting "no".
Thank you for sharing your idea!
> This pretty much makes it clear that a userland implementation is feasible,
> and thus it should indeed be implemented in userland when possible.
Actually, it's not with C written 3rd party session save handlers.
Properly written save handlers should have internal s_validate_sid()
function to check session ID collisions. User script cannot access to
save handler internals. Therefore, it requires a lot of work if user
try to create session ID properly. i.e. Validate generated session ID
string does not collide.
There is API design issue also.
Let's say we add
string str_bin2readble(string $binary, int $bis_per_char);
then we need
string str_reable2bin(string $readble_bin, int $bis_per_char);
Internal bin_to_reable() function is not designed to reversible, i.e.
It cannot convert $readable_bin to $binary, because it does not care
trailing bits that cannot fit into a char. I need more info these
function to be reversible. i.e.
string str_reable2bin(string $readble_bin, int $bis_per_char, int
$number_of_bits_in_readble_bin);
These APIs do not look good to be usable...
I hope I explained well the reason behind to have session_create_id().
Regards,
P.S. I would like to change session_regenerate_id() accept 'prefix',
but it has 1st parameter that I would like to remove in the future.
This is the reason why I didn't change session_regenerate_id(). It
requires a lot less user code
session_rengenerate_id('myprefix-');
yet it is safe.
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
