Skip Menu |
 

This queue is for tickets about the CGI-Session CPAN distribution.

Report information
The Basics
Id: 17299
Status: open
Priority: 0/
Queue: CGI-Session

People
Owner: Nobody in particular
Requestors: fabian.kainzinger [...] tngtech.com
fadius [...] gmail.com
mark [...] summersault.com
supadupa [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 3.95
Fixed in: (no value)



Subject: CGI-Session does not write files
Download (untitled) / with headers
text/plain 984b
The latest version 4.02 does not write any files with session information. After downgrading to version 3.95 everthing works fine again. Perl v5.8.3 on Linux 2.6.5-7.155.29-bigsmp Some code to reproduce this: #!/usr/bin/perl use CGI; use CGI::Session; use Data::Dumper; $cgi = new CGI; $old_id = $cgi->cookie('CGISESSID'); $session = new CGI::Session(undef, $cgi, {Directory =>'/tmp'}) or die CGI::Session->errstr; $cookie = $cgi->cookie( -name => $session->name, -value => $session->id ); print $cgi->header( -cookie=>$cookie ); print "session id:" . $session->id ."<br>"; print "old session id:" . $old_id . "<br>"; print Dumper (\$session); ############## With version 4.02 no file is written in /tmp and you get a new session id every time you reload the cgi page. With version 3.95 a file (e.g. cgisess_a5c2237d2cb3a541cdeb2c2521b08a68) is written and you get the same session id when reloading the page. Of course /tmp is writable for all.
From: guest
Download (untitled) / with headers
text/plain 1.2k
[guest - Thu Sep 15 12:56:11 2005]: Show quoted text
> The latest version 4.02 does not write any files with session > information. After downgrading to version 3.95 everthing works fine > again. > > Perl v5.8.3 on Linux 2.6.5-7.155.29-bigsmp > > Some code to reproduce this: > #!/usr/bin/perl > > use CGI; > use CGI::Session; > use Data::Dumper; > > $cgi = new CGI; > $old_id = $cgi->cookie('CGISESSID'); > > $session = new CGI::Session(undef, $cgi, {Directory =>'/tmp'}) or die > CGI::Session->errstr; > > $cookie = $cgi->cookie( -name => $session->name, > -value => $session->id ); > > print $cgi->header( -cookie=>$cookie ); > print "session id:" . $session->id ."<br>"; > print "old session id:" . $old_id . "<br>"; > print Dumper (\$session); > ############## > > With version 4.02 no file is written in /tmp and you get a new session > id every time you reload the cgi page. With version 3.95 a file > (e.g. cgisess_a5c2237d2cb3a541cdeb2c2521b08a68) is written and you > get the same session id when reloading the page. > > Of course /tmp is writable for all.
I had the same problem. 3.95 was okay, 4.03 no written files on disk with Perl 5.6.1 on Debian. However it works, when using serializer:FreezeThaw. So the problem should be within the default serializer.
Subject: session files don't get created
Download (untitled) / with headers
text/plain 934b
Perl: This is perl, v5.8.3 built for i686-linux OS: Linux 2.4.26 Apache: v1.3 session files do not get created if the line in foo() (see code below) is uncommented. Works fine when the line in foo() is commented out or when invoking the perl script from the shell (as opposed to running as CGI through apache). This has been reproduced on 2 totally independent environments... in both cases version 4.03 was used. === code starts here === #!/usr/local/bin/perl use strict; use CGI; use CGI::Session; my $query = new CGI; my $session = CGI::Session->new( "driver:File", $query, {Directory => './session'} ); # Prepare cookie with session id my $cookie = $query->cookie( -name => $session->name(), -value => $session->id() ); print $query->header( -type=>'text/html', -charset=>'utf-8', -cookie=>$cookie ,-expires=>'now' ); print "Hello World"; exit; sub foo( $ ){ $session->param('testing',"hello"); } === code ends here ===
Date: Sun, 1 Jan 2006 21:57:44 -0500
From: Mark Stosberg <mark [...] summersault.com>
To: Guest via RT <bug-CGI-Session [...] rt.cpan.org>
CC: undisclosed-recipients: ;
Subject: Re: [cpan #16861] session files don't get created
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.8k
On Sun, Jan 01, 2006 at 08:46:37PM -0500, Guest via RT wrote: Show quoted text
> > This message about CGI-Session was sent to you by guest <> via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=16861 > > > Perl: This is perl, v5.8.3 built for i686-linux > OS: Linux 2.4.26 > Apache: v1.3 > > session files do not get created if the line in foo() (see code below) is uncommented. Works fine when the line in foo() is commented out or when invoking the perl script from the shell (as opposed to running as CGI through apache). This has been reproduced on 2 totally independent environments... in both cases version 4.03 was used. > > === code starts here === > > #!/usr/local/bin/perl > > use strict; > use CGI; > use CGI::Session; > > my $query = new CGI; > my $session = CGI::Session->new( "driver:File", $query, {Directory => './session'} ); > > # Prepare cookie with session id > my $cookie = $query->cookie( -name => $session->name(), -value => $session->id() ); > print $query->header( -type=>'text/html', -charset=>'utf-8', -cookie=>$cookie ,-expires=>'now' ); > print "Hello World"; > exit; > > sub foo( $ ){ > $session->param('testing',"hello"); > } > > === code ends here ===
This is documented behavior rather than a bug. (However, since it's frequently reported, we apparently need better documentation!). The detail needed is in the documentation for flush(): http://search.cpan.org/~sherzodr/CGI-Session-4.03/lib/CGI/Session.pm#flush So, the issue is solved by calling flush() before the script exits, or having the object go out of scope before the script exits. That happens automatically when used within a web application framework such as CGI::Application or Catalyst. A patch to improve our docs would be welcome. Mark -- http://mark.stosberg.com/
Subject: No session data is saved unless $session->flush() is called.
Download (untitled) / with headers
text/plain 3.5k
I wrote a script ages ago (just checked the source) that handled sessions fine w/o using ->flush() or ->close() anywhere. It was for the debian woody release (eaisly mid 2004). I've tested this script on a few machines (omni, saturn). The use of lastpid was an attempt to see if the session was saving anything... (releases me from poking mysql on yet another terminal) When I replace END with if (0) { ... } it stops saving session data. Source snippet: #!/usr/bin/perl -w -I/home/staff/include ########################################################################### # supaplex 2006-01-11 use strict; use DBH; # internal module. works great on all our other DBI apps. use CGI; use CGI::Session; use Data::Dumper; use vars qw($session $dbh); my $cgi=new CGI; my $session; my $dbh = DBH->new('voip') or reportErrors("Cannot connect to voip database"); my $sid=$cgi->param("sid")||undef; eval { $session=new CGI::Session("driver:MySQL",$sid,{Handle => $dbh}); } or reportErrors("Session INIT error",$@); END { print STDERR "Commiting session data... "; $session->flush(); print STDERR "Done.\n"; } $sid=$session->id(); reportErrors("session failed to create or obtain an id") unless($sid); my $lastpid=$session->param("lastpid"); $session->param("lastpid",$$); my $SCRIPT=$ENV{"SCRIPT_NAME"}; $session->param("step",512); my $user = $cgi->param("search")||''; my $error =$cgi->param("error")||''; $error = '<p style="font-size: 2em; color: #f00;" class="error">' .$error."</p>\n"; print $session->header(); print qq(<form action="$SCRIPT" method="post"> <input type="text" name="search" value="$user" /> <input type="submit" name="submit" value="Search" /> <input type="hidden" name="sid" value="$sid" /> </form> SID: $sid<br /> Lastpid: [$lastpid]<br /> Pid: [$$]<br /> \$session->param("lastpid")=).$session->param("lastpid").qq(<br /> \$session->id()=).$session->id().qq(<br /> ); sub reportErrors { my ($j,$k,$l) = caller; my $msg = shift; if (defined $session) { print $session->header(); } else { print "Content-type: text/html\n\n"; } print $msg." [$l]"; print STDERR $_,"\n" foreach(@_); print STDERR $DBI::errstr,"\n" if($DBI::errstr); exit 1; } ##### omni: FreeBSD omni 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 This is a fairly recent fresh install of FreeBSD 5.4. This is perl, v5.8.7 built for i386-freebsd-64int (with 1 registered patch, see perl -V for more detail) omni behaves about the same, but also supplies these warnings: Commiting session data... Done. (in cleanup) Can't connect to data source , no database driver specified and DBI_DSN env var not set at /usr/local/lib/perl5/site_perl/5.8.7/CGI/Session/MySQL.pm line 131 Not all that important, because the data *is* recorded... ##### saturn: FreeBSD saturn 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #0: Tue May 18 00:58:36 MDT 2004 root@saturn:/usr/src/sys/compile/AROS-SMP i386 This is perl, version 5.005_03 built for i386-freebsd saturn behaves about the same, but also supplies these warnings: Commiting session data... Done. Use of uninitialized value during global destruction. Use of uninitialized value during global destruction. Use of uninitialized value during global destruction.
Subject: Re: [rt.cpan.org #17299] No session data is saved unless $session->flush() is called.
Date: Thu, 26 Jan 2006 13:48:10 -0500
To: Guest via RT <bug-CGI-Session [...] rt.cpan.org>
From: Mark Stosberg <mark [...] summersault.com>
Download (untitled) / with headers
text/plain 4.3k
On Thu, Jan 26, 2006 at 01:30:04PM -0500, Guest via RT wrote: Show quoted text
> > I wrote a script ages ago (just checked the source) that handled > sessions fine w/o using ->flush() or ->close() anywhere. It was for the > debian woody release (eaisly mid 2004). > > I've tested this script on a few machines (omni, saturn). The use of > lastpid was an attempt to see if the session was saving anything... > (releases me from poking mysql on yet another terminal) When I replace > END with if (0) { ... } it stops saving session data.
Thanks for the report. I believe there is at least one other report in the bug queue already reporting the same thing. A patch would be welcome. I know it can be frustrating-- I ran into a related variation of it myself recently. (Except in my variation, I had created the problem myself!) Mark Show quoted text
> Source snippet: > > #!/usr/bin/perl -w -I/home/staff/include > ########################################################################### > # supaplex 2006-01-11 > > use strict; > use DBH; # internal module. works great on all our other DBI apps. > use CGI; > use CGI::Session; > use Data::Dumper; > use vars qw($session $dbh); > > my $cgi=new CGI; > my $session; > my $dbh = DBH->new('voip') or > reportErrors("Cannot connect to voip database"); > my $sid=$cgi->param("sid")||undef; > eval { > $session=new CGI::Session("driver:MySQL",$sid,{Handle => $dbh}); > } or reportErrors("Session INIT error",$@); > END { > print STDERR "Commiting session data... "; > $session->flush(); > print STDERR "Done.\n"; > } > $sid=$session->id(); > reportErrors("session failed to create or obtain an id") > unless($sid); > my $lastpid=$session->param("lastpid"); > $session->param("lastpid",$$); > > my $SCRIPT=$ENV{"SCRIPT_NAME"}; > > $session->param("step",512); > my $user = $cgi->param("search")||''; > my $error =$cgi->param("error")||''; > $error = '<p style="font-size: 2em; color: #f00;" class="error">' > .$error."</p>\n"; > print $session->header(); > print qq(<form action="$SCRIPT" method="post"> > <input type="text" name="search" value="$user" /> > <input type="submit" name="submit" value="Search" /> > <input type="hidden" name="sid" value="$sid" /> > </form> > SID: $sid<br /> > Lastpid: [$lastpid]<br /> > Pid: [$$]<br /> > > \$session->param("lastpid")=).$session->param("lastpid").qq(<br /> > \$session->id()=).$session->id().qq(<br /> > ); > > > sub reportErrors > { > my ($j,$k,$l) = caller; > my $msg = shift; > if (defined $session) { > print $session->header(); > } else { > print "Content-type: text/html\n\n"; > } > print $msg." [$l]"; > print STDERR $_,"\n" foreach(@_); > print STDERR $DBI::errstr,"\n" if($DBI::errstr); > exit 1; > } > > ##### omni: > > FreeBSD omni 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Sun May 8 10:21:06 UTC > 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > This is a fairly recent fresh install of FreeBSD 5.4. > > This is perl, v5.8.7 built for i386-freebsd-64int > (with 1 registered patch, see perl -V for more detail) > > omni behaves about the same, but also supplies these warnings: > Commiting session data... Done. > (in cleanup) Can't connect to data source , no database driver > specified and DBI_DSN env var not set at > /usr/local/lib/perl5/site_perl/5.8.7/CGI/Session/MySQL.pm line 131 > > Not all that important, because the data *is* recorded... > > ##### saturn: > > FreeBSD saturn 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #0: Tue May 18 > 00:58:36 MDT 2004 root@saturn:/usr/src/sys/compile/AROS-SMP i386 > > This is perl, version 5.005_03 built for i386-freebsd > > saturn behaves about the same, but also supplies these warnings: > Commiting session data... Done. > Use of uninitialized value during global destruction. > Use of uninitialized value during global destruction. > Use of uninitialized value during global destruction. >
-- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer mark@summersault.com Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .
Subject: error: "DESTROY created new reference to dead object 'CGI::Session' during global destruction."
Download (untitled) / with headers
text/plain 1.4k
I sometimes get this diagnostic message: "DESTROY created new reference to dead object 'CGI::Session' during global destruction." This is related to CGI::Session definining a DESTROY method that calls flush(). My concern at the moment is not such whether this message arises because of something internal to CGI::Session or my own application. Rather, my concerns are that: - Third party applications can cause CGI::Session not to flush automatically, reducing its robustness and creating hard to track down bugs. (I spent over a day tracking down a variation of this bug, which was caused by a circular reference in another module in combination with mod_perl...) - When the case arises, can be it handled better? Perhaps in DESTORY we can reality check the object before trying to call "flush()" on it. Of course, if the object is gone at this point, there is just no way for "flush()" to be called automatically at this point. Considering these points and the several other bugs filed about flush() and scoping, I'm lead to wonder: Should it simply be documented that calling flush() explicitly is considered a best practice, and relying on an automatic flush() is not to be expected to be reliable. I think that recommendation is justified considering it appears something subtle related to this broke with the 4.0 upgrade, and as I discovered, third party applications can interfere with the reliability. Mark
From: dan.horne [...] redbone.co.nz
Download (untitled) / with headers
text/plain 686b
Show quoted text
> So, the issue is solved by calling flush() before the script exits, or > having the object go out of scope before the script exits. That > happens > automatically when used within a web application framework such as > CGI::Application or Catalyst. > > A patch to improve our docs would be welcome. >
Hi I just came across the bug report when trying to resolve a problem using CGI::Session (via CGI::Application::Plugin::Session) with CGI::Application with FastCGI. Some applications works okay, but with others the session param settings wouldn't take. After seeing the advice here, I added $self->session->flush to the teardown method and this seems to have solved the problem.
From: unroar [...] gmail.com
Download (untitled) / with headers
text/plain 219b
Argh! I just wasted several hours tracing through Session.pm hunting down this bug. Please add a prominent note in the docs about it until it is resolved. This is a show-stopper for anyone not using CGI::Application.
Download (untitled) / with headers
text/plain 317b
POD for CGI::Session patched in V 4.29_3 to emphasize even more that auto-flushing is unreliable, and that flush() should always be called explicitly before the program exits. Nevertheless, I'm leaving this ticket open (since the issue is unresolved), although I've just closed 34668 with the same comment as above.
Download (untitled) / with headers
text/plain 590b
I've just seen this problem for the first time, and (cough, cough) in my own code at that. There was a bug in that a form did not have the hidden sid var set when the form was sent out, so when the client submitted the form vars, the program called $self -> param('session') -> param('xyz'), but the session was a brand new session, not the session which had xyz saved in it. Also, I was not calling flush(), since I've never needed to. I wonder if this (calling param() on a new session) is the cause of this problem. I'll look at it over the next few days, and I hope others can too.
CC: fabian.kainzinger [...] tngtech.com, fadius [...] gmail.com, mark [...] summersault.com
Subject: Re: [rt.cpan.org #17299] No session data is saved unless $session->flush() is called.
Date: Mon, 27 Oct 2008 02:01:54 -0600
To: bug-CGI-Session [...] rt.cpan.org
From: "Scott Edwards" <supadupa [...] gmail.com>
Download (untitled) / with headers
text/plain 910b
On Sun, Oct 26, 2008 at 11:10 PM, RSAVAGE via RT < bug-CGI-Session@rt.cpan.org> wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=17299 > > > I've just seen this problem for the first time, and (cough, cough) in my > own code at that. > > There was a bug in that a form did not have the hidden sid var set when > the form was sent out, so when the client submitted the form vars, the > program called $self -> param('session') -> param('xyz'), but the > session was a brand new session, not the session which had xyz saved in it. > > Also, I was not calling flush(), since I've never needed to. > > I wonder if this (calling param() on a new session) is the cause of this > problem. > > I'll look at it over the next few days, and I hope others can too. > >
It's been ... a few years since I added any notes to this bug. It's been to long to associate with any code I'm using now. Thanks anyway =)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.