Re: [cgiapp] CGI::Session trouble

[Michael <suppressed>]

Gabor Szabo wrote:
> On Tue, 2 Nov 2004, Michael wrote:
>
>
> > >    $dbh->do("UPDATE users SET session=? WHERE id=?",
> > >            undef,
> > >            $self->session->id, $user->id);
> > >
> > > This seems to work as if I check immeditely afterwords I can see
> > > the data updaed but then by the time the web page shows up the
> > > database is updated again and the extra dat I UPDATE-ed disappears.
> >
> > I'm not sure what you mean by 'I can see the data updated'. What data?
> > the user id in the session? or the session id in the user table ?
>
>
> OK, I see I managed to confuse you. Sorry for that. I sent the wrong code.
> Here is the correct one:
>    $dbh->do("UPDATE sessions SET uid=? WHERE id=?",
>            undef,
>            $user->id, $self->session->id);

yeah, that makes more sense. :)

> Actually the code I sent is the workaround I wrote:
> Instead of keeping the user id in the session table now I keep the
> session id in the user table. Then every time the same user
> with a different session id tries to login I put the new session id
> in the users table. I also delete the entry from the session table that
> has this session id.
>
> This has the effect that if a user tries to login from a second
> browser s/he will be able to login seemlessly but the previous session
> will be dropped.

That's a pretty good way of handling it.

> Now this is the workaround I implemented but I consider this to be only
> a workaround as this really restricts to one user.
>
> I think it would be preferable if I could keep the user id in the
> sessions table.

I wouldn't add extra columns to the session table. CGI::Session is going 
to be using it and I expect that it's the cause of your problems. 
Somehow it's erasing what you put in. I would just add it using 
$session->param('uid') and then check that value. This does however have 
the side effect of not being able to reference this value directly in 
SQL (since all session data is serialized)


> My guess is that the session updates this table with the cached data
> when it finishes creating my page but in the cached information it
> does not have the uid yet.

I would agree. CGI::Session knows nothing about any extra columns. 
Setting $session->param('uid') will not put that info in the 'uid' 
column of the sessions table. It will go into the 'a_sessoin' column as 
part of the serialized data.

I still don't know why it clears out the value you put in with SQL into 
the sessions table since the docs say this...

    You can also add any number of additional columns to the table,
    but the above "id" and "a_session" are required.

I would venture to say that you can call $session->flush after using it, 
 set $session = undef; there by causing it to go away and not affect 
the database anymore for that request, and then call your SQL that would 
update the table, that sounds like a pretty bad hack. If you have some 
time, I would poke around the CGI::Session and CAP::Session code and try 
and find out what's going on. Sounds like it could affect others in the 
future as well.

HTH

--
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed