Re: Strict session?
| From: | Yasuo Ohgaki | Date: | Sun, 04 Dec 2011 08:19:58 +0000 |
| Subject: | Re: Strict session? | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-56744@lists.php.net to get a copy of this message | ||
Hi Stats,
2011/12/4 Stas Malyshev <smalyshev@sugarcrm.com>:
>> If user really want to set session ID, they can explicitly disable
>> use_strict_mode.
>>
>> For almost all application, setting static ID is bad code. There are
>> some applications that exploit adoptive session, but they can live
>> with new code also.
>
>
> I'm not sure I understand - why prohibiting the setting of the session ID is
> necessary? I understand the idea of the original patch - if somebody could
> set your session ID for you, without knowledge of either the user or the
> app, it is bad since third party knows this ID and thus can use it. However,
> I do not understand why it is bad for the app to set the session ID - after
> all, session ID comes from the app anyway, what's the problem here? Why we
> have to deny benefits of the protection that this patch claims to provide
> against injecting session by the third party to the applications that set
> the session from inside? I do not understand the link between one and the
> other, can you please explain?
For example, it is easy to find cases with google code search, that
users are setting ID while they really should do is
session_regenerate_id(). These kind of mistakes would be better to be
prevented under strict mode, IMHO.
We can say, shooting your own foot is your responsibility, but I think
raising error would be more user friendly.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net