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

[Cgi-session-user] Progress report on all RT bug reports

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

Hi Folks

I had a look at the bug list for CGI::Session on RT, and it gave me a
fright, so I decided to do something about it.

I've gathered the suggestions from RT and various test file patches of
my own, so come up with this status report:

1)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=33635

Status: Not yet investigated

Next: Should have time next week to investigate

2)
RT: ttp://rt.cpan.org/Public/Bug/Display.html?id=33437

Status: Patch applied, but it breaks name.t

Next: Should have time next week to investigate

3)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=29138

Status: Can be closed. Patched successfully as per RT

4)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=32932

Status: Not yet investigated

Next: Should have time next week to investigate

5)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=29969

Status: Can be closed. I've successfully patched various test programs

6)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=25325

Context: JSON

Status: Not yet investigated. See separate email thread

Next: Should have time next week to investigate

7)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=28516

Context: Utf8

Status: New test written. See seperate email thread

8)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=17299

Context: Auto-flush

Status: Still open

9)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=24601

Status: Can be closed. Patched successfully as per RT

10)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=24355

Status: Can be closed. Patched successfully as per RT

11)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=24285

Status: Can be closed. New test written. Original code now works anyway

12)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=23597

Status: Can be closed. User error!

13)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=17541

Status: See (8) above re 17299

14)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=18948

Status: Still open

Next: Should have time next week to investigate

15)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=2224

Status: Still open

Next: Should have time next week to investigate (using Pg)

16)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=21981

Status: See (7) above re 28516

In a few days I'll upload to my web site a set of patch files against V
4.20 for people to play with.
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] Problem with CGI::Session v. 4.20 while generating a new session

[Jerry C. <21...@gm...>]

I'm a new user of CGI::Session.  I ran into the same problem as
described in this post from last year:

http://sourceforge.net/mailarchive/message.php?msg_id=DD7DA0AF20A23F49BC1077FC296F0ECF039F5532%40mucse306.eu.infineon.com

using perl 5.6.1.

After hours of debugging, I figured out the cause:  Scalar::Util is
missing in my perl 5.6.1

Once I installed that package, the problem has gone away.

Ulrich, hope this may help if you still have the problem.

Jerry

Re: [Cgi-session-user] [rt.cpan.org #29138] New bug report for CGI::Session

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

This change looks OK to me.

However, I'm about to have a baby any day (hour?) now, so if someone 
else could update the code, tests and changelog for this, that would be 
appreciated.  (Antirice, still there?)

Just post a patch in "diff -u" format as an attachment to this bug 
report, or commit directly if you have access.

    Mark

Barry Friedman via RT wrote:
>        Queue: CGI-Session
>  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=29138 >
> 
> Nick,
> 
> Could you please be specific as to which file you are fixing?
> I am having similar problems and do not see a follow up to this
> report.  (A context diff would be useful)
> 
> Another case to consider is when a browser has been closed and the
> session cookie is deleted,  then the browser is restarted and
> CGI::Session does not have a session id cookie.
> 
> Thanks,
> Barry Friedman
> 
> On Mon Sep 03 14:13:42 2007, ni...@an... wrote:
>>  
>> Looking at the code I believe this is fixed by the addition of the
>> following 1 extra line
>> after line 82:
>>  
>> $dataref->{_SESSION_REMOTE_ADDR} = $ENV{REMOTE_ADDR} || "";
>>  
>> I hope that my analysis is correct, and that this will enable the
>> posting of
>> a corrected version of the module.
>>  
>> Best wishes,
>> Nick Andrews
>>  
> 
> 
> 

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

Re: [Cgi-session-user] Session name, CGI::Session and CAP::Session (post from cgi-app mailing)

[Lee C. <lec...@ya...>]

Hello Cees,


Thanks for the pointer at the newer version.


It seems that it will have the same issue with initial retrieval since 'new' calls 'load' which calls 'name' but at this point it uses the class attribute. After that initial load, the 'name' value can be changed on the instance. 


I think the 'load' method should take a parameter for this value. I can certainly put together a patch. 


Thanks for your time,


Lee



----- Original Message ----
From: Cees Hek <ce...@gm...>
To: Lee Carmichael <lec...@ya...>
Cc: CGI Session Users Mailing List <cgi...@li...>
Sent: Friday, February 15, 2008 5:20:40 PM
Subject: Re: [Cgi-session-user] Session name, CGI::Session and CAP::Session (post from cgi-app mailing)

On Sat, Feb 16, 2008 at 8:08 AM, Lee Carmichael <lec...@ya...> wrote:
> [ Sorry for the dual post of the email, but I just realized there was a cgi-session mailing ]
>
>  Hello Everyone,
>
>  I am having a bit of an issue with how the 'name' attribute is being set on CGI::Session (CGI::Session->name). It is necessary to set the class value for 'name' before creating a session after which it is possible and useful to set it on the instance.

I think that CGI::Session 4.10 fixed this by allowing you to call
->name as an instance method ( $session->name('MyName') ).  However, I
haven't used this with CGI::Application::Plugin::Session yet, so it
might require a patch to the plugin to get it to work nicely.

Cheers,

Cees

Re: [Cgi-session-user] Session name, CGI::Session and CAP::Session (post from cgi-app mailing)

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

On Sat, Feb 16, 2008 at 8:08 AM, Lee Carmichael <lec...@ya...> wrote:
> [ Sorry for the dual post of the email, but I just realized there was a cgi-session mailing ]
>
>  Hello Everyone,
>
>  I am having a bit of an issue with how the 'name' attribute is being set on CGI::Session (CGI::Session->name). It is necessary to set the class value for 'name' before creating a session after which it is possible and useful to set it on the instance.

I think that CGI::Session 4.10 fixed this by allowing you to call
->name as an instance method ( $session->name('MyName') ).  However, I
haven't used this with CGI::Application::Plugin::Session yet, so it
might require a patch to the plugin to get it to work nicely.

Cheers,

Cees

[Cgi-session-user] Session name, CGI::Session and CAP::Session (post from cgi-app mailing)

[Lee C. <lec...@ya...>]

[ Sorry for the dual post of the email, but I just realized there was a cgi-session mailing ]

Hello Everyone,

I am having a bit of an issue with how the 'name' attribute is being set on CGI::Session (CGI::Session->name). It is necessary to set the class value for 'name' before creating a session after which it is possible and useful to set it on the instance. 

I have a base class that I use for multiple CGI::App sub classes, this setups the main support for CAP::Session. Since we have lots of different cgi based apps that do very different things and that shouldn't really share session data, I need a way to alter this name. The main problem is that some of these apps are mod-perl based, which is where the class value causes issues ( or has the potential for issues). I know that I could use the 'path' value but there are cases where two subclasses could use the same session but be at different paths... ( I know, I'm being a pain in the butt :)

I have found a solution but I'm not sure its the best one. In the base class, I allow each class to set the name differently for each app as a parameter. The main problem I run into is to prevent issues with it storing that for all other sub classes, I need to do something like:

... in some code that is called as a init callback....

    ## fetch current global name
    my $old  = CGI::Session->name;

    ## change it temporarily until new session has been created
    CGI::Session->name( $self->session_name );
    $self->session->name( $self->session_name );

    ## restore global one 
    CGI::Session->name( $old);

This is pretty ugly but I couldn't figure out a way around it. This give me a brief amount of time where the package value is set and I hope that it doesn't get used (or reset) by another app. Most of the apps are used by just a few (or single) users so this isn't a huge problem. But it just doesn't feel right.

>From looking at the CGI::Session code, I don't there is another way to do this. Any ideas? 

One solution that I had was a new hash ref of parameters could be passed to 'new' and 'load' (of CGI::Session). Something like:

CGI::Session->new( 'driver:File', $self->query, { Directory  => File::Spec->tmpdir}, { name => 'SpecialName', update_atime => 1, .... } );

I am very willing to create a patch and tests for this new constructor option, if it makes sense to everyone.

Also, I have noticed that CAP::Session uses CGI::Session->name is a few places where the instance may have changed the parameter and will require a patch to fix these issues. I am willing to produce a patch and test for these issues as well.

Thanks, 

Lee

Re: [Cgi-session-user] strange behavior with CGI::Application::Plugin::Session and SQLite

[Ulrike S. <ul...@go...>]

Mr. Puneet Kishor schrieb:
> sqlite> select * from sessions;
> 4510a1b1c1db6aec8e23d8ee6d6a1938|1234
> 912574e844d18f4ca5d8dcba4f8a7fd1|1234
>   

> So, am I correct in deciphering that the Storable serializer is not  
> serializing and storing data in the table properly, or perhaps, it is  
> not even reaching that far because the $dbh is breaking in transit  
> somehow?
>
> Any suggestions/guidance will be appreciated.
>
>   

If I look in my sessions table there are a lot of strange characters
before and after "1234", maybe sqlite has only problems displaying them?
Can you make your script display the retrieved data, not what is stored
in the table, since this is encoded?

I am also having problems with a similar setup as yours (newest
CGI:Session, CGI::Application::Plugin::Session) with the difference that
I am working with opensuse 10.2 and mysql.

I tried several configurations and finally found one that works if I set
the collation of the sessions table to ascii_general_ci, don't feed it
any exotic data like Umlaute or Japanese characters and don't try to
save too much data. This makes it not really usable for me,
unfortunately. If the sessions table has the collation utf8_unicode_ci
it dies.

One test-parameter, however, shows some strange behavior: I have a
number increment everytime a certain routine is called and save it in
the session. During the first call it is correctly incremented from 0 to
1. Wenn the script is called the next time, the number retrieved form
the sesion is not "1", but "-65". From then on, however, it is correctly
incremented everytime I call the script.

This configuration is similar to yours:
$self->session_config( CGI_SESSION_OPTIONS =>
["driver:mysql;serializer:storable;id:md5",$self->query, {Handle=>$dbh }] );

If something goes wrong the script dies with "Can't locate object method
"errstr" via package "CGI::Session::Serialize::storable" at
/usr/lib/perl5/site_perl/5.8.8/CGI/Session.pm line 720, line 186."

But if everything goes ok I have no error messages whatsoever in my
logs. I mention this because none of the default settings work for me
without problems.

With "driver:mysql;serializer:default;id:md5" I get "Bareword found
where operator expected at
/usr/lib/perl5/site_perl/5.8.8/CGI/Session/Serialize/default.pm line 22,
near "new Data::Dumper" (Do you need to predeclare new?)" And nothing is
saved in the table.

As I finished writing this I found that other people are/were having
problems with CGI::Session, utf-8 and mysql:
http://www.perlmonks.org/index.pl?node_id=629094
I will do some reading now...

Uli

Re: [Cgi-session-user] strange behavior with CGI::Application::Plugin::Session and SQLite

[Mr. P. K. <pu...@ei...>]

Problem solved but questions remain --

First, thanks Ron, but unfortunately your code-snippet was not needed,  
and your suggested solution was not the solution to my problem (see  
original post below for the details on the problem).

In summary, I was getting an error message like so --

DBD::SQLite::db prepare warning: attempt to prepare on inactive  
database handle(0) at dbdimp.c line 249 at /usr/local/lib/perl5/ 
site_perl/5.8.8/CGI/Session/Driver/sqlite.pm line

My problem was happening because I had included a teardown routine in  
my application that was disconnecting the $dbh like so --

sub teardown {
   my $self = shift;

   # Disconnect when we're done, (Although DBI usually does this  
automatically)
   my $dbh = $self->dbh;
   $dbh->disconnect;
}

Removing this teardown solved the problem. So, there seems to be a  
disconnect between teardown from CGI::App and CGI::Session.

Two more things --

I don't know if this matters or not, but in CGI::App::Plugin::Session,  
the syntax is

CGI_SESSION_OPTIONS => [ "driver:PostgreSQL;serializer:Storable",  
$self->query, {Handle=>$dbh} ],
While in CGI::Session the syntax for the serializer is

CGI::Session::Serialize::storable

I am not sure if the capitalization difference between Storable and  
storable matters.

Finally, the sessions table is defined with a_session TEXT NOT NULL,  
however, doesn't Storable serialize to a binary object? Hence,  
wouldn't it be better to define a_session BLOB?

On Feb 1, 2008, at 8:57 PM, Mr. Puneet Kishor wrote:

> Greetings,
>
> I am doing my work on my Macbook with Perl 5.88 and CGI::Session 4.2  
> and the latest CGI::Application::Plugin::Session with DBD::SQLite 1.14
>
> Here is what I see in my sessions table
>
> *****************
> sqlite> .s
> CREATE TABLE sessions (
>        id        CHAR(32) NOT NULL PRIMARY KEY,
>        a_session TEXT NOT NULL
>      );
> sqlite> select * from sessions;
> 4510a1b1c1db6aec8e23d8ee6d6a1938|1234
> 912574e844d18f4ca5d8dcba4f8a7fd1|1234
> *****************
>
> Here is a bit of code
>
> *****************
>  # Connect to DBI database, with the same args as DBI->connect();
>  $self->dbh_config(
>    "dbi:SQLite:dbname=$db", "", "", { RaiseError => 1, AutoCommit =>  
> 1 }
>  );
>
>  my $dbh = $self->dbh;
>  $dbh->{unicode} = 1;
>
>  # Configure the session
>  $self->session_config(
>    CGI_SESSION_OPTIONS => [ "driver:sqlite;serializer:Storable",  
> $self->query, {Handle => $dbh} ],
>    DEFAULT_EXPIRY      => "+1w",
>    COOKIE_PARAMS       => { -expires => "+24h", -path => "/", },
>    SEND_COOKIE         => 1,
>  );
>
> and then, further down...
>
>  $self->session->param("~user_id", $aref_nodes);
> *****************
>
>
> and here is an error message from the Apache error_log
>
> *****************
> [Fri Feb 01 19:39:32 2008] [error] [client 127.0.0.1]  
> DBD::SQLite::db prepare warning: attempt to prepare on inactive  
> database handle(0) at dbdimp.c line 249 at /usr/local/lib/perl5/ 
> site_perl/5.8.8/CGI/Session/Driver/sqlite.pm line 34., referer: http://localhost/~punkish/ckb/index.cgi
> *****************
>
> Of course, line 34 in the above file is
>
>
> *****************
> 32:    my $dbh = $self->{Handle};
> 33:
> 34:    my $sth = $dbh->prepare("SELECT id FROM " . $self- 
> >table_name . " WHERE id=?");
> 35:    unless ( defined $sth ) {
> 36:        return $self->set_error( "store(): \$sth->prepare failed  
> with message " . $dbh->errstr );
> 37:    }
> *****************
>
> So, am I correct in deciphering that the Storable serializer is not  
> serializing and storing data in the table properly, or perhaps, it  
> is not even reaching that far because the $dbh is breaking in  
> transit somehow?
>
> Any suggestions/guidance will be appreciated.
>
> Many thanks,
>
> Puneet.

-- 
Puneet Kishor http://punkish.eidesis.org/
Ph.D. Program, Nelson Institute, UW-Madison http://www.nelson.wisc.edu/
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org/
-----------------------------------------------------------------------
collaborate, communicate, compete
=======================================================================

Re: [Cgi-session-user] strange behavior with CGI::Application::Plugin::Session and SQLite

[Mr. P. K. <pu...@ei...>]

On Feb 1, 2008, at 10:39 PM, Ron Savage wrote:

> On Fri, 2008-02-01 at 21:45 -0600, Mr. Puneet Kishor wrote:
>
> Hi Puneet
>
>> On Feb 1, 2008, at 9:24 PM, Ron Savage wrote:
>>
>>> On Fri, 2008-02-01 at 20:57 -0600, Mr. Puneet Kishor wrote:
>>>
>>> Hi Puneet
>>>
>>>>  my $dbh = $self->dbh;
>>>
>>>> 32:    my $dbh = $self->{Handle};
>>>
>>> Why not use:
>>>
>>> 	my $dbh = $self -> dbh();
>>>
>>> Or, does sub dbh_config() store $dbh into $self -> {Handle}?
>>>
>>
>> I have no idea why... that line is from /usr/local/lib/perl5/ 
>> site_perl/
>> 5.8.8/CGI/Session/Driver/sqlite.pm which was not written by me.
>>
>> The "Handle" bit comes from
>>
>>   # Configure the session
>>   $self->session_config(
>>     CGI_SESSION_OPTIONS => [ "driver:sqlite;serializer:Storable",
>> $self->query, {Handle => $dbh} ],
>>     DEFAULT_EXPIRY      => "+1w",
>>     COOKIE_PARAMS       => { -expires => "+24h", -path => "/", },
>>     SEND_COOKIE         => 1,
>>   );
>>
>> which is from the C:A:P:Session docs. I am just following the
>> instructions.
>
> Just because you call session_config with {Handle => $dbh} does not  
> mean
> you can later use my $dbh = $self -> {Handle}. Fix that problem first.

Ron,

I have absolutely no idea what I am supposed to fix. Could you kindly  
be more explicit/guide me in this? As I said above, I am *not* the one  
using
	my $dbh = $self -> {Handle}

That is from CGI::Session::Driver::sqlite.pm which was written by I- 
don't-know-who

None of the code above is mine except for the following line
	$self->session->param("~user_id", $aref_nodes);

Re: [Cgi-session-user] strange behavior with CGI::Application::Plugin::Session and SQLite

[Mr. P. K. <pu...@ei...>]

On Feb 1, 2008, at 9:24 PM, Ron Savage wrote:

> On Fri, 2008-02-01 at 20:57 -0600, Mr. Puneet Kishor wrote:
>
> Hi Puneet
>
>>   my $dbh = $self->dbh;
>
>> 32:    my $dbh = $self->{Handle};
>
> Why not use:
>
> 	my $dbh = $self -> dbh();
>
> Or, does sub dbh_config() store $dbh into $self -> {Handle}?
>

I have no idea why... that line is from /usr/local/lib/perl5/site_perl/ 
5.8.8/CGI/Session/Driver/sqlite.pm which was not written by me.

The "Handle" bit comes from

   # Configure the session
   $self->session_config(
     CGI_SESSION_OPTIONS => [ "driver:sqlite;serializer:Storable",  
$self->query, {Handle => $dbh} ],
     DEFAULT_EXPIRY      => "+1w",
     COOKIE_PARAMS       => { -expires => "+24h", -path => "/", },
     SEND_COOKIE         => 1,
   );

which is from the C:A:P:Session docs. I am just following the  
instructions.

[Cgi-session-user] strange behavior with CGI::Application::Plugin::Session and SQLite

[Mr. P. K. <pu...@ei...>]

Greetings,

I am doing my work on my Macbook with Perl 5.88 and CGI::Session 4.2  
and the latest CGI::Application::Plugin::Session with DBD::SQLite 1.14

Here is what I see in my sessions table

*****************
sqlite> .s
CREATE TABLE sessions (
         id        CHAR(32) NOT NULL PRIMARY KEY,
         a_session TEXT NOT NULL
       );
sqlite> select * from sessions;
4510a1b1c1db6aec8e23d8ee6d6a1938|1234
912574e844d18f4ca5d8dcba4f8a7fd1|1234
*****************

Here is a bit of code

*****************
   # Connect to DBI database, with the same args as DBI->connect();
   $self->dbh_config(
     "dbi:SQLite:dbname=$db", "", "", { RaiseError => 1, AutoCommit =>  
1 }
   );

   my $dbh = $self->dbh;
   $dbh->{unicode} = 1;

   # Configure the session
   $self->session_config(
     CGI_SESSION_OPTIONS => [ "driver:sqlite;serializer:Storable",  
$self->query, {Handle => $dbh} ],
     DEFAULT_EXPIRY      => "+1w",
     COOKIE_PARAMS       => { -expires => "+24h", -path => "/", },
     SEND_COOKIE         => 1,
   );

and then, further down...

   $self->session->param("~user_id", $aref_nodes);
*****************


and here is an error message from the Apache error_log

*****************
[Fri Feb 01 19:39:32 2008] [error] [client 127.0.0.1] DBD::SQLite::db  
prepare warning: attempt to prepare on inactive database handle(0) at  
dbdimp.c line 249 at /usr/local/lib/perl5/site_perl/5.8.8/CGI/Session/ 
Driver/sqlite.pm line 34., referer: http://localhost/~punkish/ckb/index.cgi
*****************

Of course, line 34 in the above file is


*****************
32:    my $dbh = $self->{Handle};
33:
34:    my $sth = $dbh->prepare("SELECT id FROM " . $self->table_name .  
" WHERE id=?");
35:    unless ( defined $sth ) {
36:        return $self->set_error( "store(): \$sth->prepare failed  
with message " . $dbh->errstr );
37:    }
*****************

So, am I correct in deciphering that the Storable serializer is not  
serializing and storing data in the table properly, or perhaps, it is  
not even reaching that far because the $dbh is breaking in transit  
somehow?

Any suggestions/guidance will be appreciated.

Many thanks,

Puneet.

Re: [Cgi-session-user] a bug or two related to _load_pluggables? (was: Problem With CGI::Session v. 4.20 while generating a new session)

[Ulrike S. <ul...@go...>]

Unfortunately with my "solution" I just don't get certain errors any
more, but nothing is stored in the session. I tried
$session->expire('+1h'), but it does not help.

So I tried the workaround again, but it seems to conflict somehow with
my application, I don't get any search results when I set the
parameters. If I use the defaults with my "fix" they come as expected.

When I use $session->flush the script dies in both cases.

What am I doing wrong? Thanks a lot in advance,

Uli

Ulrike Schmidt schrieb:
> Hi,
>
> I was bitten by the same problem. The suggested workaround (explicitly
> naming the serializer, driver and ID generator) helps, but I do have to
> include the line "use CGI::Session::ID::md5;".
>
> In the log I found the message: Bareword found where operator expected
> at /usr/lib/perl5/site_perl/5.8.8/CGI/Session/Serialize/default.pm line
> 22, near "new Data::Dumper",(Do you need to predeclare new?)
>
> So I changed  the line:
>
> <     my $d =
> <     new Data::Dumper([$data], ["D"]);
> ---
>   
>>     my $d = Data::Dumper->new([$data], ["D"]);
>>     
>
> Now the defaults work without the workaround, but I get the following
> line in my log:
> (in cleanup) Can't call method "new" without a package or object
> reference at
> /usr/lib/perl5/site_perl/5.8.8/CGI/Session/Serialize/default.pm line 21
>
> Not sure what this is supposed to mean ...
>
> Uli
>
>   
>>> I just wanted to create a new session and got some errors. My code is
>>> the following:
>>>
>>> use strict;
>>> use Env;
>>> use File::Basename;
>>> use DBI;
>>> use lib dirname(__FILE__) . '';
>>> use CGI;
>>> use CGI::Carp "fatalsToBrowser";
>>> use CGI::Session;
>>> use CGI::Session::ID::md5;
>>> use Digest::MD5 qw(md5 md5_hex md5_base64);
>>>
>>> my $sid = md5($ENV{UNIQUE_ID});
>>> my $cgi = new CGI;
>>>
>>> #print "Content-Type: text/html\n\n";
>>> print $cgi->start_html(
>>>
>>> -title => 'Switch.cgi',
>>> -author => 'UlrichW.External@qi...'
>>> );
>>> #print $sid;
>>> my $session = new CGI::Session(undef, undef,
>>> {Directory=>'/tmp/session'}) or die CGI::Session->errstr;
>>> $sid = $session->id();
>>> print $sid;
>>>
>>> The error-message is the folowing:
>>>
>>> session.cgi: Use of uninitialized value in concatenation (.) or string
>>> at /opt/webserver/software/perl/lib/5.6.1/CGI/Session.pm line 128.
>>> Can't locate object method "generate_id" via package
>>> "CGI::Session::ID::" at
>>> /opt/webserver/software/perl/lib/5.6.1/CGI/Session.pm line 74.
>>>
>>> I'm using Perl-Version 5.6.1
>>> CGI.pm has the version 3.05
>>> And Session.pm has the version 4.20
>>>       
>> Ulrich,
>>
>> First, you can remove this line: It shouldn't be needed:
>>
>>     
>>> use CGI::Session::ID::md5;
>>>       
>> I see what looks like a bug (or two), but I don't understand why it
>> wouldn't
>> affect more people.
>>
>> First bug:
>> - 'sub _id_generator' uses a variable without checking to see if it
>> exists first. If it did, it could have returned a more friendly error
>> message than the one you got.
>> (This is not causing your problem, but is related).
>>
>> Second bug:
>> - 'sub _load_pluggables' takes care of loading a default ID generator,
>> and putting the result in $self->{_DSN}{id}, which doesn't seem to
>> be happening for you.
>>
>> Look at line 798 in CGI/Session.pm:
>>
>> $dsn->{ $plug } = $mod_name = $1;
>>
>> By using Data::Dumper and 'warn', inspect the values
>> of '$dsn->{$plug}' and '$mod_name' before and after that line.
>>
>> By continuing to debug in 'sub _load_pluggables', I think you'll find
>> the issue. Maybe it's something related to Perl 5.6.1 being older?
>> Did the whole test suite pass for you OK?
>>
>> If you need an immediate result, the workaround seems to be explicitly
>> name the serializer, driver and ID generator you want in the DSN.
>>
>> Mark
>>     
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>
>   

Re: [Cgi-session-user] a bug or two related to _load_pluggables? (was: Problem With CGI::Session v. 4.20 while generating a new session)

[Ulrike S. <ul...@go...>]

Hi,

I was bitten by the same problem. The suggested workaround (explicitly
naming the serializer, driver and ID generator) helps, but I do have to
include the line "use CGI::Session::ID::md5;".

In the log I found the message: Bareword found where operator expected
at /usr/lib/perl5/site_perl/5.8.8/CGI/Session/Serialize/default.pm line
22, near "new Data::Dumper",(Do you need to predeclare new?)

So I changed  the line:

<     my $d =
<     new Data::Dumper([$data], ["D"]);
---
>     my $d = Data::Dumper->new([$data], ["D"]);

Now the defaults work without the workaround, but I get the following
line in my log:
(in cleanup) Can't call method "new" without a package or object
reference at
/usr/lib/perl5/site_perl/5.8.8/CGI/Session/Serialize/default.pm line 21

Not sure what this is supposed to mean ...

Uli

> > I just wanted to create a new session and got some errors. My code is
> > the following:
> >
> > use strict;
> > use Env;
> > use File::Basename;
> > use DBI;
> > use lib dirname(__FILE__) . '';
> > use CGI;
> > use CGI::Carp "fatalsToBrowser";
> > use CGI::Session;
> > use CGI::Session::ID::md5;
> > use Digest::MD5 qw(md5 md5_hex md5_base64);
> >
> > my $sid = md5($ENV{UNIQUE_ID});
> > my $cgi = new CGI;
> >
> > #print "Content-Type: text/html\n\n";
> > print $cgi->start_html(
> >
> > -title => 'Switch.cgi',
> > -author => 'UlrichW.External@qi...'
> > );
> > #print $sid;
> > my $session = new CGI::Session(undef, undef,
> > {Directory=>'/tmp/session'}) or die CGI::Session->errstr;
> > $sid = $session->id();
> > print $sid;
> >
> > The error-message is the folowing:
> >
> > session.cgi: Use of uninitialized value in concatenation (.) or string
> > at /opt/webserver/software/perl/lib/5.6.1/CGI/Session.pm line 128.
> > Can't locate object method "generate_id" via package
> > "CGI::Session::ID::" at
> > /opt/webserver/software/perl/lib/5.6.1/CGI/Session.pm line 74.
> >
> > I'm using Perl-Version 5.6.1
> > CGI.pm has the version 3.05
> > And Session.pm has the version 4.20
>
> Ulrich,
>
> First, you can remove this line: It shouldn't be needed:
>
> > use CGI::Session::ID::md5;
>
> I see what looks like a bug (or two), but I don't understand why it
> wouldn't
> affect more people.
>
> First bug:
> - 'sub _id_generator' uses a variable without checking to see if it
> exists first. If it did, it could have returned a more friendly error
> message than the one you got.
> (This is not causing your problem, but is related).
>
> Second bug:
> - 'sub _load_pluggables' takes care of loading a default ID generator,
> and putting the result in $self->{_DSN}{id}, which doesn't seem to
> be happening for you.
>
> Look at line 798 in CGI/Session.pm:
>
> $dsn->{ $plug } = $mod_name = $1;
>
> By using Data::Dumper and 'warn', inspect the values
> of '$dsn->{$plug}' and '$mod_name' before and after that line.
>
> By continuing to debug in 'sub _load_pluggables', I think you'll find
> the issue. Maybe it's something related to Perl 5.6.1 being older?
> Did the whole test suite pass for you OK?
>
> If you need an immediate result, the workaround seems to be explicitly
> name the serializer, driver and ID generator you want in the DSN.
>
> Mark

[Cgi-session-user] The JSON serializer mess

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

The JSON serializer has been a source of "make test" failures for
CGI::Session for a while. Tonight I looked into it.

It turns out it uses the "JSON::Syck" module, which is reported to be
buggy and unmaintained. Using "JSON::Any" seems to the best alternative,
as it can load any number of available JSON modules to get the job done.

But there is not clear way to make that upgrade go smoothly, without
requiring "JSON::Any" for the whole distribution, when we currently
require no JSON modules.

Howevever, even when I tried using JSON::Any as a serializer with a
different JSON module back-end...tests still failed.

For me, this was the final straw: the JSON driver will ejected from the
distribution in the next release, and anyone who wants can start to
maintain it themselves.

I might have done this tonight, but I couldn't get SVN access to our
code repository to work, so nothing was comitted.

Otherwise, Happy New Year!

     Mark

Re: [Cgi-session-user] session files don't get deleted after they expired, workaround?

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

On Thu, 2008-01-03 at 12:26 +0100, ste...@gm...

Hi Stefan

> you could use the (experimental) method find(), which will try to 

[snip]

> If anybody out there knows a better way for this, I'd be glad to hear
> as well!

http://search.cpan.org/~rsavage/CGI-Session-ExpireSessions-1.08/
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] session files don't get deleted after they expired, workaround?

[<ste...@gm...>]

Hi,

you could use the (experimental) method find(), which will try to load all
session objects stored on disk and which removes all expired ones (it won't
do anything to the other, valid ones when using empty sub)

> CGI::Session->find( sub {} );

You may put it either in a cronjob or start a small script with it manually
(e. g. on a regular base). I wouldn't include this line into your normal
script because it may need a few seconds if many sessions are active in
parallel...

If anybody out there knows a better way for this, I'd be glad to hear as
well!

Best regards

Stefan.

On 1/3/08, Andreas Schipplock <an...@sc...> wrote:
>
> Hi,
> I'm using cgi::session 4.20 and I use the expire() method to set an
> expire time for sessions and it really works great but I also expect
> the sessionfile on disk (/tmp/cgisess_*) do be deleted after the
> session has expired but that's simply not the case.
> The files are small and aren't really a problem storage wise but I
> can't delete session files on occasion :P as I don't know if they
> expired or still valid.
>
> Can you give me a hint on how to solve that "problem"?
> I really appreciate your help.
>
> Have a nice day,
> Andreas.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

[Cgi-session-user] session files don't get deleted after they expired, workaround?

[Andreas S. <an...@sc...>]

Hi,
I'm using cgi::session 4.20 and I use the expire() method to set an
expire time for sessions and it really works great but I also expect
the sessionfile on disk (/tmp/cgisess_*) do be deleted after the
session has expired but that's simply not the case.
The files are small and aren't really a problem storage wise but I
can't delete session files on occasion :P as I don't know if they
expired or still valid.

Can you give me a hint on how to solve that "problem"?
I really appreciate your help.

Have a nice day,
Andreas.

[Cgi-session-user] Fwd: JSON driver for CGI::Session still broken.

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

We continue to get test failures for the JSON::Syck driver. It would be
great if someone could fix them, or volunteer to maintain this as a
separate distribution.

If not, I will likely be ejecting this driver from the distribution the
next time I have a chance to work on it.

   Mark

----------  Forwarded Message  ----------

Subject: FAIL CGI-Session-4.20 i686-linux-64int 2.6.22-1-k7
Date: Friday 07 September 2007 04:26
From: and...@fr...
To: cpa...@pe...
Cc: MAR...@cp...

This distribution has been tested as part of the cpan-testers
effort to test as many new uploads to CPAN as possible.  See
http://testers.cpan.org/

Please cc any replies to cpa...@pe... to keep other
test volunteers informed and to prevent any duplicate effort.

--
Dear Mark Stosberg,

This is a computer-generated test report for CGI-Session-4.20, created
automatically by CPAN::Reporter, version 0.4801, and sent to the CPAN
Testers mailing list.  If you have received this email directly, it is
because the person testing your distribution chose to send a copy to
 your CPAN email address; there may be a delay before the official
 report is received and processed by CPAN Testers.

Thank you for uploading your work to CPAN.  However, it appears that
there were some problems testing your distribution.

Sections of this report:

    * Tester comments
    * Prerequisites
    * Environment and other context
    * Test output

------------------------------
TESTER COMMENTS
------------------------------

Additional comments from tester:

[none provided]

------------------------------
PREREQUISITES
------------------------------

Prerequisite modules loaded:

requires:

    Module       Need  Have
    ------------ ----- --------
    Data::Dumper undef 2.121_14
    Digest::MD5  undef 2.36_01
    Scalar::Util undef 1.19
    Test::More   undef 0.70

------------------------------
ENVIRONMENT AND OTHER CONTEXT
------------------------------

Environment variables:

    LANG = en_US.utf8
    PATH =
 /usr/lib/ccache:/home/sand/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X
11:/usr/games:/usr/local/perl/bin:/usr/X11/bin:/sbin:/usr/sbin PERL5LIB
 =
    PERL5_CPANPLUS_IS_RUNNING = 1992
    PERL5_CPAN_IS_RUNNING = 1992
    SHELL = /usr/bin/zsh
    TERM = screen

Perl special variables (and OS-specific diagnostics, for MSWin32):

    Perl: $^X =
 /home/src/perl/repoperls/installed-perls/perl/pR263DW/perl-5.8.0@31805
/bin/perl UID:  $<  = 1005
    EUID: $>  = 1005
    GID:  $(  = 1005 1005
    EGID: $)  = 1005 1005

Perl module toolchain versions installed:

    Module              Have
    ------------------- -------
    CPAN                1.9102
    Cwd                 3.25
    ExtUtils::CBuilder  0.19
    ExtUtils::Command   1.13
    ExtUtils::Install   1.41_04
    ExtUtils::MakeMaker 6.36_01
    ExtUtils::Manifest  1.51_01
    ExtUtils::ParseXS   2.18
    File::Spec          3.25
    Module::Build       0.2808
    Module::Signature   0.55
    Test::Harness       2.64
    Test::More          0.70
    version             0.7203

------------------------------
TEST OUTPUT
------------------------------

Output from '/usr/bin/make test':

make[3]: Entering directory
 `/home/sand/.cpan/build/CGI-Session-4.20-rsBCo0' PERL_DL_NONLAZY=1
 /home/src/perl/repoperls/installed-perls/perl/pR263DW/perl-5.8.0@31805
/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib',
 'blib/arch')" t/*.t t/api3_db_file..................ok
t/api3_db_file_freezethaw.......ok
t/api3_db_file_storable.........ok
t/api3_db_file_storable_incr....ok
t/api3_file.....................ok
t/api3_file_freezethaw..........ok
t/api3_file_freezethaw_incr.....ok
t/api3_file_storable............ok
t/api3_file_storable_incr.......ok
t/api3_incr.....................ok
t/api3_obj_store................#Using FreezeThaw as object serializer
ok
t/api3_obj_store_db_file........ok
t/bug21952......................ok
t/cgi_simple....................ok
t/complex_ds....................ok
t/driver_dbi....................ok
t/expire........................ok
t/find..........................ok
t/flush.........................ok
t/g4............................ok
t/g4_dbfile.....................ok
t/g4_dbfile_freezethaw..........ok
t/g4_dbfile_json................# JSON::Syck
	(in cleanup) Dumping circular structures is not supported with
 JSON::Syck at
 /home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Se
rialize/json.pm line 18.

#   Failed test 'Previously stored object loaded successfully'
#   at
 /home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Te
st/Default.pm line 362.

#   Failed test at
 /home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Te
st/Default.pm line 362. Use of uninitialized value in string eq at
	/home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Te
st/Default.pm line 325 (#1) (W uninitialized) An undefined value was
 used as if it were already defined.  It was interpreted as a "" or a
 0, but maybe it was a mistake. To suppress this warning assign a
 defined value to your variables.

    To help you figure out what was undefined, perl will try to tell
 you the name of the variable (if any) that was undefined. In some
 cases it cannot do this, so it also tells you what operation you used
 the undefined value in.  Note, however, that perl optimizes your
 program and the operation displayed in the warning may not necessarily
 appear literally in your program.  For example, "that $foo" is usually
 optimized into "that " . $foo, and the warning will refer to the
 concatenation (.) operator, even though there is no . in your program.

Can't call method "can" on an undefined value at
 /home/src/perl/repoperls/installed-perls/perl/pR263DW/perl-5.8.0@31805
/lib/5.10.0/overload.pm line 52. # Looks like you planned 101 tests but
 only ran 91.
# Looks like you failed 2 tests of 91 run.
# Looks like your test died just after 91.
dubious
	Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 84, 90, 92-101
	Failed 12/101 tests, 88.12% okay (less 6 skipped tests: 83 okay,
 82.18%) t/g4_dbfile_storable............ok
t/g4_dbfile_yaml................# YAML
# YAML::Syck
ok
        1/202 skipped: various reasons
t/g4_freezethaw.................ok
t/g4_mysql......................skipped
        all skipped: Couldn't establish connection with the MySQL
 server: 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 t/g4_mysql.t line 44
 t/g4_mysql_freezethaw...........skipped
        all skipped: Couldn't establish connection with the MySQL
 server: 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 t/g4_mysql_freezethaw.t line 43
 t/g4_mysql_storable.............skipped
        all skipped: Couldn't establish connection with the MySQL
 server: 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 t/g4_mysql_storable.t line 43
 t/g4_postgresql.................skipped
        all skipped: DataSource is not known
t/g4_postgresql_freezethaw......skipped
        all skipped: DataSource is not known
t/g4_postgresql_storable........skipped
        all skipped: DataSource is not known
t/g4_sqlite.....................ok
t/g4_sqlite_freezethaw..........ok
t/g4_sqlite_storable............ok
t/g4_storable...................ok
t/header........................ok
t/ip_matches....................ok
t/is_new........................ok
t/load..........................ok
t/name..........................ok
t/parse_dsn.....................ok
t/remote_addr...................ok
t/str2seconds...................ok
t/symlink_db_file...............ok
t/symlink_file..................ok
Failed Test        Stat Wstat Total Fail  List of Failed
-----------------------------------------------------------------------
-------- t/g4_dbfile_json.t  255 65280   101   22  84 90 92-101
6 tests and 7 subtests skipped.
Failed 1/46 test scripts. 12/1497 subtests failed.
Files=46, Tests=1497, 111 wallclock secs (31.80 cusr +  1.28 csys =
 33.08 CPU) Failed 1/46 test programs. 12/1497 subtests failed.
make[3]: *** [test_dynamic] Error 255
make[3]: Leaving directory
 `/home/sand/.cpan/build/CGI-Session-4.20-rsBCo0'


--

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.6.22-1-k7, archname=i686-linux-64int
    uname='linux k75 2.6.22-1-k7 #1 smp sun jul 29 15:15:55 utc 2007
 i686 gnulinux '
 config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/pR
263DW/perl-5.8.0@31805 -Dinstallusrbinperl=n -Uversiononly
 -Doptimize=-g -des -Duse64bitint -Dusedevel -Duserelocatableinc'
 hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define,
 usesocks=undef use64bitint=define, use64bitall=undef,
 uselongdouble=undef usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-DDEBUGGING -fno-strict-aliasing -pipe
 -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
 optimize='-g',
    cppflags='-DDEBUGGING -fno-strict-aliasing -pipe
 -I/usr/local/include' ccversion='', gccversion='4.1.2 20061115
 (prerelease) (Debian 4.1.1-21)', gccosandvers='' intsize=4,
 longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
 ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
 Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/lib64
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.6.1.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.6.1'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -g -L/usr/local/lib'

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

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

--Boundary-00=_btV4GGAS4hzbAXw
Content-Type: text/plain;
  name="FAIL CGI-Session-4.20 i686-linux-64int 2.6.22-1-k7"
Content-Transfer-Encoding: 7bit

This distribution has been tested as part of the cpan-testers
effort to test as many new uploads to CPAN as possible.  See
http://testers.cpan.org/

Please cc any replies to cpa...@pe... to keep other
test volunteers informed and to prevent any duplicate effort.

--
Dear Mark Stosberg,

This is a computer-generated test report for CGI-Session-4.20, created
automatically by CPAN::Reporter, version 0.4801, and sent to the CPAN
Testers mailing list.  If you have received this email directly, it is
because the person testing your distribution chose to send a copy to
 your CPAN email address; there may be a delay before the official
 report is received and processed by CPAN Testers.

Thank you for uploading your work to CPAN.  However, it appears that
there were some problems testing your distribution.

Sections of this report:

    * Tester comments
    * Prerequisites
    * Environment and other context
    * Test output

------------------------------
TESTER COMMENTS
------------------------------

Additional comments from tester:

[none provided]

------------------------------
PREREQUISITES
------------------------------

Prerequisite modules loaded:

requires:

    Module       Need  Have
    ------------ ----- --------
    Data::Dumper undef 2.121_14
    Digest::MD5  undef 2.36_01
    Scalar::Util undef 1.19
    Test::More   undef 0.70

------------------------------
ENVIRONMENT AND OTHER CONTEXT
------------------------------

Environment variables:

    LANG = en_US.utf8
    PATH =
 /usr/lib/ccache:/home/sand/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X
11:/usr/games:/usr/local/perl/bin:/usr/X11/bin:/sbin:/usr/sbin PERL5LIB
 =
    PERL5_CPANPLUS_IS_RUNNING = 1992
    PERL5_CPAN_IS_RUNNING = 1992
    SHELL = /usr/bin/zsh
    TERM = screen

Perl special variables (and OS-specific diagnostics, for MSWin32):

    Perl: $^X =
 /home/src/perl/repoperls/installed-perls/perl/pR263DW/perl-5.8.0@31805
/bin/perl UID:  $<  = 1005
    EUID: $>  = 1005
    GID:  $(  = 1005 1005
    EGID: $)  = 1005 1005

Perl module toolchain versions installed:

    Module              Have
    ------------------- -------
    CPAN                1.9102
    Cwd                 3.25
    ExtUtils::CBuilder  0.19
    ExtUtils::Command   1.13
    ExtUtils::Install   1.41_04
    ExtUtils::MakeMaker 6.36_01
    ExtUtils::Manifest  1.51_01
    ExtUtils::ParseXS   2.18
    File::Spec          3.25
    Module::Build       0.2808
    Module::Signature   0.55
    Test::Harness       2.64
    Test::More          0.70
    version             0.7203

------------------------------
TEST OUTPUT
------------------------------

Output from '/usr/bin/make test':

make[3]: Entering directory
 `/home/sand/.cpan/build/CGI-Session-4.20-rsBCo0' PERL_DL_NONLAZY=1
 /home/src/perl/repoperls/installed-perls/perl/pR263DW/perl-5.8.0@31805
/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib',
 'blib/arch')" t/*.t t/api3_db_file..................ok
t/api3_db_file_freezethaw.......ok
t/api3_db_file_storable.........ok
t/api3_db_file_storable_incr....ok
t/api3_file.....................ok
t/api3_file_freezethaw..........ok
t/api3_file_freezethaw_incr.....ok
t/api3_file_storable............ok
t/api3_file_storable_incr.......ok
t/api3_incr.....................ok
t/api3_obj_store................#Using FreezeThaw as object serializer
ok
t/api3_obj_store_db_file........ok
t/bug21952......................ok
t/cgi_simple....................ok
t/complex_ds....................ok
t/driver_dbi....................ok
t/expire........................ok
t/find..........................ok
t/flush.........................ok
t/g4............................ok
t/g4_dbfile.....................ok
t/g4_dbfile_freezethaw..........ok
t/g4_dbfile_json................# JSON::Syck
	(in cleanup) Dumping circular structures is not supported with
 JSON::Syck at
 /home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Se
rialize/json.pm line 18.

#   Failed test 'Previously stored object loaded successfully'
#   at
 /home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Te
st/Default.pm line 362.

#   Failed test at
 /home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Te
st/Default.pm line 362. Use of uninitialized value in string eq at
	/home/sand/.cpan/build/CGI-Session-4.20-rsBCo0/blib/lib/CGI/Session/Te
st/Default.pm line 325 (#1) (W uninitialized) An undefined value was
 used as if it were already defined.  It was interpreted as a "" or a
 0, but maybe it was a mistake. To suppress this warning assign a
 defined value to your variables.

    To help you figure out what was undefined, perl will try to tell
 you the name of the variable (if any) that was undefined. In some
 cases it cannot do this, so it also tells you what operation you used
 the undefined value in.  Note, however, that perl optimizes your
 program and the operation displayed in the warning may not necessarily
 appear literally in your program.  For example, "that $foo" is usually
 optimized into "that " . $foo, and the warning will refer to the
 concatenation (.) operator, even though there is no . in your program.

Can't call method "can" on an undefined value at
 /home/src/perl/repoperls/installed-perls/perl/pR263DW/perl-5.8.0@31805
/lib/5.10.0/overload.pm line 52. # Looks like you planned 101 tests but
 only ran 91.
# Looks like you failed 2 tests of 91 run.
# Looks l

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

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

Re: [Cgi-session-user] [rt.cpan.org #25325] t/g4_dbfile_json.t still failing with YAML-Syck-0.94

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

On Tuesday 31 July 2007 00:44, off...@gm... via RT wrote:
>        Queue: CGI-Session
>  Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=25325 >
>
> Hi,
> I wanted to report that t/g4_dbfile_json.t is still failing with
> YAML::Syck version 0.94.
>
> Also, I was wondering, can I ignore these testing failures and do a
> 'force install'?

That's certainly safe, as long as you don't use the YAML::Syck driver. 

I'm ready to remove the YAML and Syck drivers from the distribution...no one 
else has stepped up to apply patches for this in the core distribution, and 
it's creating extra maintenance work for the maintainers.

I'll plan to remove them from the next release. If anyone wants to start 
preparing a release of them in a separate distribution...that's great, and I 
can see making sure you can make an "official" release in the same name 
space. 

Otherwise, patches welcome.

   Mark

[Cgi-session-user] Weird correlation between CGI and CGI::Session when uploading files

[<ste...@gm...>]

Hi *,
I've just found a quite curious behaviour when using standard Perl-CGI
module and CGI::Session in an upload script. Maybe somebody can explain that
to me? Or is it a bug somewhere?

*Description*: I use the uploadInfo method of the
CGI module for getting the content type of an uploaded file. If I first
create the CGI object and afterwards the new CGI::Session object, everything
works fine as intended.

*<snippet>*
use CGI qw/:standard/;
use CGI::Carp qw/fatalsToBrowser/;
use CGI::Session;

# this is the place to focus on ;)
my $cgi = new CGI;  # create CGI instance
                               # create CGI::Session instance
my $CGISession = new CGI::Session(undef, undef,
{Directory=>'./_tmp__SESSIONS', UMask=>0664}) or die CGI::Session->errstr;

my $uploadedFile = $cgi->param('uploadedFile');
my $ContentType = $cgi->uploadInfo($uploadedFile)->{'Content-Type'};  # <=
here it is working...
print "the determined content-type is: ".$ContentType."<br />";
*</snippet>*

*But:* When switching the instantiation lines for CGI and CGI::Session, the
uploadInfo method suddenly returns an error:
...
# this breaks the uploadInfo() method (it returns undef instead of a hash
reference)
my $CGISession = new CGI::Session(undef, undef,
{Directory=>'./_tmp__SESSIONS', UMask=>0664}) or die CGI::Session->errstr;
my $cgi = new CGI;  # create CGI instance
                               # create CGI::Session instance
...
> *upload.pl: Can't use an undefined value as a HASH reference at ..*. (=>
the line with uploadInfo)

Does anybody know why that happens? I had
some restless hours until I found the problem (by chance!)...
While writing this down, I could
imagine that maybe the import of :standard CGI
methods into local namespace has something to do with it?!

Best regards so far, and have a nice weekend.
Stefan.

[Cgi-session-user] Weird correlation between CGI.pm and CGI::Session when uploading files

[<ste...@gm...>]

Hi *,
I've
just found a quite curious behaviour when using standard CGI module
and CGI::Session in an upload script. Maybe somebody can explain that
to me?
Or is it a bug anywhere?

*Description*: I use the uploadInfo method of the
CGI module for getting the content type of an uploaded file. If I first
create the CGI object and afterwards the new CGI::Session object, everything
works fine as intended.

*<snippet>*
use CGI qw/:standard/;
use CGI::Carp qw/fatalsToBrowser/;
use CGI::Session;

# this is the place to focus on ;)
my $cgi = new CGI;  # create CGI instance
                               # create CGI::Session instance
my $CGISession = new CGI::Session(undef, undef,
{Directory=>'./_tmp__SESSIONS', UMask=>0664}) or die CGI::Session->errstr;

my $uploadedFile = $cgi->param('uploadedFile');
my $ContentType = $cgi->uploadInfo($uploadedFile)->{'Content-Type'};  # <=
here it is working...
print "the determined content-type is: ".$ContentType."<br />";
*</snippet>*

*But:* When switching the instantiation lines for CGI and CGI::Session, the
uploadInfo method suddenly returns an error:
...
# this breaks the uploadInfo() method (it returns undef instead of a hash
reference)
my $CGISession = new CGI::Session(undef, undef,
{Directory=>'./_tmp__SESSIONS', UMask=>0664}) or die CGI::Session->errstr;
my $cgi = new CGI;  # create CGI instance
                               # create CGI::Session instance
...
> *upload.pl: Can't use an undefined value as a HASH reference at ..*. (=>
the line with uploadInfo)

Does anybody know why that happens? I had
some restless hours until I found the problem (by chance!)...
While writing this down, I could
imagine that maybe the import of :standard CGI
methods into local namespace has something to do with it?!

Best regards so far, and have a nice weekend.
Stefan.

Re: [Cgi-session-user] Regarding session expiry

[Tom P. <pa...@ph...>]

Note that I am not using the most current CGI::Session (using v4.14),
but I may have an idea about what is going on.

I tried duplicating Jahangir Mohammed's sample code on my web server,
and noticed that the load method seemed to be returning an unexpired
but empty session after the session expired.  I.e., got an unexpired
empty session the first run through, then got a real session if reloaded
before the expiry, but after waiting til the expiration clearly passed, 
load returned an unexpired but empty session.

Following Mark Stosberg's request for a Test::More style script, I
adapted my code and was surprised to find it passed everything without
problem.

I think the "issue" is that when CGI::Session header method creates its
cookie, it sets an expiration time on the cookie based on the session
expiry.  Which means that when I reload the page after waiting
for the expiration period to pass, the cookie in my browser should have
also expired.  The load method doesn't get a session id from the cookie
(at least if my browser if behaving properly), and so does not connect
my http request with the expired session but creates a new empty
session.  The standalone test script did not use cookies,  and so did
not have this problem.  The web based script worked as expected
(acknowledged the session as expired) when the session id passed as
a GET parameter.  Similarly worked as expected when I baked my own
cookie without the expiry and rolled my own header (simply following the
formula in the header method portion of the POD) 

I am not sure if this constitutes a bug, but the example code in the POD
for testing for expired sessions with load (which is what my and
Jahangir Mohammed's code seemed to be based on), is somewhat erroneous
because it used the CGI::Session header method, which sets the expiry on
the cookie.

-- 
Tom Payerle
Dept of Physics                         pa...@ph...
University of Maryland                  (301) 405-6973
College Park, MD 20742-4111             Fax: (301) 314-9525

Re: [Cgi-session-user] Regarding session expiry

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

On Thursday 26 July 2007 17:41, Jahangir Mohammed wrote:
> Hi,
>
> Yes.I did call flush.

OK. Please create a small code sample that illustrates the issue, preferably 
using the Test::More test suite syntax. 

If the tests pass, there is some difference between the test case and your 
code. If the test fails, there is a potential bug or something unusual about 
your environment. 

In any case, if you create a little test and that doesn't help solve it, post 
the code and result and here and perhaps someone can help.

  Mark

Re: [Cgi-session-user] Help required

[Thomas M. P. <pa...@ph...>]

I tried running something based on the code you gave on my system,
CGI::Session::VERSION 4.14.  IT's somewhat late, and I have not really
used the load method before, but it seems that on the expiration of the
session, load is returning an empty but non-expired session.

I print to STDERR assorted info on the session right after the load.
After the initial call to the script, I get an unexpired but empty session,
with no access/creation time or expiration.

On subsequent calls within the expiry period, the session is not empty,
not expired, and the access/creation times are as expected.

After waiting the expiration time, I again get an empty but non-expired
session.  So it looks like there is something subtly wrong with the load
method, unless I am missing something.

I am not really sure why you are using load instead of new.  Normally, I just 
use the new method and let CGI::Session create new or load
existing sessions as it wants, using a field in the session to determine
whether user already authenticated.  This field(s) has the expiration set,
which allows me to require the user to re-login if inactive but without losing
all the session based info (i.e. only delete stuff which is considered sensitive
enough to need to relogin for).


On Thu, 26 Jul 2007, Jahangir Mohammed wrote:

> Hello  ,
>
> I have a weird problem.
>
> Problem : The session doesnt expire at all in my cgi script.
>
> Purpose : To expire the session and show the user login form
>              after the user is idle for 2 minutes.
>
> Details:
> I am using CGI::Session's 4.20 version.
>
> I am trying to use this module for authentication purposes.
> Once the user is authenticated,I write the following code :
> my $session = CGI::Session->load() or die CGI::Session->errstr;
> if ( $session->is_expired ) {
>       die "Your session expired. Please refresh your browser to re-start
> your session";
> }
> $CGISESSID = $session->id(); ***************This generates id
> successully**************
> $session->expire('+1m'); *********** Doesn't expire my session************
>
> The only problem I could think is that I have force installed this module.
> Can anyone let me know why are there so many problems in
> installation ?
> Kindly go through the log file attached.
>
> Thanks a lot,
> Jahangir.
>

Tom Payerle 
Dept of Physics				pa...@ph...
University of Maryland			(301) 405-6973
College Park, MD 20742-4111		Fax: (301) 314-9525

Re: [Cgi-session-user] Regarding session expiry

[Jahangir M. <md....@gm...>]

Hi,

Yes.I did call flush.

Thanks,
Jahangir.


On 7/26/07, Mark Stosberg <ma...@su...> wrote:
>
> On Thursday 26 July 2007 17:18, Jahangir Mohammed wrote:
> > Hello  ,
> >
> > I have a weird problem.
> >
> > Problem : The session doesnt expire at all in my cgi script.
> >
> > Purpose : To expire the session and show the user login form
> >                after the user is idle for 2 minutes.
> >
> > Details:
> > I am using CGI::Session's 4.20 version.
>
> Did you remember to call "$session->flush()" before your script exits?
>
> Mark
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>