#56 fallback error

[Dieter Steinwedel]

I've recognized that the fallback mechanism from
cookie to get doesn't work correctly. The created
session always works, but sometimes the mechanism
fallsback to "get" on session creation on browser with
cookie support.

The source of this behaviour may be "release_token()"
and/or "get_id()" in "session.inc".

Dieter

[Gaetano Giunta]

Logged In: YES
user_id=114789

My 2 eurocents of analysis: it depends on session.inc, function
release_token, line 406 (in release 7.4rc1): mode is set to
fallback.

This looks unnecessary (and if your'sure all your users
have cookies enabled just comment the line and all will be smooth), but it
stems from a logic problem: if a page is hit by the browser and there's no
cookie found containing the session id, there's no (easy) way that PHPLIB
can possibly know if it is the first time that the page was hit and the
session cookie has yet to be set, or if it is the second time that the page is
hit and the cookie is not working, so session should switch to fallback
mode. To make sure it gets it right, phplib adds the session id in the URL,
although it looks a bit nasty to the end user.

An (hard and long ?) way to
do it could be storing in the db container the session info on the first page
hit, before redirecting the user. This way the second page hit would find
the session id already defined in the db and know that if no cookie is there
it should fall back to get mode and try a second redirect including the
session id in the url...

Hope this helps a bit (and maybe even gets
implemented in verion 8 or someting...)
Gaetano

[Gaetano Giunta]

Logged In: YES
user_id=114789

DOH! I think the final suggestion in my previous post
is BULL$#!^: on the
second load of the page you will NOT get back a session id from the browser,
so you can't match it in the database!

Anyway, the brilliant idea to
solve the problem is here:
1st hit: set cookie, reload adding GET
params
2nd hit: if no cookie found continue using GETs, else
reload,
eliminating GET params
3rd hit: you're OK now, sure to get the
cookie

the tradeoff is a slightly slower load-time of 1st-page-of-
session, your take...

the patch to session.inc I just posted here
(see the patches section)

[Nobody/Anonymous]

Logged In: NO

I think this could be related to the web-server.
I have the same error using IIS4, but everything is working fine
with Apache 1.3.24, though I'm using the same PHPLIB
version (7.2d).
I think they treat HTTP_COOKIE_VARS in different ways.
MaRu

[Giancarlo Pinerolo]

Logged In: YES
user_id=163488

The latest session.inc from the php-lib-stable cvs solves
the id creation: you cannot pass a non-existent id in the
URL anymore, nor force a cookie enabled browser to accept
it. It is not part of the tarball yet.

This problem is twofold though.
A)The arbitrary id creation, B)the fallback mode, entered
when cookies enabled.
The latest session.inc solves the arbitrary id creation (no
more a non existent ID in the URL will be created).
This behaviour can be determined by a session flag,
block_alien_sid (default true).

But the forceable fallback mode (B) can still be imposed, if
a preexistent ID is passed via URL.

Example (prerequisite is cookie enabled, no previous cookie
received):

1.User A gets a session via cookie. He appends that
regularly created session ID to an URL, and passes it to
User B, who has cookies enabled (and no prevous cookie
received).

2.User B is forced to enter get mode, and acquires the
session created by User A, because this already exists, as
it was regularly vreated by User A

The new session.inc, so, solves only part of the problem,
but a big part.
If User A wants to inject a 'known id' to User B, he can
still do it, but when that session really expires, User A
has to restart the trick again: create a new session and
find a way to pass it again it to User B.
With things as they were before, User A could rely on the
fact that User B would click again and again on the same
link, and it would be recreated, even if no more existent
because garbage collected.
Now things are more difficult, the malicious horse has only
three legs, it still can walk, but not how and where it did
before.

To complete closing this weakness we could block any 'mode
shift' witin the same session. I call this 'session
coherence'.
By making persistent within the session the 'mode', as soon
as we know it, session.inc could block any mode change
within the same session. So if User A creates his id in mode
cookie, this session would be blocked when, passed to User
B, is found into 'get' mode.
With this missing second part, passing session ID to User B
would only be possible in the case that both User A and User
B have cookies disabled. Which, in my opinion, is a better
interpretation of 'fallback mode'.

HIH

Gian