cgi-session-user — CGI::Session users mailing list

[Cgi-session-user] CGI-Session-4.10 released

[Sherzod R. <she...@ha...>]

All the tests passed for me also.

I updated my CGI::Session installation in my production environment, all
the sites are still functional :)

I just released CGI-Session-4.10. Please take a look and see if
everything went OK this time.

The next time, Mark, feel free to initiate new releases. You guys don't
have to wait for me. Doing so may delay things, unfortunately :-(.

Thanks for everybody for great job done!

--  
Sherzod Ruzmetov

Re: [Cgi-session-user] Re: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

Patch has been applied to svn with notes made in the driver's pod and 
the Changes file. Also, I made name an instance method. Please run all 
of the tests. If everything works fine, I think we're ready for a new 
release.

Thanks,
Matt LeBlanc

Mark Stosberg wrote:
> That works for me. The Sqlite driver is new, and I doubt this will
> affect many people at all. 
>
> I think a clear message about the behavior change in the 'Changes' file
> is sufficient, along with making sure the POD is updated as well.
>
> 	Mark
>   

Re: [Cgi-session-user] Re: Security issue about CGI::Session

[Mark S. <ma...@su...>]

On Thu, Mar 23, 2006 at 03:38:26PM -0600, Matt LeBlanc wrote:
> My current opinion on the matter is that we do away with a default 
> location for the sqlite database file. Neither the mysql nor postgresql 
> drivers have this behavior and providing a default location just 
> encourages an unsafe practice.

That works for me. The Sqlite driver is new, and I doubt this will
affect many people at all. 

I think a clear message about the behavior change in the 'Changes' file
is sufficient, along with making sure the POD is updated as well.

	Mark

Re: [Cgi-session-user] Re: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

My current opinion on the matter is that we do away with a default 
location for the sqlite database file. Neither the mysql nor postgresql 
drivers have this behavior and providing a default location just 
encourages an unsafe practice.

-Matt

Julien Danjou wrote:
> I did not know that, so my way of fixing the problem is totally wrong,
> in this way. If having an empty file confuses DBI, that's the not good
> path to follow.
>
> Another way to fix this, also suggested by Joey, would be to create a
> directory under $TmpDir (if no full path is given) owned by the user.
>
> The idea is the following (this not real Perl code):
>
>  ! -d /tmp/sqlite-$user && mkdir /tmp/sqlite-$user
>  if(-d /tmp/sqlite-$user)
>  {
>    checkOwnerOfThisDirectory() or die "Directory owned by someone else?"
>    chmod 0700 /tmp/sqlite-$user or die "Unable to chmod, directory owned
>                                       by someone else?";
>    DataSource = /tmp/sqlite-$user/sqlite.db;
>  }
>
> Just keep in mind that you don't want to write directly to /tmp as
> someone could have created another sqlite database here.
>
> There could be other and best way to fix it, but I don't have any other
> in mind for now.
>
> Cheers,
>   
   

Re: [Cgi-session-user] Re: Security issue about CGI::Session

[Julien D. <ju...@da...>]

On Thu, Mar 23, 2006 at 04:04:28PM -0500, Mark Stosberg wrote:
> > 2) No, we shouldn't. In my experience with DBD::SQLite, if a file exist=
s=20
> > and it is not recognized by DBD::SQLite as being a sqlite database, a=
=20
> > valid database handle is not created.

I did not know that, so my way of fixing the problem is totally wrong,
in this way. If having an empty file confuses DBI, that's the not good
path to follow.

Another way to fix this, also suggested by Joey, would be to create a
directory under $TmpDir (if no full path is given) owned by the user.

The idea is the following (this not real Perl code):

 ! -d /tmp/sqlite-$user && mkdir /tmp/sqlite-$user
 if(-d /tmp/sqlite-$user)
 {
   checkOwnerOfThisDirectory() or die "Directory owned by someone else?"
   chmod 0700 /tmp/sqlite-$user or die "Unable to chmod, directory owned
                                      by someone else?";
   DataSource =3D /tmp/sqlite-$user/sqlite.db;
 }

Just keep in mind that you don't want to write directly to /tmp as
someone could have created another sqlite database here.

