Re: [cgiapp] CGI::Session trouble

[Michael <suppressed>]

Gabor Szabo wrote:
> Hi,
>
> I am not sure what is the source of the problem, I hope someone
> can point me to a good solution.
>
> I'am using the CA:Plugin::Session and using Class::DBI with SQLite.
>
> As I'd like to use the SQLite database to hold the session
> data in cgiapp_init I have this code:
>
>   my $dbh = MyDBI::db_Main();
>
>
>   $self->session_config(
>    CGI_SESSION_OPTIONS => [ "driver:SQLite", $self->query, {Handle => $dbh}],
>
>
> This works fine, it uses the "id" and "a_session" columns of the
> "sessions" table.
>
> The problem arises when I want to add further information to the
> "sessions" table. I'd like to be able to control how many times each user
> is logged on at the same time. (Usually that will be <= 1 as we don't
> want clients to use the same login information from multiple locations).
>
> So the issue is, how can I recognize that two browsers with two separate
> session id-s actually belong to the same user ?
> I though of adding a column "uid" to the "sessions" table and adding
> the current uid to this column. This way I can easily search the table
> for duplicate entries and take some action such as deleteing the old one.
>
> so in my login_process run mode after verifying that the correct username
> and password were provided I set the session object:
>
>    $self->session->param('loggedin' => time);
>    $self->session->param('uid' => $user->id);
>
> and then want to update the current row:
>
>
>     my $dbh = MyDBI::db_Main();
>
>     $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 ?

If it's your session id in the user table, then the problem doesn't lie 
in the session but in you dealings with your user table later in your code.

There are some problems with keeping a user not be able to have 
concurrent sessions. If they don't log out but their old session hasn't 
expired, then they can't login in. For instance, they close their 
browser and then open it up again before their session has expired in 
the sessions table. When they go to the application and try to login 
they won't be able to. This could be overcome by checking to see if 
someone has a valid session before showing the login screen and instead 
take them someplace else. This still won't work if they have somehow 
delete the cookie that stores the session or if you use query parameters 
for you session.

But, if you still want to do it I would do something like:

When trying to login, check to see if there is a current, valid session 
associated with that user id. If there is show them some warning page. 
If there isn't, save the session id in the user table.

If this is what you are doing then maybe some more code would help us to 
find the issue.

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