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

Re: [Cgi-session-user] Active Sessions on Server?

[<ma...@ao...>]

Hi,

found a simple solution to delete expired session by myself, with the 
"find" method of cgi::session :-)

Ciao
  Martin  

[Cgi-session-user] Active Sessions on Server?

[<ma...@ao...>]

Hi,

two questions:

1.)

is there a nice way to detect all active sessions on the webserver 
from within the cgi-script?

i would like to implement a small "who's online" feature. it would be 
possible to store each user
activity with a timestamp on the server and take a look at it with 
the eye on the auto-session-timeout
time, but maybe there's a better way directly with cgi::session itself?

2.)

all the sessions that expired on the server aren't removed from the 
given directory, do you know a nice
way to detect and delete all expired session files on the server?


Thanks

With best regards,
  Martin 

Re: [Cgi-session-user] Problem with detecting a expired session

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

Hi Martin

I'm relying via the list. It's a defect of the list management software
that clicking Reply send the reply to the individual and not the list.

On Thu, 2011-03-17 at 13:13 +0100, Martin Lang wrote:
> Hi,
> 
> thank you for your replay, but i don't unterstand the point with the
> 
> id in the load command:
> load(undef, $id, {Directory => '/tmp'});
> 
> because is the real application i don't have the $id of the previous session!?
> 
> maybe you could explain me that thing again?

Sure.

You have to think of the code being run twice.

The first time, of course, there can be no id. Hence
CGI::Session/Data::Session/What::Ever generates a session and with it an
id.

The second time, your code supplies the id to
CGI::Session/Data::Session/What::Ever, which uses the id to recover the
session from the backing store (e.g. database).

If you never supply an id, then every time the code runs a new session
is generated, because you threw away the id from the previous run.

In that case, there's no point in using sessions, since you've written
your code in such a way as to guarantee that anything stored in a
session in 1 run of the program is never accessed again in a later run
of the program.

> thank you very much!
> 
> with best regards,
>   martin lang
> 
> At 23:10 14.03.2011, you wrote:
> >Hi Martin
> >
> >On Mon, 2011-03-14 at 08:44 +0100, ma...@ao... wrote:
> >
> > > So, i use a small template file where i included a "PROCESSMESSAGE"
> > > parameter to be the placeholder for some
> > > messages. This works all fine, but the problem is that i never end up
> > > in the "$session->is_expired" section, it allways
> > > goes to "$session->is_empty" when the session expired by time.
> > >
> > > What do i have to change to detect an expired session?
> >
> >If you run a little test program as below, setting $s1 -> expire('1s')
> >or expire('10s') so the sleep(2) does or does not affect the expiry
> >activity, you'll see that it makes no difference!
> >
> >So, why is that.
> >
> >It's because you're making the common mistake of using load(undef,
> >undef, ...).
> >
> >So:
> >o Use new not load
> >o Use meaningful parameters, not undef, undef
> >o Switch to Data::Session (which I wrote).
> >
> >#!/usr/bin/env perl
> >
> >use feature 'say';
> >use strict;
> >use warnings;
> >
> >use CGI::Session;
> >
> ># ------------------------------------------------
> >
> >sub report
> >{
> >         my($who, $s) = @_;
> >         my($id) = $s -> id || 'No id';
> >         my($claimed_id) = $$s{_CLAIMED_ID} || 'No claimed id';
> >
> >         say "$who: Id: $id. $claimed_id.";
> >
> >         my(%status) =
> >         (
> >                 unset    => CGI::Session::STATUS_UNSET,
> >                 new      => CGI::Session::STATUS_NEW,
> >                 modified => CGI::Session::STATUS_MODIFIED,
> >                 delete   => CGI::Session::STATUS_DELETED,
> >                 expired  => CGI::Session::STATUS_EXPIRED,
> >         );
> >
> >         for my $key (sort keys %status)
> >         {
> >                 if ($s -> _test_status($status{$key}) )
> >                 {
> >                         say "$who: $key";
> >                 }
> >         }
> >
> >         if ($s -> is_empty)
> >         {
> >                 say "$who: empty";
> >         }
> >
> >} # End of report.
> >
> ># ------------------------------------------------
> >
> >my($s1) = CGI::Session -> load(undef, undef, {Directory => '/tmp'});
> >my($id) = $s1 -> id;
> >
> >report('s1', $s1);
> >
> >$s1 -> expire('10s');
> >
> >say 'Sleeping for 2 seconds';
> >
> >sleep 2;
> >
> >report('s1', $s1);
> >
> >my($s2) = CGI::Session -> load(undef, $id, {Directory => '/tmp'});
> >
> >report('s2', $s2);
> >
> >--
> >Ron Savage
> >http://savage.net.au/
> >Ph: 0421 920 622
> >
> >
> >------------------------------------------------------------------------------
> >Colocation vs. Managed Hosting
> >A question and answer guide to determining the best fit
> >for your organization - today and in the future.
> >http://p.sf.net/sfu/internap-sfd2d
> >_______________________________________________
> >Cgi-session-user mailing list
> >Cgi...@li...
> >https://lists.sourceforge.net/lists/listinfo/cgi-session-user
> 
> 

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

Re: [Cgi-session-user] Problem with detecting a expired session

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

Hi Martin

On Mon, 2011-03-14 at 08:44 +0100, ma...@ao... wrote:

> So, i use a small template file where i included a "PROCESSMESSAGE" 
> parameter to be the placeholder for some
> messages. This works all fine, but the problem is that i never end up 
> in the "$session->is_expired" section, it allways
> goes to "$session->is_empty" when the session expired by time.
> 
> What do i have to change to detect an expired session?

If you run a little test program as below, setting $s1 -> expire('1s')
or expire('10s') so the sleep(2) does or does not affect the expiry
activity, you'll see that it makes no difference!

So, why is that.

It's because you're making the common mistake of using load(undef,
undef, ...).

So:
o Use new not load
o Use meaningful parameters, not undef, undef
o Switch to Data::Session (which I wrote).

#!/usr/bin/env perl

