Yasuo Ohgaki wrote:
2011/12/2 Daniel K. <d...@uw.no>:
Yasuo Ohgaki wrote:
2011/12/2 Yasuo Ohgaki <yohg...@ohgaki.net>:
Search for a + followed by only tabs or spaces. Empty lines should be
just that, empty.
Does CODING_STANDARDS mention this?
I hope not, this should be obvious.
Since Daniel mentioned that he cannot disable strict session,
I did no such thing. from where did you get that idea?
Because you wrote this.
You cut out the essential lines before:
It removes session read failure retry code from
php_session_initialize() . The retry code may cause infinite loop
depending on save handler implementation. Some session save handlers
may be using this to prevent adoption(?)
I do not believe this could have been used as you speculate. The retry
logic kicks in when PS_READ_FUNC() fails _and_ additionally sets
PS(invalid_session_id)
Where I proposition that the existing logic (which you removed in your
patch) could not have done any looping. Because, then the code below
would not have worked.
This could never work with:
session_id("foo");
session_start();
could it?
No code in PHP sets PS(invalid_session_id) in PS_READ_FUNC(), so this
must have been added for the benefit of external modules once upon a time.
However, the current code seems to never have worked for anyone.
If we suppose that it exists an external session module which sets
PS(invalid_session_id) in PS_READ_FUNC(), the above sequence of
session_id("foo"); session_start(); would have left you with a NULL
session_id, then a new one would have been created after goto new_session.
I hope someone would have discovered this had they actually implemented
such a module.
I take this as a sign that no such module exists, but I may of course be
wrong in that.
I am in serious doubt as to whether the additonal restrictions on valid
characters in session ids are appropriate, and I fear that some poor sod may
be in for a nasty surpris because of this.
Remember, this is not just about the return value of hash functions, as this
is used to validate session_ids set with session_id() as well.
With strict session, user cannot set session ID. If user can, it's not
a strict session, but adoptive.
If by 'user' you mean any PHP script, I disagree.
The purported goal of the patch was to thwart attempts to choose ones own
session_id by sending fake/stale cookies. To also make session_id() unusable
from PHP scripts, or to thwart the script-writers ability to choose the
session_id seems like a serious bug.
If user would like to use adoptive session, user may set
session.use_strict_mode=0.
Of course, but I think we need to find out the semantics, and the expected
use case / protection level this new feature is supposed to have.
With my current understanding of the patch, and my use of PHP, it seems
mostly useless. But, I stress again that I have just read the code, I have
not actually used it yet.
Daniel K.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
