>> >> I was just pointing out that 'use_strict_mode' shouldn't change the
>> >> behavior of session_id().
>> >> In other words, you don't need a "force" option, because passing a
>> >> custom made ID by itself already tells it to force something.
>> >
>> > Change has been done already. It does not accept uninitialized ID when
>> > use_strict_mode=On since 5.5.
>>
>> I know that. I'm saying it should work like you suggested without the
>> need of another option.
>>
>> session_id(<user input>); // changes session ID to the user-supplied
>> string, regardless of use_strict_mode
>>
>
> You may be referring old RFC. Current RFC is
>
> Add optional $force_id parameter for session_id() to allow any id regardless
> of this mode.
>
> bool session_id(string $new_id [, bool $force_id=FALSE]);
>
> This was changed as Stas(?) suggested since I agree to him. It would be more
> secure
> than old one.
I am not referring to an old RFC, I'm saying this parameter is pointless.
What difference does it make at all? How does session_id() work with
and without it?
>> >> Don't know why you're talking about prefixes here ... nothing to do
>> >> with security.
>> >
>> >
>> > I see many codes that uses insecure session ID. The main reason why
>> > they write such bad code is 'lack of secure ID generation feature'.
>> >
>> > It's security matter, IMHO.
>>
>> Why is that necessary at all? session_regenerate_id() not sufficient?
>> Either way, this shouldn't be a part of this RFC.
>>
>> It's your RFC, but still - it's about changing default settings for
>> improved security, not new features.
>
>
> You are ignoring the fact that there is no 'default' function that is
> securely generates random bytes/ID.
>
> There are code that requires prefix for much efficient session data
> handling.
> For example, user may want to know session creation time/owner/etc
> *without reading* session data. With prefixed session ID, creation
> time/owner/etc
> is known just selecting session ID names. For databases like PostgreSQL
> which
> supports function index, searching specific session is done in msec order
> even
> when there are millions of session IDs.
I'm not ignoring anything, I'm just saying this should be in a separate RFC.
>> Because, as I said above - I thought this RFC was about changing
>> default settings and nothing else.
>> And again, an underscore *is not* a part of the hash, regardless of
>> hash_bits_per_character.
>>
>> I personally don't care about the prefix. It's just that it's a
>> completely new feature that has nothing to do with the default
>> settings and it's just confusing that you mention it in the same
>> context. :)
>
>
> It's new for PHP, but there are codes do this and many of them are
> insecure...
> I would like to eliminate insecure code by introducing easy to use API also.
>
> I might have chosen wrong name for the RFC.
See my previous comment above.
You didn't chose a wrong name, you seem to have done a 2-in-1 RFC and
that's not the right approach IMO. At the very least - it's obviously
confusing and most of what you've said in this conversation isn't
described in the RFC at all.
Cheers,
Andrey.