[pmwiki-users] Session Erors and UserAuth2

IchBin weconsultants at gmail.com
Mon May 21 10:22:15 CDT 2007


ThomasP wrote:
> On Sun, May 20, 2007 19:14, IchBin wrote:
>> Sorry Thomas I have to look into it closer. I have not had time to play
>> around with it. I would guess that something had to be persisted to see
>> this behavior for maintaining information between sessions(). With
>> little knowledge I will speculate:
>>
>> It seems there are three pieces to this puzzle:
>>
>>    1 - session.save_path
>>    2 - the actual physical location of the saved session.
>>    3 - more importantly the index\pointer to that saved session:
>> (sess_9af2e42745051da48fab511b67112ac7)
>>
>>
>> I would think that 1 and 2 are indirectly the problem.  Since the
>> default session.save_path points to a different place then where you
>> save your session information it has to be storing the session id
>> somewhere else or it would have not know about
>> sess_9af2e42745051da48fab511b67112ac7.
>>
>> So as far as I can tell I just need to find out where, under Windows,
>> does PHP saved this index information. Do thy save it in the windows
>> temp area (not the session.save_path, this is just the path to the data)
>> or maybe in the registry.
>>
>> I think this maybe the right way to resolve...? I'm a beginner with PHP
>> so take this with a grain of salt but will try to resolve.
>>
>> Does this make sense?
>>
> 
> I see now (-- at least I think so). The key point is: The session id which
> is manufactured by PHP into the filename
> 'sess_9af2e42745051da48fab511b67112ac7' is taken from the session cookie!!
> 
> How it works: when a session is created on the server side, its data is
> stored with under a (hopefully) unique id on the server. Now to convey to
> the client what id had been used, a cookie is transfered to it upon
> outputing the HTML, usually as part of the header information. Then on a
> subsequent page request by the client, the client browser in turn takes
> this cookie and sends it to the server, and by this the server knows which
> session to load for this particular client. (*)
> 
> This means: the above file name is constructed by PHP from the session
> cookie it has received from the client. This cookie might exists on your
> browser even if you would have executed a 'rm -r *' on your server. It
> tries to look for the corresponding session file (in which all session
> data is saved), but can't find it since the session path is not existent.
> 
> Try
> 
> session_save_path("C:/tmp"); // or
> session_save_path("C:/windows/temp");
> 
> somewhere near the beginning of your local config.php. That should be
> working, unless ... well, unless there is a deeper problem that I haven't
> yet imagined.
> 
> Let's see whether that was it.
> 
> Thomas
> 
> (*) [Admittedly, it took me some while to figure out how session work as
> well, since it is not documented on www.php.net]

It looks like PHP is not complaining about the session as much as the 
subdirectory. Once it has a real subdirectory, even with no stored 
sessions, the error is resolved. But now with pmWiki every time I edit 
and save I have to re-enter the password.

- The session.save_path was always blank. I never gave it a path and 
still does not have a path.
- Running from Opera (9.21 build 8776) it knows of no cookies.
- I have to add a session.save_path to all of the scripts that use 
session(). I could add a real subdirectory to the PHP.ini entry for 
session.save_path.

The problem I have is where is PHP storing this session information if 
it is not storing them in a browser cookie?

Why is pmWiki not remembering the admin password so I do not have to 
enter it every time I edit or save now?

-- 
Thanks in Advance...           http://weconsulting.org
IchBin, Philadelphia, Pa, USA http://ichbinquotations.weconsulting.org
______________________________________________________________________
'If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor, Regular Guy (1952-)






More information about the pmwiki-users mailing list