use feature 'say';
use strict;
use warnings;

use CGI::Session;

# ------------------------------------------------

sub report
{
	my($who, $s) = @_;
	my($id) = $s -> id || 'No id';
	my($claimed_id) = $$s{_CLAIMED_ID} || 'No claimed id';

	say "$who: Id: $id. $claimed_id.";

	my(%status) =
	(
		unset    => CGI::Session::STATUS_UNSET,
		new      => CGI::Session::STATUS_NEW,
		modified => CGI::Session::STATUS_MODIFIED,
		delete   => CGI::Session::STATUS_DELETED,
		expired  => CGI::Session::STATUS_EXPIRED,
	);

	for my $key (sort keys %status)
	{
		if ($s -> _test_status($status{$key}) )
		{
			say "$who: $key";
		}
	}

	if ($s -> is_empty)
	{
		say "$who: empty";
	}

} # End of report.

# ------------------------------------------------

my($s1) = CGI::Session -> load(undef, undef, {Directory => '/tmp'});
my($id) = $s1 -> id;

report('s1', $s1);

$s1 -> expire('10s');

say 'Sleeping for 2 seconds';

sleep 2;

report('s1', $s1);

my($s2) = CGI::Session -> load(undef, $id, {Directory => '/tmp'});

report('s2', $s2);

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

[Cgi-session-user] Problem with detecting a expired session

[<ma...@ao...>]

Hi,

i think this question is very easy for you. My ISP installed the 
CGI::Session package for me and
i included it into my CGI/Perl project.

all works fine until one thing. i set the expire time to be 1 hour, 
this works too, after 1 hour without
activity the session will be deleted.

but i would like to send the user not only the normal login-page, i 
would like to tell the user that the
session had expired. i used the sample codes on the web and included 
it like this:

-----------------------------------------------------

.
.
.

   $session = 
CGI::Session->load(undef,undef,{Directory=>'/home/etc/sessions'}) or 
die CGI::Session->errstr;

   if($session->is_expired)
		{
			$session->clear();
			$session->delete();

			  my %Placeholders = (
			      PROCESSMESSAGE => 'Session expired!'
    			  );
			  open(TEMPLATE,"<templatesV2/loginform$handy.html") or die("can't 
open loginform.html",$!);
			  {local($/) = undef;$template = <TEMPLATE>;}
			  close(TEMPLATE);
	   	  	  $template =~ s/\$([A-Z]+)/$Placeholders{$1}/g;
			  print $session->header(-cache_control=>"no-cache, no-store, 
must-revalidate");
			  print $template;
			  goto END;
	    }
	    elsif($session->is_empty)
         {
     	  		 my %Placeholders = (
			      PROCESSMESSAGE => ' '
    			 );
	      	 	open(TEMPLATE,"<templatesV2/loginform$handy.html") or 
die("can't open loginform.html",$!);
		  	{local($/) = undef;$template = <TEMPLATE>;}
		  	close(TEMPLATE);
    	  	  	$template =~ s/\$([A-Z]+)/$Placeholders{$1}/g;
     	  	  	print $session->header(-cache_control=>"no-cache, 
no-store, must-revalidate");
		  	print $template;
		  	goto END;
         }
	    else
		{
         # Session is OK, load parameters and do the main output...
		$username = $session->param("username");
		$usertype = $session->param("usertype");
		$useremail = $session->param("useremail");
		$lastlogin = $session->param("userlastlogin");
		}
.
.
.
-----------------------------------------------------

So, i use a small template file where i included a "PROCESSMESSAGE" 
parameter to be the placeholder for some
messages. This works all fine, but the problem is that i never end up 
in the "$session->is_expired" section, it allways
goes to "$session->is_empty" when the session expired by time.

What do i have to change to detect an expired session?

Thanks

With best regards,
  Martin

Re: [Cgi-session-user] more new CGI::Session user questions

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

> I then put some things in the session and do a flush.  There are no
> errors, the code runs, but nothing is stored into the database.
> 
> I can run the code repeatedly and I will get different sessionIDs each
> time -- but nothing is stored.
> 
> ideas?

Try again with the "handle" option, but before passing in the handle
call this:

$dbh->trace(2);

http://search.cpan.org/~timb/DBI-1.615/DBI.pm#trace

Then, run the code and check the error log. It should show you the
database actually did.

This may produce an easier to read result:

 $dbh->{Profile} = 2;

http://search.cpan.org/~timb/DBI-1.615/lib/DBI/Profile.pm

If that doesn't help, copy the CGI::Session module to a private location
and add some "warn" statements to it where you suspect an issue, if
adding "warn" statements to your own code is not enough.

Also, check in your browser that the cookie is being set, if that's part
of the test case.

   Mark

[Cgi-session-user] more new CGI::Session user questions

[Seven R. <sev...@gm...>]

Hi,

I am still missing something fundamental when it comes to storing
sessions in MySQL.  I am trying the following:

            $SESSION = CGI::Session->load("driver:MySQL", $CGI,
                                      {
                                          DataSource  => join(':',
                                              $CONFIG->{mysql}{DSN},
                                              $CONFIG->{mysql}{Collection}),
                                          User        =>
                                                 $CONFIG->{mysql}{User},
                                          Password    =>
                                                 $CONFIG->{mysql}{Password},
                                          TableName   => 'sessions',
                                          IdColName   => 'id',
                                          DataColName => 'data',
                                      }) ||
                die CGI::Session->errstr() . "\n";

I have tried:

            $SESSION = CGI::Session->load("driver:MySQL", $CGI,
                                      {
                                          DataSource  => join(':',
                                              $CONFIG->{mysql}{DSN},
                                              $CONFIG->{mysql}{Collection}),
                                          TableName   => 'sessions',
                                          IdColName   => 'id',
                                          DataColName => 'data',
                                          Handle      => $dbh,
                                      }) ||
                die CGI::Session->errstr() . "\n";

and

            $SESSION = CGI::Session->load("driver:MySQL", $CGI,
                                      {
                                          TableName   => 'sessions',
                                          IdColName   => 'id',
                                          DataColName => 'data',
                                          Handle      => $dbh,
                                      }) ||
                die CGI::Session->errstr() . "\n";

In the cases where I am using the "CONFIG" reference, all the values
are there and are correct.  In the cases where I use an active
database handle, that handle exists and is open.  In either casr the
"die" has never been triggered.

I then do a couple of checks:

            if ($SESSION->is_expired) {
                #
                # If we are picking up an old session see if it is
                # already expired.  If it is expired delete it from the
                # store and flush the session data.
                #
warn __LINE__, ": session is expired\n";
                $SESSION->delete();
                $SESSION->flush();
warn __LINE__, ": session FLUSH\n";
            }
            if ($SESSION->is_empty) {
                #
                # This "new" is CGI::Session magic.  The session
                # definition in the "load" above is remembered and will
                # be re-applied here.
                #
warn __LINE__, ": session is empty\n";
                $SESSION = CGI::Session->new() ||
                    die CGI::Session->errstr() . "\n";
            }
            if ($SESSION->is_new) {
warn __LINE__, ": session is NEW\n";
            }

I then put some things in the session and do a flush.  There are no
errors, the code runs, but nothing is stored into the database.

I can run the code repeatedly and I will get different sessionIDs each
time -- but nothing is stored.

ideas?

s.r.

[Cgi-session-user] unsubscribe

[Devin A. <dev...@gm...>]

On Tue, Oct 26, 2010 at 6:04 AM, <
cgi...@li...> wrote:

> Send Cgi-session-user mailing list submissions to
>        cgi...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/cgi-session-user
> or, via email, send a message with subject or body 'help' to
>        cgi...@li...
>
> You can reach the person managing the list at
>        cgi...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cgi-session-user digest..."
>
>
> Today's Topics:
>
>   1. new CGI::Session user questions (Seven Reeds)
>   2. Re: new CGI::Session user questions (Cees Hek)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 25 Oct 2010 13:41:49 -0500
> From: Seven Reeds <sev...@gm...>
> Subject: [Cgi-session-user] new CGI::Session user questions
> To: cgi...@li...
> Message-ID:
>        <AAN...@ma...<AANLkTinacGiFfz6ru_F_RoqFvVch3%2BS...@ma...>
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> I am running CGI::Session version 4.42 on a redhat linux box rhel 5.5
> with Apache2.x.
>
> I am trying the following:
>
> ? ? ? ?$SESSION = new CGI::Session("driver:MySQL",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$CGI || $loginSessionID, {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TableName ? =>'sessions',
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?IdColName ? =>'id',
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DataColName =>'data',
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Handle ? ? ?=>$DBH,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}) ||
> ? ? ? ? ? ?die CGI::Session->errstr() . "\n";
>
> but when I run the script I get:
>
> (in cleanup) Can't connect to data source '' because I can't work out
> what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix
> and the DBI_DRIVER env var is not set) at
> /usr/lib/perl5/site_perl/5.8.8/CGI/Session/Driver/DBI.pm line 26
>
> I have tried:
>
> ? ? ? ?$SESSION = new CGI::Session("driver:MySQL",
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$CGI || $loginSessionID, {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DataSource
> ?=>'dbi:mysql:project_db',
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TableName ? =>'sessions',
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?IdColName ? =>'id',
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DataColName =>'data',
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Handle ? ? ?=>$DBH,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}) ||
> ? ? ? ? ? ?die CGI::Session->errstr() . "\n";
>
> but adding the data source almost defeats the purpose of the "Handle"
> element. ?When I run it I get:
>
> (in cleanup) Can't call method "FETCH" on an undefined value at
> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBI.pm line
> 668 during global destruction.
>
> ideas?
>
> s.r.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 Oct 2010 10:32:50 +1100
> From: Cees Hek <ce...@gm...>
> Subject: Re: [Cgi-session-user] new CGI::Session user questions
> To: Seven Reeds <sev...@gm...>
> Cc: cgi...@li...
> Message-ID:
>        <AAN...@ma...<AANLkTinyDHTkQibhA3XgAr29sJ3nN_GpHNDOej%2B...@ma...>
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> What might be happening is that your database handle is 'cleaned up'
> before the session object, so by the time the session is flushing, the
> database handle has already been disconnected.  Notice that this is
> all happening during global destruction, so you need to ensure that
> your session goes out of scope before the database handle does.
>
> What is usually safer to do is to explicitly 'flush' your session at
> the end of your code.
>
> Cheers,
>
> Cees
>
> On Tue, Oct 26, 2010 at 5:41 AM, Seven Reeds <sev...@gm...>
> wrote:
> > Hi,
> >
> > I am running CGI::Session version 4.42 on a redhat linux box rhel 5.5
> > with Apache2.x.
> >
> > I am trying the following:
> >
> > ? ? ? ?$SESSION = new CGI::Session("driver:MySQL",
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$CGI || $loginSessionID, {
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TableName ? =>'sessions',
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?IdColName ? =>'id',
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DataColName =>'data',
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Handle ? ? ?=>$DBH,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}) ||
> > ? ? ? ? ? ?die CGI::Session->errstr() . "\n";
> >
> > but when I run the script I get:
> >
> > (in cleanup) Can't connect to data source '' because I can't work out
> > what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix
> > and the DBI_DRIVER env var is not set) at
> > /usr/lib/perl5/site_perl/5.8.8/CGI/Session/Driver/DBI.pm line 26
> >
> > I have tried:
> >
> > ? ? ? ?$SESSION = new CGI::Session("driver:MySQL",
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?$CGI || $loginSessionID, {
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DataSource
> ?=>'dbi:mysql:project_db',
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?TableName ? =>'sessions',
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?IdColName ? =>'id',
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DataColName =>'data',
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Handle ? ? ?=>$DBH,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}) ||
> > ? ? ? ? ? ?die CGI::Session->errstr() . "\n";
> >
> > but adding the data source almost defeats the purpose of the "Handle"
> > element. ?When I run it I get:
> >
> > (in cleanup) Can't call method "FETCH" on an undefined value at
> > /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBI.pm line
> > 668 during global destruction.
> >
> > ideas?
> >
> > s.r.
> >
> >
> ------------------------------------------------------------------------------
> > Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> > Create new apps & games for the Nokia N8 for consumers in ?U.S. and
> Canada
> > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> > http://p.sf.net/sfu/nokia-dev2dev
> > _______________________________________________
> > Cgi-session-user mailing list
> > Cgi...@li...
> > https://lists.sourceforge.net/lists/listinfo/cgi-session-user
> >
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America
> contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
>
> ------------------------------
>
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>
>
> End of Cgi-session-user Digest, Vol 34, Issue 1
> ***********************************************
>



-- 
Devin Austin
http://www.codedright.net
9702906669 - Cell

Re: [Cgi-session-user] 'host' not being set correctly

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

On 12/13/2010 04:00 PM, Harshal Chhaya wrote:
> 
> Hello,
> 
> The value of the 'host' parameter in the cookie being set by CGI::Session
> is missing the leading dot. I don't use 'www' in the URL so the URL is
> domain.com (say). The value of the 'host' field in the cookie set by 
> CGI::Session is 'domain.com' instead of '.domain.com'.
> 
> How do I fix this?
> 
> Also, how do I tell CGI::Session to set the 'secure' flag in the cookie?
> 
> If I generate my own cookie with the 'secure' flag set to 1, the browser
> stores 2 cookies with the same name - one with 'domain.com' (from CGI::Session)
> and the other with '.domain.com' from my script.

Harshal,

CGI::Session does not handle setting the domain. For both this issue and
the secure flag, what you need to do is read the related docs for
CGI::Application and then pass through the values you want through the
CGI::Session header() method when I presume you are using).