There could be other and best way to fix it, but I don't have any other
in mind for now.

Cheers,
--=20
Julien Danjou
// <ju...@da...>     http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// Ferns will rule the world.

Re: [Cgi-session-user] Re: Security issue about CGI::Session

[Mark S. <ma...@su...>]

Comments below. 

> Mark Stosberg wrote:
> >On Thu, Mar 23, 2006 at 12:42:18PM -0600, Matt LeBlanc wrote:
> >  
> >>Mark and Sherzod, shouldn't we create the session table if we create the 
> >>database file?
> >>    
> >
> >I just read what "O_CREAT" does. I  think we should remove this flag. We 
> >don't create the the database and table for any of the SQL drivers, so
> >why do it here? 

On Thu, Mar 23, 2006 at 02:10:56PM -0600, Matt LeBlanc wrote:
> Mark,
> 
> If we remove O_CREAT, we might as well remove O_EXCL because O_EXCL does 
> nothing without O_CREAT. If we do that, then this entire exercise 
> becomes sort of moot.
> 
> To get down to what we need, let's consider a few things:
> 
> 1) Do we want to create databases that don't exist or should we just 
> error out in those particular cases?
> 2) If we don't create the database, should we really limit the user from 
> using symlinks for the database file?
> 
> My opinions on the matter are thus:
> 1) Error out.
> 2) No, we shouldn't. In my experience with DBD::SQLite, if a file exists 
> and it is not recognized by DBD::SQLite as being a sqlite database, a 
> valid database handle is not created. Also, I can think of several cases 
> where one might want to have a symlink for a sqlite database.

I agree with you Matt. Your suggestions are consistent with how we treat other
database backends, which is that the creation of the database and the session table
is /not/ handled by CGI::Session. 

I think we've had some confusion because each of understood some part of the issue, 
but I don't think we've all been clear about it until now!

	Mark

Re: [Cgi-session-user] Re: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

Mark,

If we remove O_CREAT, we might as well remove O_EXCL because O_EXCL does 
nothing without O_CREAT. If we do that, then this entire exercise 
becomes sort of moot.

To get down to what we need, let's consider a few things:

1) Do we want to create databases that don't exist or should we just 
error out in those particular cases?
2) If we don't create the database, should we really limit the user from 
using symlinks for the database file?

My opinions on the matter are thus:
1) Error out.
2) No, we shouldn't. In my experience with DBD::SQLite, if a file exists 
and it is not recognized by DBD::SQLite as being a sqlite database, a 
valid database handle is not created. Also, I can think of several cases 
where one might want to have a symlink for a sqlite database.

-Matt


Mark Stosberg wrote:
> On Thu, Mar 23, 2006 at 12:42:18PM -0600, Matt LeBlanc wrote:
>   
>> Mark and Sherzod, shouldn't we create the session table if we create the 
>> database file?
>>     
>
> I just read what "O_CREAT" does. I  think we should remove this flag. We 
> don't create the the database and table for any of the SQL drivers, so
> why do it here? 
>
> 	Mark
>   

[Cgi-session-user] Re: Security issue about CGI::Session

[Julien D. <ju...@da...>]

On Thu, Mar 23, 2006 at 12:42:18PM -0600, Matt LeBlanc wrote:
Hello Matt,

> Thanks for the patch. I have two questions, though.
>=20
> 1) Wouldn't this attempt to create a file of the form=20
> "dbi:SQLite:dbname=3Dfile_we_should_be_checking"

Oops, after re-reading, I did not see that DataSource was overwritten.
The sysopen() should be juste before the unless block {}, 2 lines above,
I guess.

> 2) Shouldn't you be checking the return of sysopen?

Probably ; this patch is not probably totally usable, that's mainly a
proof of concept. :-)

> Anyway, I've committed a patch to pull the filename back out of the dsn,=
=20
> check for a symlink, and create the file if it doesn't exist.

Seems perfect.

Thanks,
Cheers,
--=20
Julien Danjou
// <ju...@da...>     http://julien.danjou.info
// 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
// Tomorrow I was nothing, yesterday I'll be.

Re: [Cgi-session-user] Re: Security issue about CGI::Session

[Mark S. <ma...@su...>]

On Thu, Mar 23, 2006 at 12:42:18PM -0600, Matt LeBlanc wrote:
> 
> Mark and Sherzod, shouldn't we create the session table if we create the 
> database file?

I just read what "O_CREAT" does. I  think we should remove this flag. We 
don't create the the database and table for any of the SQL drivers, so
why do it here? 

	Mark

[Cgi-session-user] Re: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

Julien,

Thanks for the patch. I have two questions, though.

1) Wouldn't this attempt to create a file of the form 
"dbi:SQLite:dbname=file_we_should_be_checking"
2) Shouldn't you be checking the return of sysopen?

Anyway, I've committed a patch to pull the filename back out of the dsn, 
check for a symlink, and create the file if it doesn't exist.

Mark and Sherzod, shouldn't we create the session table if we create the 
database file?

Thanks,
Matt LeBlanc

Julien Danjou wrote:
> Please, could you test the patch attached ?
> It is pretty small and I think you'll understand the underlaying
> concept. :-)
>
> If it does not work, I'll try to fix it another way. So if you could
> send me a little program to test it, I would not have to annoy you to
> test another patch.
>
> Regards,
>   
> ------------------------------------------------------------------------
>
> diff -ru CGI-Session-4.09/lib/CGI/Session/Driver/sqlite.pm libcgi-session-perl-4.09/lib/CGI/Session/Driver/sqlite.pm
> --- CGI-Session-4.09/lib/CGI/Session/Driver/sqlite.pm	2006-03-17 06:03:45.000000000 +0100
> +++ libcgi-session-perl-4.09/lib/CGI/Session/Driver/sqlite.pm	2006-03-23 10:16:33.000000000 +0100
> @@ -10,15 +10,18 @@
>  
>  # @CGI::Session::Driver::sqlite::ISA        = qw( CGI::Session::Driver::DBI );
>  $CGI::Session::Driver::sqlite::VERSION    = "1.4";
> +$CGI::Session::Driver::sqlite::UMask       = 0660;
>  
>  sub init {
>      my $self = shift;
>  
> +    $self->{UMask} = $CGI::Session::Driver::db_file::UMask unless exists $self->{UMask};
>      $self->{DataSource} ||= File::Spec->catfile( File::Spec->tmpdir, 'sessions.sqlt' );
>      unless ( $self->{DataSource} =~ /^dbi:sqlite/i ) {
>          $self->{DataSource} = "dbi:SQLite:dbname=" . $self->{DataSource};
>      }
>  
> +    sysopen(DATASOURCE, $self->{DataSource}, O_RDWR|O_CREAT|O_EXCL, $self->{UMask}) unless $self->{Handle};
>      $self->{Handle} ||= DBI->connect( $self->{DataSource}, '', '', {RaiseError=>1, PrintError=>1, AutoCommit=>1});
>      unless ( $self->{Handle} ) {
>          return $self->set_error( "init(): couldn't create \$dbh: " . $DBI::errstr );
>   

RE: [Cgi-session-user] FW: Security issue about CGI::Session

[Sherzod R. <she...@ha...>]

All the tests passed for me with Berkeley DB 4.1.25, and DB_File.pm
1.806

> -----Original Message-----
> From: cgi...@li... 
> [mailto:cgi...@li...] On 
> Behalf Of Matt LeBlanc
> Sent: Wednesday, March 22, 2006 5:12 PM
> To: cgi...@li...
> Subject: Re: [Cgi-session-user] FW: Security issue about CGI::Session
> 
> 
> All right gang,
> 
> I've added O_NOFOLLOW to pretty much any and all file 
> operations for the 
> file and db_file drivers. O_EXCL|O_CREAT is used to create 
> files. There 
> are also two new symlink tests to make certain the drivers 
> don't follow 
> any symlinks and remove symlinks before writing to session files. 
> Hopefully, this ends this series of bugs.
> 
> Btw, if you have svn access, please test the db_file driver. I was 
> getting some fairly odd issues when using O_NOFOLLOW and an older 
> version of Berkeley DB. (upgrade fixed it)
> 
> Thanks,
> Matt LeBlanc
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking 
> scripting language that extends applications into web and 
> mobile media. Attend the live webcast and join the prime 
> developer group breaking into this new coding territory! 
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Cgi-session-user mailing list Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

All right gang,

I've added O_NOFOLLOW to pretty much any and all file operations for the 
file and db_file drivers. O_EXCL|O_CREAT is used to create files. There 
are also two new symlink tests to make certain the drivers don't follow 
any symlinks and remove symlinks before writing to session files. 
Hopefully, this ends this series of bugs.

Btw, if you have svn access, please test the db_file driver. I was 
getting some fairly odd issues when using O_NOFOLLOW and an older 
version of Berkeley DB. (upgrade fixed it)

Thanks,
Matt LeBlanc

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Kenneth P. <sh...@se...>]

On Tuesday, March 21, 2006 5:00 PM -0600 Matt LeBlanc <mle...@cp...> 
wrote:

> Good point. I've submitted yet another patch that checks to make certain
> the file opened is not a symlink.

You might want to look at source to mkstemp(3) to see if there's any other 
conditions to worry about.

[Cgi-session-user] V 4.09 and format of sessions in database

[Ron S. <ro...@sa...>]

Hi Folks

After storing a session in a (MySQL) database, it's format is:

$D = {...};;$D

where the real contents are represented by '...'.

Ummm, but what are the last 4 characters doing there?

Anybody else seeing this?
--
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

Kenneth,

Good point. I've submitted yet another patch that checks to make certain 
the file opened is not a symlink.

Now that I've reread the documentation for sysopen, it seems O_EXCL is 
only effective if it's paired with O_CREAT. I've verified that 
O_RDONLY|O_EXCL follows symlinks on three operating systems. Anyway, I'm 
currently writing new tests to make certain the file and db_file drivers 
protect against symlinks.

Thanks,
Matt LeBlanc

Kenneth Porter wrote:
> On Tuesday, March 21, 2006 2:17 PM -0600 Matt LeBlanc 
> <mle...@cp...> wrote:
>
>> This is why the code now checks for symlinks prior to opening the file
>> for writing and attempts to delete the file and returns an error if
>> failing the deletion.
>
> Don't you still have a window of vulnerability between the delete and 
> create when a malicious local process could recreate the symlink?
>

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Kenneth P. <sh...@se...>]

