Yes, there are a lot of possible cases where IP addresses could be
changed frequently.
Yes, there are a lot of cases where users would be behind a NAT
gateway or a proxy.
And yes, session.match_ip wouldn't be applicable or as useful under
such conditions.
But consider an intranet environment, the future with IPv6 (even if
not that close as we'd like it to be) or just an otherwise appropriate
user base.
I agree that this feature wouldn't be suitable for your general,
public web application, but I think somebody already pointed out that
this would be useful for admin interfaces. How many applications don't
have that? There certainly are use cases.
On Sun, Jan 26, 2014 at 3:08 AM, Yasuo Ohgaki <[email protected]> wrote:
> Hi Stas,
>
> On Sun, Jan 26, 2014 at 10:00 AM, Yasuo Ohgaki <[email protected]> wrote:
>>
>> On Sun, Jan 26, 2014 at 9:44 AM, Stas Malyshev <[email protected]>
>> wrote:
>>>
>>> > which is really bad thing to do. session_create_id() generate ID using
>>> > the same code PHP generates ID which is much secure than above and
>>> > supposed to be faster than user land script.
>>>
>>> I agree that exposing the ID creation function is a good addition
>>> (actually if it was available I'd probably use it in other contexts
>>> where I need a random token, not necessarily a session ID as such).
>>> Maybe we need even more generic function and have session reuse that
>>> code, too.
>>
>>
>> Although I've written it already, I appreciate any comments for
>> improvement. Do you have idea for session_create_id()?
>> Perhaps, more generic function name and/or move to ext/standard?
>
>
> An idea for session_id().
> It would be better to allow session_id() to set SID regardless of
> use_strict_mode. It's programmer's intention.
>
> Should I make this change from 5.5? It's nicer than now.
>
> Regards,
>
> --
> Yasuo Ohgaki
> [email protected]
>