http://search.cpan.org/~markstos/CGI-Session-4.43/lib/CGI/Session.pm#header()
http://search.cpan.org/~lds/CGI.pm-3.50/lib/CGI.pm#HTTP_COOKIES

  Mark

[Cgi-session-user] [Fwd: Re: 'host' not being set correctly]

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

Hi

Damn list management software. This went to OP and not the list...

-------- Forwarded Message --------
> From: Ron Savage <ro...@sa...>
> To: Harshal Chhaya <ha...@ch...>
> Subject: Re: [Cgi-session-user] 'host' not being set correctly
> Date: Tue, 14 Dec 2010 11:02:31 +1100
> 
> Hi Harshal
> 
> On Mon, 2010-12-13 at 16:00 -0500, Harshal Chhaya wrote:
> > Hello,
> > 
> > The value of the 'host' parameter in the cookie being set by CGI::Session
> > is missing the leading dot. I don't use 'www' in the URL so the URL is
> > domain.com (say). The value of the 'host' field in the cookie set by 
> > CGI::Session is 'domain.com' instead of '.domain.com'.
> > 
> > How do I fix this?
> > 
> > Also, how do I tell CGI::Session to set the 'secure' flag in the cookie?
> > 
> > If I generate my own cookie with the 'secure' flag set to 1, the browser
> > stores 2 cookies with the same name - one with 'domain.com' (from CGI::Session)
> > and the other with '.domain.com' from my script.
> 
> What type of query object are you using? CGI, CGI::Simple, or something
> else?
> 
> And which version?
> 
> CGI::Session does not create cookies itself. It uses its query() method
> to get a query object (whose default type is CGI), and then uses that to
> call the query object's cookie() method.
> 
> There is no provision in CGI::Session - at the moment - to set
> parameters such as host and secure, without dealing with the code (in
> sub cookie() ) which checks for expired sessions, and sessions which
> have an expiry time.
> 
> In other words, if your sessions have no expiry time, you can call
> cookie() directly (without calling header() and http_header() ), and in
> that case you can pass extra parameters to the query object's cookie()
> method.
> 
> See sub cookie() at line 334 in V 4.43 of Session.pm.
> 
> That suggests - to achieve your goals /and/ to use expiry times - you
> should not use CGI::Session's header(), http_header() and cookie()
> methods, but create you own cookie, presumably by calling CGI::Cookie ->
> new() directly.
> 
> That would also allow you to set the domain to '.domain.com'.
> 
-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

[Cgi-session-user] 'host' not being set correctly

[Harshal C. <ha...@ch...>]

Hello,

The value of the 'host' parameter in the cookie being set by CGI::Session
is missing the leading dot. I don't use 'www' in the URL so the URL is
domain.com (say). The value of the 'host' field in the cookie set by 
CGI::Session is 'domain.com' instead of '.domain.com'.

How do I fix this?

Also, how do I tell CGI::Session to set the 'secure' flag in the cookie?

If I generate my own cookie with the 'secure' flag set to 1, the browser
stores 2 cookies with the same name - one with 'domain.com' (from CGI::Session)
and the other with '.domain.com' from my script.

Thanks,
- Harshal

[Cgi-session-user] Announce: CGI::Session 4.43 released

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

Hello,

I'd like to announce the release of CGI::Session 4.43. It includes the
following changes since the last version. It has been uploaded to CPAN
moments ago and should appear on a CPAN mirror near you in the next few
hours. The changes since the last release are below.

###

4.43 - Saturday, December 11, 2010

* FIX: Avoid deleting unmatched sessions when calling find() when
       ip_match is enabled.

    Closes RT#47795. Thanks to m-uchino, Ron Savage, and Mark Stosberg

* NEW: new public ip_match() method is available, primarily for use with
       find(). (Ron Savage, Mark Stosberg)

* DOCS: UTF8 related documentation was updated.

* INTERNAL: Don't add _SESSION_EXPIRE_LIST to internal hash unless we
       need to.  RT#51192, Thanks to Pavel V. Rochnyack, Ron Savage,
       Mark Stosberg

* INTERNAL: Avoid calling sprintf() in CGI::Session::ErrorHandler,
    fixing RT#48733 Solves taint error for Perl V 5.10.0. All
    well-written code will have been using errstr() to retrieve errors
    anyway so this change will not affect any code which obeys the API.
    (Peter Kaminsk, Ron Savage, Mark Stosberg)

