Re: Strict session?

Yasuo Ohgaki wrote:

2011/12/2 Daniel K. <dk@uw.no>:

Yasuo Ohgaki wrote:

2011/12/2 Yasuo Ohgaki <yohgaki@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.