$dbtype = 'mysql';
$dbname = 'somedb';
$dbname = 'localhost';
$dbuser = 'username';
$dbpass = 'password';
tie %session, 'Apache::Session::MySQL', $id, {
    DataSource    => "DBI:$dbtype:$dbname:$dbhost",
    UserName    => $dbuser,
    Password    => $dbpass,
    LockDataSource  => "DBI:$dbtype:$dbname:$dbhost",
    LockUserName    => $dbuser,
    LockPassword    => $dbpass,
} or die "Can't tie the session ", %session, ": $!";
[download]

I can't find LockDataSource in Apache::Session::DBIStore anywhere. Is that a MySql specific thing?

No, actually the Lock schtuff is in there to satisfy Apache::Session's need for a lock. I just don't grok the documentation on Apache::Session, so I found that just reading through the modules gave me better insight into getting it working, and it took a while.

I didn't see a module Apache::Session::DBIStore, there is Apache::Session::Store::DBI, but that should be accessed through another module (like Apache::Session::Mysql or Apache::Session::Postgres ) as they also use the Apache::Session::Lock modules that are most appropriate.

Or at least I think so, the docs are lacking in the explaining as far as I am concerned.

EEjack

One thing that I don't like about this code is how it doesn't always clean up if something goes wrong during handling the request. I think it would be better to put your session in $r->pnotes() than in a global, because pnotes is always cleaned up at the end of the request, even if Mason dies on something. If you haven't used pnotes before, see the docs that came with mod_perl or the Guide.

$session{userid} *should* only exist if the person has a cookie from logging in. When they logout, $session{userid} is set to undef, and (as I understand it) the row in the DB is deleted. $session is a tied hash, so when someone connects they should get a new (empty) cookie if they don't have one; if they have one, then $session{userid} is whataver is stored in that.

However, apparently doing $session{userid} = undef; *does* get rid of the info in the DB, but does not keep the child from remembering the value of $session{userid}.

I don't know what's going on.

dstar (forgot to log in)

Okay, first off $session{userid} is not set anywhere in your sample code, and unless you're setting it somewhere else it will never get set to anything.

Second, there is no concept of "loggin in" and "logging out" in this code. It assigns anyone who comes along a cookie with a session ID, and creates backend storage for that session. It never makes any attempt to delete anything from the database. Are you talking about some other code that you didn't post?

There is a session ID, $session{_session_id}. Is that what you're talking about?

Note that Apache::Session stores all data as a BLOB serialized by Storable, so removing a value from the session should not cause anything to be deleted from the database, it would just update the row for that session. Values are not stored as separate rows.

#!/usr/bin/perl
use strict;
use Apache::Session::Postgres;
use CGI;


my $driver   = "Pg";
my $dbname   = "database";
my $host     = "127.0.0.1";
my $user     = "user";
my $password = "password";
my $dbh      =
  DBI->connect(
"dbi:$driver(PrintError=>1,RaiseError=>1,Taint=>1):dbname=$dbname;host
+=$host",
    $user, $password );

my $q           = CGI->new;
my $id          = $q->param('get_id');
my $visa_number = $q->param('visa_number');

tie my %hash, 'Apache::Session::Postgres', $id, { Handle => $dbh, };
if ( !$id && $visa_number ) {
    $hash{visa_number} = $visa_number;
}

use Data::Dumper;
print Data::Dumper->Dump( [%hash] );
[download]

So I added some code before the offending line:

### SDW DEBUG
    $self->{insert_sth}->trace(9, "/tmp/sessioncheck");
    open(SDW_DEBUG_OUT, ">/tmp/serial");
    print SDW_DEBUG_OUT "FOO".$serialized."BAR\n";
    close(SDW_DEBUG_OUT);
[download]

And I get:

FOO
bc6f80d5a358ae0f_session_idBAR
[download]

Note the linefeed between FOO and the start of the sessionid. The serialized data seems to start with a linefeed! Needless to say, this foobars the sql statement.

This can't be right, can it?