* INTERNAL: The undocumented 4th parameter to load() has changed its
meaning.

* INTERNAL: Test suite improvements. (Ron Savage, Mark Stosberg)

Re: [Cgi-session-user] Announce: Data::Session - A re-write of CGI::Session

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

> http://search.cpan.org/~rsavage/Data-Session-1.01/

As I responded on the CGI::Application list, I welcome this fresh
rewrite which drops some baggage from CGI::Session, like global
variables, which CGI::Session has retained in the name of backwards
compatibility.

I would suggest also dropping the DESTROY method, as it has had a
history of being problematic for some CGI::Session users.  Third party
code can create a circular reference, which causes the CGI::Session
objects not to go out of scope when expected, and then sessions don't
get flushed automatically by DESTROY. Because the bugs are ultimately
with third-party code, it can be very hard to track and fix those issues
when users have them.

Explicit flushing seems like a better idea. Something like the "DESTROY"
concept can be accomplished when the module is hooked into frameworks
like CGI::Application, which offers a "teardown" phase.

On the other hand, one the benefits from Ron for this project is to take
the project in direction of his choosing, so I won't belabor different
design choices I might make here.

    Mark

[Cgi-session-user] Announce: Data::Session - A re-write of CGI::Session

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

Hi Folks

Test and enjoy...

http://search.cpan.org/~rsavage/Data-Session-1.01/

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

Re: [Cgi-session-user] new CGI::Session user questions

[Seven R. <sev...@gm...>]

Thanks to all that responded.  The issue was that I had forgotten to
call flush(), duh on me.

All the best,
sr

On Mon, Oct 25, 2010 at 6:32 PM, Cees Hek <ce...@gm...> wrote:
> What might be happening is that your database handle is 'cleaned up'
> before the session object, so by the time the session is flushing, the
> database handle has already been disconnected.  Notice that this is
> all happening during global destruction, so you need to ensure that
> your session goes out of scope before the database handle does.
>
> What is usually safer to do is to explicitly 'flush' your session at
> the end of your code.
>
> Cheers,
>
> Cees
>
> On Tue, Oct 26, 2010 at 5:41 AM, Seven Reeds <sev...@gm...> wrote:
>> Hi,
>>
>> I am running CGI::Session version 4.42 on a redhat linux box rhel 5.5
>> with Apache2.x.
>>
>> I am trying the following:
>>
>>        $SESSION = new CGI::Session("driver:MySQL",
>>                                    $CGI || $loginSessionID, {
>>                                        TableName   =>'sessions',
>>                                        IdColName   =>'id',
>>                                        DataColName =>'data',
>>                                        Handle      =>$DBH,
>>                                    }) ||
>>            die CGI::Session->errstr() . "\n";
>>
>> but when I run the script I get:
>>
>> (in cleanup) Can't connect to data source '' because I can't work out
>> what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix
>> and the DBI_DRIVER env var is not set) at
>> /usr/lib/perl5/site_perl/5.8.8/CGI/Session/Driver/DBI.pm line 26
>>
>> I have tried:
>>
>>        $SESSION = new CGI::Session("driver:MySQL",
>>                                    $CGI || $loginSessionID, {
>>                                        DataSource  =>'dbi:mysql:project_db',
>>                                        TableName   =>'sessions',
>>                                        IdColName   =>'id',
>>                                        DataColName =>'data',
>>                                        Handle      =>$DBH,
>>                                    }) ||
>>            die CGI::Session->errstr() . "\n";
>>
>> but adding the data source almost defeats the purpose of the "Handle"
>> element.  When I run it I get:
>>
>> (in cleanup) Can't call method "FETCH" on an undefined value at
>> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBI.pm line
>> 668 during global destruction.
>>
>> ideas?
>>
>> s.r.
>>
>> ------------------------------------------------------------------------------
>> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
>> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
>> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
>> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
>> http://p.sf.net/sfu/nokia-dev2dev
>> _______________________________________________
>> Cgi-session-user mailing list
>> Cgi...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>>
>

Re: [Cgi-session-user] new CGI::Session user questions

[Cees H. <ce...@gm...>]

What might be happening is that your database handle is 'cleaned up'
before the session object, so by the time the session is flushing, the
database handle has already been disconnected.  Notice that this is
all happening during global destruction, so you need to ensure that
your session goes out of scope before the database handle does.

What is usually safer to do is to explicitly 'flush' your session at
the end of your code.

Cheers,

Cees

On Tue, Oct 26, 2010 at 5:41 AM, Seven Reeds <sev...@gm...> wrote:
> Hi,
>
> I am running CGI::Session version 4.42 on a redhat linux box rhel 5.5
> with Apache2.x.
>
> I am trying the following:
>
>        $SESSION = new CGI::Session("driver:MySQL",
>                                    $CGI || $loginSessionID, {
>                                        TableName   =>'sessions',
>                                        IdColName   =>'id',
>                                        DataColName =>'data',
>                                        Handle      =>$DBH,
>                                    }) ||
>            die CGI::Session->errstr() . "\n";
>
> but when I run the script I get:
>
> (in cleanup) Can't connect to data source '' because I can't work out
> what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix
> and the DBI_DRIVER env var is not set) at
> /usr/lib/perl5/site_perl/5.8.8/CGI/Session/Driver/DBI.pm line 26
>
> I have tried:
>
>        $SESSION = new CGI::Session("driver:MySQL",
>                                    $CGI || $loginSessionID, {
>                                        DataSource  =>'dbi:mysql:project_db',
>                                        TableName   =>'sessions',
>                                        IdColName   =>'id',
>                                        DataColName =>'data',
>                                        Handle      =>$DBH,
>                                    }) ||
>            die CGI::Session->errstr() . "\n";
>
> but adding the data source almost defeats the purpose of the "Handle"
> element.  When I run it I get:
>
> (in cleanup) Can't call method "FETCH" on an undefined value at
> /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBI.pm line
> 668 during global destruction.
>
> ideas?
>
> s.r.
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

