[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