On Tuesday, March 21, 2006 2:17 PM -0600 Matt LeBlanc <mle...@cp...> 
wrote:

> This is why the code now checks for symlinks prior to opening the file
> for writing and attempts to delete the file and returns an error if
> failing the deletion.

Don't you still have a window of vulnerability between the delete and 
create when a malicious local process could recreate the symlink?

Re: [Cgi-session-user] FW: Security issue about CGI::Session

[Matt L. <mle...@cp...>]

Sherzod,

Just to make this public for why I applied things the way I did, I 
decided not to include O_EXCL in sysopen for the file driver's store 
method specifically because the file is quite likely to already exist 
(ie the next time the person returns to your site). This is why the code 
now checks for symlinks prior to opening the file for writing and 
attempts to delete the file and returns an error if failing the 
deletion. If we wish to use O_EXCL on all sysopen calls, we can delete 
the file prior to writing. However, this is a suboptimal solution if we 
proceed with the flush-by-default in param strategy.

Now for the db_file driver. For storage, this one has the same deal. The 
database is created in a file and we would rather have it stay around so 
using the O_EXCL flag creates problems. We protect against symlinks by 
deleting the literal symlink and, failing deletion, returning an error. 
Using O_EXCL for the lockfile would be ok if we could guarantee that it 
never exists, which we cannot (since we want to wait on the lock and not 
fail on the open). Thus all of these cases are protected by symlink 
checks which was the reason to use O_EXCL in the first place. I 
temporarily excluded O_EXCL from retrieve in db_file in the last release 
to pass tests (a pretty stupid mistake slipped through for 4.08) but the 
symlink checks are still in effect for retrieve as well. The fix has 
been committed and the next release will have O_EXCL for retrieve.