[Cgi-session-user] new CGI::Session user questions

[Seven R. <sev...@gm...>]

Hi,

I am running CGI::Session version 4.42 on a redhat linux box rhel 5.5
with Apache2.x.

I am trying the following:

       $SESSION = new CGI::Session("driver:MySQL",
                                   $CGI || $loginSessionID, {
                                       TableName   =>'sessions',
                                       IdColName   =>'id',
                                       DataColName =>'data',
                                       Handle      =>$DBH,
                                   }) ||
           die CGI::Session->errstr() . "\n";

but when I run the script I get:

(in cleanup) Can't connect to data source '' because I can't work out
what driver to use (it doesn't seem to contain a 'dbi:driver:' prefix
and the DBI_DRIVER env var is not set) at
/usr/lib/perl5/site_perl/5.8.8/CGI/Session/Driver/DBI.pm line 26

I have tried:

       $SESSION = new CGI::Session("driver:MySQL",
                                   $CGI || $loginSessionID, {
                                       DataSource  =>'dbi:mysql:project_db',
                                       TableName   =>'sessions',
                                       IdColName   =>'id',
                                       DataColName =>'data',
                                       Handle      =>$DBH,
                                   }) ||
           die CGI::Session->errstr() . "\n";

but adding the data source almost defeats the purpose of the "Handle"
element.  When I run it I get:

(in cleanup) Can't call method "FETCH" on an undefined value at
/usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/DBI.pm line
668 during global destruction.

ideas?

s.r.

[Cgi-session-user] Patches for CGI::Session's discussion of UTF8

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

Hi Folks

I've updated the repository as we discussed re UTF8.

Here is the new POD: 

http://savage.net.au/Perl-modules/html/CGI/Session.html

-- 
Ron Savage
http://savage.net.au/
Ph: 0421 920 622

Re: [Cgi-session-user] Parameter expiration - what am I doing wrong?

[Jason P. <ja...@jo...>]

Thanks! That sounds like it should do it, but I added a sleep between 
the load and the test and it still fails. I tried undef'ing the session 
after the load and re-loading it and it still fails, too.

Very odd...

- Jason

On 07/23/2010 08:30 PM, Ron Savage wrote:
> Hi Jason
>
> On Fri, 2010-07-23 at 13:43 -0400, Jason Purdy wrote:
>> I have this simple test script that's trying to expire a particular
>> parameter (from a simplified issue I'm dealing with in a separate piece
>> of code) and it seems to be failing:
>>
>> http://pastebin.com/tNxC1Wsm
>>
>> I filed a bug report[1], just in case this is a module bug, but I have a
>> sneaking suspicion I'm doing something wrong. If that's the case, I'll
>> go back to RT and resolve it.
>
> User error, I'm afraid (IMHO).
>
> Re-read the last statement (Note...) under the docs for expire(), where
> is says the time is /relative to session's last access time/.
>
> Your code does a load just before the test, so without reading the
> source I'd say the expire is not triggered, 'cause the last access is
> microseconds ago.
>
> Try the sleep just after the load() but before the test...
>
> Let us know what happens.
>

[Cgi-session-user] Parameter expiration - what am I doing wrong?

[Jason P. <ja...@jo...>]

I have this simple test script that's trying to expire a particular 
parameter (from a simplified issue I'm dealing with in a separate piece 
of code) and it seems to be failing:

http://pastebin.com/tNxC1Wsm

I filed a bug report[1], just in case this is a module bug, but I have a 
sneaking suspicion I'm doing something wrong. If that's the case, I'll 
go back to RT and resolve it.

Thanks!

Jason

[1]: https://rt.cpan.org/Ticket/Display.html?id=59662

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On 05/03/2010 04:27 PM, Ron Savage wrote:
> Hi Jeff
> 
> On Mon, 2010-05-03 at 09:23 -0700, Jeff Chimene wrote:
>> On 05/03/2010 09:16 AM, Jeff Chimene wrote:
>>> On 05/02/2010 05:14 PM, Ron Savage wrote:
> 
>> No, that doesn't work. The current CGI session ($i) has other context I
>> forgot about. Initializing $i using CGI::Session->load erases that context.
> 
> Oh.
> 
> I think there are no more suggestions I can make now, but it seems you
> are making progress.
> 
> Let us know when it's working.

Hi Ron,

I'm actually pretty satisfied right now. To recap: call
$cgiSession->delete() to remove the spurious session file.

I may be able to work up a test case, if you are interested.

Again, thanks for the feedback!

