|
|
Posted by axlq on 07/30/06 17:13
In article <98e1e$44cc5d3f$8259c69c$647@news2.tudelft.nl>,
Rik <luiheidsgoeroe@hotmail.com> wrote:
>are you sure everything get's executed correctly? No notices when
>error_reporting(E_ALL)?
Good idea. No unusual notices came from error_reporting(E_ALL)
- just some instances of testing values of nonexistent variables
instead of using isset(), which doesn't affect the logical execution
of the code and isn't related to the problem at hand.
However, my testing to see if the error reporting gave any surprises
*did* clarify that the problem arises from the 'sess_deleted' files
that are left behind in my session path when logging off. It seems
that the 'sess_deleted' file is actually being used as a session ID.
Here is what seems to be wrong:
A. After logging off, re-logging in doesn't re-set the session
cookie. It persists as having the value 'deleted', which is how it
gets set after using set_cookie() with a timestamp of time()-3600 to
force the cookie to expire.
B. The session file 'sess_deleted' - which appears from
session_destroy() in the logoff script - is used as an actual
session by browsers with a 'login_settings' cookie set to 'deleted'.
Any $_SESSION values introduced by one browser become part of the
$_SESSION in all browsers.
==========
Here's what I did. The first 5 steps are set-up steps.
1. Choose two computers on my end, delete the cookies and clear the
browser cache to start fresh. I also delete any session files in my
session_path on the server, just to make sure it's fresh on that end.
2. Computer A: I open up the Opera browser log in as a normal user.
A session cookie appears in the cookie list, and a file called
sess_99eae3b908fa57142f08f31a7eafc6c2 appeared in my session_path
when the browser first accessed the site.
3. Computer A (again): I open up the Firefox browser and log in
as a customer. A session cookie is set properly in the browser,
and a new file sess_4dd766f5f0bb86404b1e6d872e59035e appears in my
session_path.
4. Computer B: Open up the IE browser and log in as superuser.
A new file sess_92d1cd69bb176cb4167c08220af30be7 appears.
Everything fine so far. So far all three computers are working fine
independently. No surprises from E_ALL error reporting.
5. I log off computer B. The session file disappears and becomes
'sess_deleted' instead. The two browsers on computer A still behave
properly.
OK. HERE'S WERE IT GETS WEIRD.
6. I log off the Opera browser in computer A. The session file
disappears. The browser displays the non-logged-in index page,as it
should. However... there is still ONE 'sess_deleted' file, but with
a new timestamp.
7. I re-log in computer B as superuser. The superuser index page
appears, but no new session file is created! Nothing strange
appears in the E_ALL errors.
8. From computer A, I re-load the non-logged-in index page in Opera.
It loads up the superuser index page that B is seeing! Opera's
cookie manager says of the session cookie, "login_settings: deleted"
9. All this time, the Firefox browser on computer A has
been operating normally in its own session. There has been
no interference so far. Now I log off. The session file
disappears. The browser loads the superuser index page instead of
the non-logged-in index page! Firefox says of the session cookie:
Name: login_settings
Content: deleted
10. Logging off from 'superuser' from any computer logs off all
browsers. There is still one 'sess_deleted' file in my session_path
with a timestamp updated to the logoff time.
>It could also have something to do with the actual logging in/checking,
>maybe post a portion of that code.
It now seems to have everything to do with sess_deleted and session
cookies set to 'deleted'. My logoff script follows the example shown
in http://us2.php.net/manual/en/function.session-destroy.php
-A
Navigation:
[Reply to this message]
|