On the subject of the sqlite driver, we have no control over the 
creation of the sqlite database used with the sqlite driver. Perhaps we 
should add a note to the driver's pod that due diligence should be taken 
when creating the sqlite database and setting the database file's 
permissions?

Thanks,
Matt LeBlanc

Sherzod Ruzmetov wrote:
>   
>> -----Original Message-----
>> From: Julien Danjou [mailto:ju...@da...] 
>> Sent: Monday, March 20, 2006 12:27 PM
>> To: Sherzod Ruzmetov
>> Subject: Security issue about CGI::Session
>>
>>
>> Hello,
>>
>> I just saw you released 4.09, fixing security holes.
>> However, it seems that at least the "file" driver is still 
>> vulnerable, since it does not use the O_EXCL flag. What do you think ?
>>
>> Do you plan to fix this and the sqlite holes ?
>>
>> Regards,
>> -- 
>> Julien Danjou
>> // <ju...@da...>     http://julien.danjou.info
>> // 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
>> // I'm no superman.
>>
>>     

[Cgi-session-user] FW: Security issue about CGI::Session

[Sherzod R. <she...@ha...>]

> -----Original Message-----
> From: Julien Danjou [mailto:ju...@da...] 
> Sent: Monday, March 20, 2006 12:27 PM
> To: Sherzod Ruzmetov
> Subject: Security issue about CGI::Session
> 
> 
> Hello,
> 
> I just saw you released 4.09, fixing security holes.
> However, it seems that at least the "file" driver is still 
> vulnerable, since it does not use the O_EXCL flag. What do you think ?
> 
> Do you plan to fix this and the sqlite holes ?
> 
> Regards,
> -- 
> Julien Danjou
> // <ju...@da...>     http://julien.danjou.info
> // 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
> // I'm no superman.
> 

[Cgi-session-user] Re: Potential security problems with CGI::Session (addressed with 4.08 release)

[Mark S. <ma...@su...>]

CGI::Session 4.08 has been released, primarily to address the issues described
below. Thanks to Matt LeBlanc and Tyler MacDonald, the primary contributors
for this release.

 * FIX: DESTROY was sometimes wiping out exception handling. RT#18183, Matt LeBlanc.
 * SECURITY: Resolve some issues in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356555
   - db_file and file now check for symlinks either explicitly or by using O_EXCL on sysopen
   - file creation umask defaults to 660
 * NEW: db_file and file drivers now accepts a UMask option. (Matt LeBlanc)
 * INTERNAL: test suite clean up (Tyler MacDonald)

	Mark

On Sun, Mar 12, 2006 at 02:19:23PM -0500, Sherzod Ruzmetov wrote:
> 
> 
> > -----Original Message-----
> > From: Julien Danjou [mailto:ju...@da...] 
> > Sent: Sunday, March 12, 2006 1:54 PM
> > To: Sherzod Ruzmetov
> > Subject: Potential security problems with CGI::Session
> > 
> > 
> > Hello,
> > 
> > I am the current maintainer of CGI-Session in Debian. Joey 
> > Hess sent me a bug report about potential security issue with 
> > your Perl module. I did not treat it yet, but I will try to 
> > as soon as possible. Your help would be welcome.
> > 
> > The corresponding Debian bug number is #356555, see: 
> > http://bugs.debian.org/356555
> > 
> > Regards,
> > -- 
> > Julien Danjou
> > // 
> > <ju...@da...>     http://julien.danjou.info
> > // 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
> > 


--
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[Cgi-session-user] FW: Potential security problems with CGI::Session

[Sherzod R. <she...@ha...>]

> -----Original Message-----
> From: Julien Danjou [mailto:ju...@da...] 
> Sent: Sunday, March 12, 2006 1:54 PM
> To: Sherzod Ruzmetov
> Subject: Potential security problems with CGI::Session
> 
> 
> Hello,
> 
> I am the current maintainer of CGI-Session in Debian. Joey 
> Hess sent me a bug report about potential security issue with 
> your Perl module. I did not treat it yet, but I will try to 
> as soon as possible. Your help would be welcome.
> 
> The corresponding Debian bug number is #356555, see: 
> http://bugs.debian.org/356555
> 
> Regards,
> -- 
> Julien Danjou
> // 
> <ju...@da...>     http://julien.danjou.info
> // 9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
> 