Cheers,
jec

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On 05/03/2010 09:16 AM, Jeff Chimene wrote:
> On 05/02/2010 05:14 PM, Ron Savage wrote:
>> Hi Jeff
>>
>> Damn. Replies go by default to the sender, not the list.
>>
>> I'm sending this to the list of the benefit of anyone who might be doing
>> the same sort of thing.
>>
>> On Sun, 2010-05-02 at 16:56 -0700, Jeff Chimene wrote:
>>> On 05/02/2010 04:35 PM, Ron Savage wrote:
>>
>>> Yes, that's the case. I've been trying to avoid that "little wrinkle"
>>
>> Always post real code, please!
> 
> That's not possible in this case.
> 
>>  
>>>> OK. So you're generating a company-dependent path to the primary session
>>>> file, right?
>>>
>>> Almost. The company-dependent path is to the secondary session.
>>
>> Right. My wording was wrong. I do get what you're doing...
>>
>> I think... Company-specific data in the primary session enables you to
>> access the secondary session.
> 
> Correct.
> 
>>>>
>>>>>     my $sessionFile = File::Spec->catfile(
>>>>>         $dataPath    #
>>>>>         , sprintf( $CGI::Session::Driver::file::FileName,
>>>>> $i->param('report_id') )
>>>>>     );
>>>>>
>>>>>     if ( -e $sessionFile )
>>>>>     {
>>>>>         my $cgiSession = CGI::Session->load( "id:static",
>>>>> $i->param('report_id'), { Directory => $dataPath } );
>>>>>         $cgiSession->load_param($i);
>>>>
>>>> This is loading the primary session, right?
>>>
>>> No. It's loading the secondary session. The primary session has already
>>> successfully loaded. I'm going to adopt your terminology. The primary
>>> session has successfully loaded by this time; which new() operation is
>>> not shown here (as it's not part of this subroutine).
>>
>> OK.
>>
>>>> But load_param takes 2 parameters: ($query, $params). How is ($i) going
>>>> to work?
>>>
>>> The CGI session was initialized outside of this subroutine.
>>>
>>>>
>>>> Hopefully, this is /the/ bug.
>>>
>>> Sorry, that's not it.
>>
>> I'd say it is. If you don't wish to pass $q to load_param, you need to
>> call it as (undef, $i).
>>
>> I say this because I've just examined the code.
>>
>> ($i) means $i is ignored, since the code calls $self -> param instead.
>>
> 
> It's doing what I want. I understand your confusion, as it's due to
> you're not being able to see the entire code base.
> 
> As this is a legacy app, the values from the CGI::Session object
> ($cgiSession) are to be copied to the CGI object ($i). I've tried making
> $i a new CGI::Session, but the application-specific data structures
> aren't compatible. The best I can do is to create a placenta that
> converts from the primary CGI::Session object to the secondary
> CGI::Session object.
> 
> However, now that I think about it, perhaps I can go back to loading the
> secondary session into $i. I'd abandoned that attempt a few days ago,
> but the problem may have been related to the test harness as opposed to
> the specific technique.

No, that doesn't work. The current CGI session ($i) has other context I
forgot about. Initializing $i using CGI::Session->load erases that context.

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On 05/02/2010 05:14 PM, Ron Savage wrote:
> Hi Jeff
> 
> Damn. Replies go by default to the sender, not the list.
> 
> I'm sending this to the list of the benefit of anyone who might be doing
> the same sort of thing.
> 
> On Sun, 2010-05-02 at 16:56 -0700, Jeff Chimene wrote:
>> On 05/02/2010 04:35 PM, Ron Savage wrote:
> 
>> Yes, that's the case. I've been trying to avoid that "little wrinkle"
> 
> Always post real code, please!

That's not possible in this case.

>  
>>> OK. So you're generating a company-dependent path to the primary session
>>> file, right?
>>
>> Almost. The company-dependent path is to the secondary session.
> 
> Right. My wording was wrong. I do get what you're doing...
> 
> I think... Company-specific data in the primary session enables you to
> access the secondary session.

Correct.

>>>
>>>>     my $sessionFile = File::Spec->catfile(
>>>>         $dataPath    #
>>>>         , sprintf( $CGI::Session::Driver::file::FileName,
>>>> $i->param('report_id') )
>>>>     );
>>>>
>>>>     if ( -e $sessionFile )
>>>>     {
>>>>         my $cgiSession = CGI::Session->load( "id:static",
>>>> $i->param('report_id'), { Directory => $dataPath } );
>>>>         $cgiSession->load_param($i);
>>>
>>> This is loading the primary session, right?
>>
>> No. It's loading the secondary session. The primary session has already
>> successfully loaded. I'm going to adopt your terminology. The primary
>> session has successfully loaded by this time; which new() operation is
>> not shown here (as it's not part of this subroutine).
> 
> OK.
> 
>>> But load_param takes 2 parameters: ($query, $params). How is ($i) going
>>> to work?
>>
>> The CGI session was initialized outside of this subroutine.
>>
>>>
>>> Hopefully, this is /the/ bug.
>>
>> Sorry, that's not it.
> 
> I'd say it is. If you don't wish to pass $q to load_param, you need to
> call it as (undef, $i).
> 
> I say this because I've just examined the code.
> 
> ($i) means $i is ignored, since the code calls $self -> param instead.
> 

It's doing what I want. I understand your confusion, as it's due to
you're not being able to see the entire code base.

As this is a legacy app, the values from the CGI::Session object
($cgiSession) are to be copied to the CGI object ($i). I've tried making
$i a new CGI::Session, but the application-specific data structures
aren't compatible. The best I can do is to create a placenta that
converts from the primary CGI::Session object to the secondary
CGI::Session object.

However, now that I think about it, perhaps I can go back to loading the
secondary session into $i. I'd abandoned that attempt a few days ago,
but the problem may have been related to the test harness as opposed to
the specific technique.

To return to the topic at hand, the load_param() with a single argument
works as intended and expected.

sub load_param {
    my $self = shift;
    my ($query, $params) = @_; # resolves to $i, undef

    $query  ||= $self->query();   # resolves to $i
    $params ||= [ $self->param ]; # resolves to $cgiSession->param

    for ( @$params ) {
        $query->param(-name=>$_, -value=>$self->param($_));
    }
}


>>> Besides the complexity of chained session, which I suggest you
>>> eliminate, the CGI::Session code connected to
>>> $CGI::Session::Driver::file::FileName assumes a %s in the file name,
>>> doesn't it, into which CGI::Session will inject the id.
>>>
>>> But you don't have that, so I guess that's not what you're trying to set
>>> up, although that was certainly my first impression.
>>
>> Eh? From the code:
>>
>> $CGI::Session::Driver::file::FileName = "%s.dat";
>>
>> Perhaps I'm missing your point...
> 
> Sorry. My mistake. You are using %s.
>  
>>> This is another side effect of the complexity I mentioned!
>>>
>>>>         $logger->trace("found spurious session") if -e
>>>> $dataPath.$cgiSession->id().'.dat';
>>>>         $logger->logcroak(CGI::Session->errstr()) unless
>>>> CGI::Session->errstr() eq '';
>>>>         return 'OK';
>>>>     }
>>>>     $logger->logcroak("cannot find $sessionFile: $!");
>>>> } ## end sub GetLocalReportState
>>>
>>>
>>
>> The above was resolved (?) via $cgiSession->delete()
> 
> I everything working?
> 
> Which version of CGI::Session are you using?


$CGI::Session::VERSION  = '4.41';

I think it's working. There is no spurious session, and $i is
initialized as intended from the secondary CGI::Session object.

I /really/ appreciate your patience, Ron. Esp. in regards to the fact
that you examined the code to investigate the potential abuse of
CGI::Session.

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On 05/02/2010 04:35 PM, Ron Savage wrote:
> Hi Jeff
> 
> I have received your email which follows this one.

Good. I posit a solution in that message.

> 
> On Sun, 2010-05-02 at 11:23 -0700, Jeff Chimene wrote:
>> On 04/30/2010 05:36 PM, Jeff Chimene wrote:
>>> Hi:
>>>
>>> I'm trying to change the session file name.
>>>
>>> Given the following code:
>>> 	use CGI::Session::Driver::file;
>>> 	$CGI::Session::Driver::file::FileName = "%s.dat";
>>> 	die;
>>>
>>> I find a spurious session file. Is this expected behavior?
>>>   
>> Hi Ron:
>>
>> Sorry, I cannot let this go.
> 
> No need to apologize.
> 
>> Let's start negotiations with the following routine. The "found
>> spurious" message is in the log. The session file does load.
> 
> Which session, though, gets loaded?

They're both loaded.

I have to admit though, that I did not check ATIME in the code.

> 
>> spurious session:   _SESSION_ATIME => 1272823871
>> legitimate session: _SESSION_ATIME => 1272823852
>>
>> There is a "primary" session in $postdata; which provides  bootstrap
>> information necessary to retrieve the legitimate session.
> 
> Hmmm. This is the first time you've mentioned chaining sessions.

Yes, that's the case. I've been trying to avoid that "little wrinkle"
> 
> To me this says you're using user/session dependent parameters to
> specify the session, rather than using parameters which apply uniformly
> to all sessions.

Correct. The legitimate session is a work-in-progress session, to which
the user can return over a period of days.

> I'm just noting this because it adds complexity, and
> complexity /automatically/ raises a big, red, flag.
> 
> That does not mean what you are doing is wrong, just complex :-(.
> 
>> I switched to "load()" from "new()" in an attempt to address this issue.
>>
>> #%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> #
>> sub GetLocalReportState
>> ##
>> ##%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>> {
>>     use File::Spec;
>>     use CGI::Session::Driver::file;
>>     $CGI::Session::Driver::file::FileName = "%s.dat";
>>     $i->param( 'report_id', $postdata->{report}->{report_id} || '' );
>>     $i->param( 'inspection_company_id', $postdata->{inspectionCompanyId} );
>>     my $dataPath = join( '', $CompanyDataPath,
>> $i->param('inspection_company_id'), '/reports/' );
> 
> OK. So you're generating a company-dependent path to the primary session
> file, right?

Almost. The company-dependent path is to the secondary session.

> 
>>     my $sessionFile = File::Spec->catfile(
>>         $dataPath    #
>>         , sprintf( $CGI::Session::Driver::file::FileName,
>> $i->param('report_id') )
>>     );
>>
>>     if ( -e $sessionFile )
>>     {
>>         my $cgiSession = CGI::Session->load( "id:static",
>> $i->param('report_id'), { Directory => $dataPath } );
>>         $cgiSession->load_param($i);
> 
> This is loading the primary session, right?

No. It's loading the secondary session. The primary session has already
successfully loaded. I'm going to adopt your terminology. The primary
session has successfully loaded by this time; which new() operation is
not shown here (as it's not part of this subroutine).

> 
> But load_param takes 2 parameters: ($query, $params). How is ($i) going
> to work?

The CGI session was initialized outside of this subroutine.

> 
> Hopefully, this is /the/ bug.

Sorry, that's not it.

> Besides the complexity of chained session, which I suggest you
> eliminate, the CGI::Session code connected to
> $CGI::Session::Driver::file::FileName assumes a %s in the file name,
> doesn't it, into which CGI::Session will inject the id.
> 
> But you don't have that, so I guess that's not what you're trying to set
> up, although that was certainly my first impression.

Eh? From the code:

$CGI::Session::Driver::file::FileName = "%s.dat";

Perhaps I'm missing your point...

> 
> This is another side effect of the complexity I mentioned!
> 
>>         $logger->trace("found spurious session") if -e
>> $dataPath.$cgiSession->id().'.dat';
>>         $logger->logcroak(CGI::Session->errstr()) unless
>> CGI::Session->errstr() eq '';
>>         return 'OK';
>>     }
>>     $logger->logcroak("cannot find $sessionFile: $!");
>> } ## end sub GetLocalReportState
> 
> 

The above was resolved (?) via $cgiSession->delete()

Cheers,
jec

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On 05/02/2010 11:23 AM, Jeff Chimene wrote:
> On 04/30/2010 05:36 PM, Jeff Chimene wrote:
>> Hi:
>>
>> I'm trying to change the session file name.
>>
>> Given the following code:
>> 	use CGI::Session::Driver::file;
>> 	$CGI::Session::Driver::file::FileName = "%s.dat";
>> 	die;
>>
>> I find a spurious session file. Is this expected behavior?
>>   
> Hi Ron:
> 
> Sorry, I cannot let this go.
> 
> Let's start negotiations with the following routine. The "found
> spurious" message is in the log. The session file does load.
> 
> spurious session:   _SESSION_ATIME => 1272823871
> legitimate session: _SESSION_ATIME => 1272823852
> 
> There is a "primary" session in $postdata; which provides  bootstrap
> information necessary to retrieve the legitimate session.
> 
> I switched to "load()" from "new()" in an attempt to address this issue.

I think this is the way it has to work. Given the following sequence of
events:
1) use new() to load the 1st session and establish the 2nd session's
location parameters;
2) use the location parameters to set the FileName variable;
3) load() the 2nd session;
4) the 2nd session variable goes out-of-scope;
5) flush() is called, which writes the 2nd session;

Perhaps 2ndSession->delete() addresses the issue.