Hi Stats, 2011/12/4 Stas Malyshev <smalys...@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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