[Cgi-session-user] unexpect conduct after session expire

[thomas p. <th...@po...>]

Hello,

at the moment I try to understand CGI::Session, if an session expire.

I wrote follow small test programm:

-- snip --
 1 #!/usr/bin/perl -wT
 2
 3 use strict;
 4 use CGI::Carp qw(fatalsToBrowser);
 5 use CGI::Session;
 6
 7 my $session = new CGI::Session;
 8 $session->expire('10s');
 9 # output to the browser
10 print $session->header();
11 my $tmp_01=$session->dump();
12 $tmp_01=~s/\n/<br>/g;

print"
<html>
<head>
</head>
<body>
<p>".$session->header()."</p>
<p>$tmp_01</p>
</body>
</html>";
-- snap --

The Session with the ID 4b3a040a3c034455c148e3edcb7ced05 is expire, so
line 7 create a new ID (b0e5c89d4ea867511a6c5752f53238f4) and send it to
the client, see first run.

Some seconds later I recall the test programm and I expect, that the new
ID b0e5c89d4ea867511a6c5752f53238f4 is valid, line 7 should find valid
data, but the programm send a new ID fcb5d86e2aa89782fb6258f34020496b,
see second run.

Some second later I recall the programm again and I get the expected new
ID from the second run, fcb5d86e2aa89782fb6258f34020496b, line 7 found a
valid session and load the data, see third run.

Some second later I recall the programm again and I get again the ID
fcb5d86e2aa89782fb6258f34020496b, that is what I expect, see 4th run.

I don't understand, why CGI::Session don't find the valid session with
the ID b0e5c89d4ea867511a6c5752f53238f4 from the first run. CGI::Session
create a file on disk,

I try this programm with firefox 1.5 and IE 6, everytime with the same
result. Have anybody a hint for me for this results or is there a
mistake in my test programm? At the moment I must send twice data to the
server to get a valid session.

btw: I is possible to set a parameter, that a ID only is sent, if there
a SSL connection?

my first run:
-- snip --
Set-Cookie: CGISESSID=b0e5c89d4ea867511a6c5752f53238f4; path=/;
expires=Thu, 09-Mar-2006 21:37:23 GMT Date: Fri, 10 Mar 2006 21:37:23
GMT Content-Type: text/html; charset=ISO-8859-1

$CGI::Session = bless( {
'_STATUS' => 11,
'_OBJECTS' => {
'serializer' => 'CGI::Session::Serialize::default',
'id' => 'CGI::Session::ID::md5',
'driver' => bless( {
'Directory' => '/tmp',
'NoFlock' => 0
}, 'CGI::Session::Driver::file' )
},
'_CLAIMED_ID' => '4b3a040a3c034455c148e3edcb7ced05',
'_DATA' => {
'_SESSION_ETIME' => 10,
'_SESSION_ID' => 'b0e5c89d4ea867511a6c5752f53238f4',
'_SESSION_ATIME' => 1142026643,
'_SESSION_CTIME' => 1142026643
},
'_QUERY' => bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.cookies' => {
'CGISESSID' => bless( {
'value' => [
'4b3a040a3c034455c148e3edcb7ced05'
],
'name' => 'CGISESSID',
'path' => '/'
}, 'CGI::Cookie' )
},
'.fieldnames' => {},
'.header_printed' => 1,
'escape' => 1
}, 'CGI' ),
'_DRIVER_ARGS' => bless( {
'Directory' => '/tmp',
'NoFlock' => 0
}, 'CGI::Session::Driver::file' ),
'_DSN' => {
'serializer' => 'default',
'id' => 'md5',
'driver' => 'file'
}
}, 'CGI::Session' );

-- snap --

some seconds later the second run:

-- snip --
Set-Cookie: CGISESSID=fcb5d86e2aa89782fb6258f34020496b; path=/;
expires=10s Date: Fri, 10 Mar 2006 21:37:29 GMT Content-Type: text/html;
charset=ISO-8859-1

$CGI::Session = bless( {
'_STATUS' => 3,
'_OBJECTS' => {
'id' => 'CGI::Session::ID::md5'
},
'_CLAIMED_ID' => undef,
'_DATA' => {
'_SESSION_ETIME' => 10,
'_SESSION_ID' => 'fcb5d86e2aa89782fb6258f34020496b',
'_SESSION_ATIME' => 1142026649,
'_SESSION_REMOTE_ADDR' => '84.188.192.93',
'_SESSION_CTIME' => 1142026649
},
'_QUERY' => bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.cookies' => undef,
'.fieldnames' => {},
'.header_printed' => 1,
'escape' => 1
}, 'CGI' ),
'_DRIVER_ARGS' => {},
'_DSN' => {
'serializer' => 'default',
'id' => 'md5',
'driver' => 'file'
}
}, 'CGI::Session' );

-- snap --

some seconds later the third run:

-- snip --
Set-Cookie: CGISESSID=fcb5d86e2aa89782fb6258f34020496b; path=/;
expires=10s Date: Fri, 10 Mar 2006 21:37:35 GMT Content-Type: text/html;
charset=ISO-8859-1

$CGI::Session = bless( {
'_STATUS' => 2,
'_OBJECTS' => {
'serializer' => 'CGI::Session::Serialize::default',
'driver' => bless( {
'Directory' => '/tmp',
'NoFlock' => 0
}, 'CGI::Session::Driver::file' )
},
'_CLAIMED_ID' => 'fcb5d86e2aa89782fb6258f34020496b',
'_DATA' => {
'_SESSION_ID' => 'fcb5d86e2aa89782fb6258f34020496b',
'_SESSION_ETIME' => 10,
'_SESSION_ATIME' => 1142026655,
'_SESSION_EXPIRE_LIST' => {},
'_SESSION_REMOTE_ADDR' => '84.188.192.93',
'_SESSION_CTIME' => 1142026649
},
'_QUERY' => bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.cookies' => {
'CGISESSID' => bless( {
'value' => [
'fcb5d86e2aa89782fb6258f34020496b'
],
'name' => 'CGISESSID',
'path' => '/'
}, 'CGI::Cookie' )
},
'.fieldnames' => {},
'.header_printed' => 1,
'escape' => 1
}, 'CGI' ),
'_DRIVER_ARGS' => bless( {
'Directory' => '/tmp',
'NoFlock' => 0
}, 'CGI::Session::Driver::file' ),
'_DSN' => {
'serializer' => 'default',
'id' => 'md5',
'driver' => 'file'
}
}, 'CGI::Session' );

-- snap --

some seconds later the 4th run:

-- snip --
Set-Cookie: CGISESSID=fcb5d86e2aa89782fb6258f34020496b; path=/;
expires=10s Date: Fri, 10 Mar 2006 21:37:40 GMT Content-Type: text/html;
charset=ISO-8859-1

$CGI::Session = bless( {
'_STATUS' => 2,
'_OBJECTS' => {
'serializer' => 'CGI::Session::Serialize::default',
'driver' => bless( {
'Directory' => '/tmp',
'NoFlock' => 0
}, 'CGI::Session::Driver::file' )
},
'_CLAIMED_ID' => 'fcb5d86e2aa89782fb6258f34020496b',
'_DATA' => {
'_SESSION_ETIME' => 10,
'_SESSION_ID' => 'fcb5d86e2aa89782fb6258f34020496b',
'_SESSION_ATIME' => 1142026660,
'_SESSION_REMOTE_ADDR' => '84.188.192.93',
'_SESSION_EXPIRE_LIST' => {},
'_SESSION_CTIME' => 1142026649
},
'_QUERY' => bless( {
'.parameters' => [],
'.charset' => 'ISO-8859-1',
'.cookies' => {
'CGISESSID' => bless( {
'value' => [
'fcb5d86e2aa89782fb6258f34020496b'
],
'name' => 'CGISESSID',
'path' => '/'
}, 'CGI::Cookie' )
},
'.fieldnames' => {},
'.header_printed' => 1,
'escape' => 1
}, 'CGI' ),
'_DRIVER_ARGS' => bless( {
'Directory' => '/tmp',
'NoFlock' => 0
}, 'CGI::Session::Driver::file' ),
'_DSN' => {
'serializer' => 'default',
'id' => 'md5',
'driver' => 'file'
}
}, 'CGI::Session' );

-- snap --

best regards,
thomas polnik.

Re: [Cgi-session-user] Re: Serialize::yaml,json

[Tyler M. <ty...@yi...>]

Mark Stosberg <ma...@su...> wrote:
> > 	JSON and YAML serializers are in trunk as of change 249. I've logged
> > into my PAUSE account and deleted the CGI::Session::Serialize::yaml
> > distribution; it is scheduled to disappear on March 10th.
> > 
> > 	What else needs to be done for the next release of CGI::Session to
> > happen?
> Thanks for this work. I'm happy to make another release with just this
> improvement, if that helps some other project progress. 
> 
> However, I also want to continue the discussions about what to do about
> "flush()" to see if we can agree on a short-term solution for that. 
> 
> Sherzord has weighed in, and I'd like to respond further on the issue.

	Sounds good. Let me know if there's anything I can do. Apache2::AUS
still needs some more test/doc/examples before I can release it, but I don't
want to release until I can use JSON serialization by default.

	I think I missed the conversation on flush(), my mailbox has been
bombarded recently and I havent looked at everything. :) One comment about
flush() tho:

	AUS's session driver uses a table format like this with additional
metadata:

CREATE TABLE aus_session (
    id          varchar(128) NOT NULL PRIMARY KEY,
    created     TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT now(),
    time_last   TIMESTAMP WITH TIME ZONE NULL,
    user_id     INT NULL,
    a_session   BYTEA NULL,
    
    FOREIGN KEY (user_id)
        REFERENCES  aus_user (id)
        ON UPDATE CASCADE
        ON DELETE SET NULL
);

	In order to have the driver update user_id and time_last, I had to
modify flush() to pass $session to the driver's store() method. In order to
change that one line of functionality I had to copy-and-paste the entire
50-line flush method. I'd like to see flush() broken down into smaller bits;
maybe instead of having it call the driver and serializer itself,
CGI::Session could have it's own freeze/store/delete methods? By default
they'd just call the driver/serializer methods, but then subclassing becomes
easier.

	Just a thought...

	Cheers,
		Tyler


	

[Cgi-session-user] Re: Serialize::yaml,json

[Mark S. <ma...@su...>]

On Wed, Mar 08, 2006 at 10:25:54AM -0800, Tyler MacDonald wrote:
> Mark,
> 	JSON and YAML serializers are in trunk as of change 249. I've logged
> into my PAUSE account and deleted the CGI::Session::Serialize::yaml
> distribution; it is scheduled to disappear on March 10th.
> 
> 	What else needs to be done for the next release of CGI::Session to
> happen?

Tyler,

Thanks for this work. I'm happy to make another release with just this
improvement, if that helps some other project progress. 

However, I also want to continue the discussions about what to do about
"flush()" to see if we can agree on a short-term solution for that. 

Sherzord has weighed in, and I'd like to respond further on the issue.

	Mark

[Cgi-session-user] Serialize::yaml,json

[Tyler M. <ty...@yi...>]

Mark,
	JSON and YAML serializers are in trunk as of change 249. I've logged
into my PAUSE account and deleted the CGI::Session::Serialize::yaml
distribution; it is scheduled to disappear on March 10th.

	What else needs to be done for the next release of CGI::Session to
happen?

	Thanks,
		Tyler

RE: [Cgi-session-user] Trouble with C::S::SQLite

[Ron S. <ro...@sa...>]

On Wed, 8 Mar 2006 00:43:30 -0500, Sherzod Ruzmetov wrote:

Hi Sherzod

> So here is what I'm proposing. When one does:
>
> $session->param('name', 'John Doe');
>
> flush() would get called automatically from within param(), because

Note: I have never had a problem with missing data needing a flush, and I've
been very curious as to what might be causing it. Hint: I've never used such
code in a mod_perl handler.

Anyway, this proposal sounds good to me.

--
Ron Savage
ro...@sa...
http://savage.net.au/index.html