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

Re: [Cgi-session-user] session data not being saved till flushed.

[James.Q.L <shi...@ya...>]

--- Cees Hek <ce...@gm...> wrote:

> On 2/12/06, James.Q.L <shi...@ya...> wrote:
> > I tried another example and it worked (logged is flushed)..
> > % perl -MCGI::Session -e '{my $s=CGI::Session->new();$s->param("logged",1)}'
> >
> > I am posting my code here and hopefully someone can spot why it doesn't flush in the login
> > subroutine.
> 
> Nothing in the code you posted suggests any problems.  So it must be
> somewhere else in the code.  Do you by chance pass the $self->session
> object to your template?  I believe that HTML::Template sometimes
> hangs on to the parameters that you send to it, and hence the Session
> object doesn't go out of scope (that is a wild guess btw)

I do have $session object passed to HTML::Template as mentioned on CGI::Session tutorial. without
editing that part, however, I tried my code again and session data is suddently all flushed
without calling flush(). 

> > another question along with the code: in the login sub, if user passes the authentication then
> > calls session method which will create new session and send cookie(since i have SEND_COOKIE
> on),
> > user will then be redirect to ./ . I am expecting a new cookie will be created when it is
> > redirecting user to ./ but i don't see any cookie in the response header.  therefor my script
> > can't recognize the user as a logged in one. what's wrong in the code?
> 
> Try it again without the 'domain' and 'path' options to the cookie.  I
> find that those two often keep cookies from being set correctly in the
> browser (actually, to be more acurate, they are set correctly in the
> browser, but the browser doesn't send them back on the next request). 
> You might also increase the expiry time while testing this.  Also,
> make sure that the cookie is actually being sent to the browser in the
> first place (using something like the livehttpheaders plugin for
> mozilla makes this really easy).

I found out why the cookie doesn't sent during redirect. You see, i was using header_props for
redirect which overrides the cookie header set in CPA::Session early on. that means header_props
can't be used with CPA::Session and SEND_COOKIE is on. maybe this should be mentioned in
CPA::Session doc? 

yes, I was using livehttpheader. now i find i need something to edit the cookie easily to test my
script. the firefox extention "Add & Edit Cookies" looks promising, going to give it a go.

> Cheers,
> 
> Cees


	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

Re: [Cgi-session-user] session data not being saved till flushed.

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

On 2/12/06, James.Q.L <shi...@ya...> wrote:
> I tried another example and it worked (logged is flushed)..
> % perl -MCGI::Session -e '{my $s=3DCGI::Session->new();$s->param("logged"=
,1)}'
>
> I am posting my code here and hopefully someone can spot why it doesn't f=
lush in the login
> subroutine.

Nothing in the code you posted suggests any problems.  So it must be
somewhere else in the code.  Do you by chance pass the $self->session
object to your template?  I believe that HTML::Template sometimes
hangs on to the parameters that you send to it, and hence the Session
object doesn't go out of scope (that is a wild guess btw)

You can use Devel::Peek to double check the reference count of your variabl=
es:

perl -MDevel::Peek=3DDump -e 'my $x=3D10; Dump $x; my $y=3D\$x; Dump $x; Du=
mp $y'

Look at the value of REFCNT and how it changes when we store a
reference to $x in $y.

Since you are using CGI::Application, you can probably just setup a
'teardown' or 'cgiapp_postrun'  method that looks at the REFCNT of the
session object.

### UNTESTED CODE ###
sub teardown {
  my $self =3D shift;
  my $session =3D $self->session;
  use Devel::Peek qw(Dump);
  print STDERR "Peeking at \$self->session\n----------\n";
  Dump ($session);
  print STDERR "----------\n";
}

Then check your error log and see the REFCNT value.  If it is more
than 2, then you have a problem somewhere in your code (there are
already at least 2 copies, since $self has a copy, and you just made a
fresh copy in $session).  Although this might indicate that you have a
problem, it doesn't give you any indication where the problem is in
your code...

> another question along with the code: in the login sub, if user passes th=
e authentication then
> calls session method which will create new session and send cookie(since =
i have SEND_COOKIE on),
> user will then be redirect to ./ . I am expecting a new cookie will be cr=
eated when it is
> redirecting user to ./ but i don't see any cookie in the response header.=
  therefor my script
> can't recognize the user as a logged in one. what's wrong in the code?

Try it again without the 'domain' and 'path' options to the cookie.  I
find that those two often keep cookies from being set correctly in the
browser (actually, to be more acurate, they are set correctly in the
browser, but the browser doesn't send them back on the next request).=20
You might also increase the expiry time while testing this.  Also,
make sure that the cookie is actually being sent to the browser in the
first place (using something like the livehttpheaders plugin for
mozilla makes this really easy).

Cheers,

Cees

Re: [Cgi-session-user] session data not being saved till flushed.

[James.Q.L <shi...@ya...>]

I tried another example and it worked (logged is flushed)..
% perl -MCGI::Session -e '{my $s=CGI::Session->new();$s->param("logged",1)}'

I am posting my code here and hopefully someone can spot why it doesn't flush in the login
subroutine. 

another question along with the code: in the login sub, if user passes the authentication then
calls session method which will create new session and send cookie(since i have SEND_COOKIE on),
user will then be redirect to ./ . I am expecting a new cookie will be created when it is
redirecting user to ./ but i don't see any cookie in the response header.  therefor my script
can't recognize the user as a logged in one. what's wrong in the code? 

### Base.pm
use base "CGI::Application";
sub cgiapp_init {
    my $self = shift;
    CGI::Session->name('S');
    $self->session_config(
          CGI_SESSION_OPTIONS => [ "driver:File", $self->query, {Directory=>'/tmp/cgisession'} ],
          DEFAULT_EXPIRY      => '+5m',
          COOKIE_PARAMS       => {
                                   -domain  => 'dev.example.com',
                                   -path    => '/',
                                 },
          SEND_COOKIE         => 1,
    );
    $self->dbh_config($self->config_param('sqlite.data_source'));
}

# Login.pm
use base 'Base.pm';
sub setup
{
    my $self = shift;
    $self->start_mode('show_form');
    $self->run_modes('show_form' => 'show_form',
                     'login'     => 'login',
                     'logout'    => 'logout',
                    );
    $self->tmpl_path('Login/');
}

sub show_form
{
    my $self  = shift;
    my %args  = @_;
    my $query = $self->query();
    my $tmpl  = $self->load_tmpl('login.tmpl');

    $tmpl->param(alert => $args{alert} || $query->param('alert'));
    return $tmpl->output();
}

sub login
{
    my $self  = shift;
    my $query = $self->query();
    my $username = $query->param('username');
    my $password = $query->param('password');

    return $self->show_form(alert =>
                            "User name and password are required fields.")
      unless defined $username and length $username and
             defined $password and length $password;

    # check username and password ,
    my $user_id = $self->check_auth($username, $password);

    # failure
    return $self->show_form(alert =>
                     "Invalid login. The number of failed login attemps is $tries")
      unless $user_id;

    # update session if passed.
    my $session = $self->session;
    $session->param('_logged_in',1);
    $session->param('username',$username);
#    $session->flush(); # won't write to disk unless comment out this line

    $self->redirect_home;
}
############


--- "James.Q.L" <shi...@ya...> wrote:

> HI,
> 
> I am using C::S 4.03 and the session data is not saved unless i call flush(). The doc claims
> otherwise, "Normally it will be called for you just before the program terminates, or session
> object goes out of scope, so you should never have to flush() on your own."
> 
> Originally, I was using it with CGI::Application::Plugin::Session and noticed this behaviour.
> then



	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

[Cgi-session-user] session data not being saved till flushed.

[James.Q.L <shi...@ya...>]

HI,

I am using C::S 4.03 and the session data is not saved unless i call flush(). The doc claims
otherwise, "Normally it will be called for you just before the program terminates, or session
object goes out of scope, so you should never have to flush() on your own."

Originally, I was using it with CGI::Application::Plugin::Session and noticed this behaviour. then
I run this little test:

% perl -MCGI::Session -e '$s=CGI::Session->new;$s->param("log",1)'
% cat /tmp/cgisess_2c7678a377472c64a250304007295874
$D = {_SESSION_ID => '2c7678a377472c64a250304007295874',_SESSION_ATIME => 1139717550,log =>
1,_SESSION_REMOTE_ADDR => '',_SESSION_CTIME => 1139717550}; 

% perl -MCGI::Session -e '$s=CGI::Session->new;$s->param("log",1);$s->flush()'
% cat /tmp/cgisess_1d74dd15ded333689551116eae1ec263
$D = {_SESSION_ID => '1d74dd15ded333689551116eae1ec263',_SESSION_ATIME => 1139717605,log =>
1,_SESSION_REMOTE_ADDR => '',_SESSION_CTIME => 1139717605};

looks like flush() call is necessary.

James.


	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

RE: [Cgi-session-user] Re: session not written to disk, worked before 4.x upgrade

[Cristi O. <cr...@wi...>]

Thank you Mark,

Everything works fine now.

CO 

-----Original Message-----
From: cgi...@li...
[mailto:cgi...@li...] On Behalf Of Mark
Stosberg
Sent: Wednesday, January 18, 2006 5:18 PM
To: Cristi Ocolisan
Cc: cgi...@li...
Subject: [Cgi-session-user] Re: session not written to disk, worked before
4.x upgrade

On Wed, Jan 18, 2006 at 05:07:16PM +0200, Cristi Ocolisan wrote:
> Hi all,
> 
> Again, my "fellow" admin from the server I host two of my clients' sites
has
> upgraded the version of perl to 5.8.7 and CGI::Session module to 4.03.
> 
> This leads to several problems regarding my websites. 
> 
> First was that the sessions refused to initialize, but this I solved.
> Now I have a nightmare because I have nothing written inside the session
> files.
> 
>  
> It is incredible, because it WORKED fine until the upgrade. 
> I revised several times my code and nothing seems to be wrong, but.
> Please tell me if there are incompatibilities between perl 5.8.7 and
> CGI::Session 4.03.

No. I think something changed with the 4.00 release which shouldn't
have. 

> Anyway my code is as follows: (maybe you can find my error)

I think there may be something we can change in CGI::Session to fix
this. In the meantime,  call 

$session->flush();

Before your script exits to insure the session is written to disk.

This is supposed to happen automatically, but apparently it works
differently with 4.x. 

	Mark


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Cgi-session-user mailing list
Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user

[Cgi-session-user] Re: session not written to disk, worked before 4.x upgrade

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

On Wed, Jan 18, 2006 at 05:07:16PM +0200, Cristi Ocolisan wrote:
> Hi all,
> 
> Again, my "fellow" admin from the server I host two of my clients' sites has
> upgraded the version of perl to 5.8.7 and CGI::Session module to 4.03.
> 
> This leads to several problems regarding my websites. 
> 
> First was that the sessions refused to initialize, but this I solved.
> Now I have a nightmare because I have nothing written inside the session
> files.
> 
>  
> It is incredible, because it WORKED fine until the upgrade. 
> I revised several times my code and nothing seems to be wrong, but.
> Please tell me if there are incompatibilities between perl 5.8.7 and
> CGI::Session 4.03.

No. I think something changed with the 4.00 release which shouldn't
have. 

> Anyway my code is as follows: (maybe you can find my error)

I think there may be something we can change in CGI::Session to fix
this. In the meantime,  call 

$session->flush();

Before your script exits to insure the session is written to disk.

This is supposed to happen automatically, but apparently it works
differently with 4.x. 

	Mark

[Cgi-session-user] perl 5.8.7 and cgi::session 4.03

[Cristi O. <cr...@wi...>]

Hi all,

 

Again, my "fellow" admin from the server I host two of my clients' sites has
upgraded the version of perl to 5.8.7 and CGI::Session module to 4.03.

 

This leads to several problems regarding my websites. 

 

First was that the sessions refused to initialize, but this I solved.

Now I have a nightmare because I have nothing written inside the session
files.

 

It is incredible, because it WORKED fine until the upgrade. 

I revised several times my code and nothing seems to be wrong, but.

Please tell me if there are incompatibilities between perl 5.8.7 and
CGI::Session 4.03.

 

Anyway my code is as follows: (maybe you can find my error)

============================================================================
=======

#!/usr/bin/perl

use CGI;

my $q = new CGI;

 

use setup; 

 

use CGI::Session;

my $sid = $q->cookie('CGISESSID') || undef;

$session = new CGI::Session(undef, $sid,
{Directory=>$setup::director_sesiuni});

$sid = $session->id();

$utilizator = $session->param("utilizator");

$id_utilizator = $session->param("utilizator_id");

$tip_utilizator = $session->param("utilizator_tip");

$session->expire('+30m');

 

if ($utilizator ne ''){

print $q->header(-expires=>'1s');

}

 

if ($utilizator eq ''){

$cookie = $q->cookie(-name=>$session->name, -value=>$session->id,
-expires=>"+6h");

print $q->header( -cookie=>$cookie, -expires=>'1s' );

}

 

 

 

I (try to) write into the session file using this code:

 

#!/usr/bin/perl

use CGI;

my $q = new CGI;

 

use setup;

 

my $pag = $q->param('pag');

use CGI::Session;

my $sid = $q->cookie('CGISESSID') || undef;

my $session = new CGI::Session(undef, $sid,
{Directory=>$setup::director_sesiuni});

$sid = $session->id();

$cookie = $q->cookie(-name=>$session->name, -value=>$session->id,
-expires=>"+1d");

print $q->header( -cookie=>$cookie, -expires=>'1s' );

 

my $adresa = $setup::cale;

use Digest::MD5 qw(md5_hex);

use DBI;

my $dbh =
DBI->connect("dbi:mysql:database=$setup::database",$setup::username,$setup::
password,{RaiseError=>1});

 

===== snip ======

 

if ($gigi == 1){

    my $sth1 = $dbh->prepare("SELECT

                        id,

                        nume,

                        confirmat,

                        tip_user

                      FROM

                        utilizator

                      WHERE

                        (utilizator.username = ?) AND

                        (utilizator.parola = ?)");

    $sth1->execute($user,$passcrypt);

    while (my @row1 = $sth1->fetchrow_array()){

        if ($row1[2] == 1){

                $id_utilizator = $row1[0];

                $gigi = 1;            

                $session->param("utilizator", $row1[1]);

                $session->param("utilizator_id", $row1[0]);

                $session->param("utilizator_tip", $row1[3]);                

        }else{

            $gigi = 2;            

        }

    }

}

 

===============================================   

 

Thanks in advance for any tip.

Cristi Ocolisan

Re: [Cgi-session-user] V 4.03: Problem with load(), delete() and flush()

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

Thanks for the report Ron.

Some comments below. 

> my($id);
> my($session);
> 
> {
> 	$session	= CGI::Session -> new();
> 	$id			= $session -> id();
> 
> 	print "Inner scope. New session: $session. id: $id. \n";
> }
> 
> print "Original scope. id: $id. \n";
> 
> $session = CGI::Session -> load($id);
> 
> print "Original scope. Old session: $session. id: ", $session -> id(), ". \n";
> 
> if ($session -> is_empty() )
> {
> 	print "Original scope. Empty. \n";
> 
> 	$session -> delete();
> }

Just to be clear here, there is only one "$session" here in one scope, the
global scope. Therefore, it probably never goes out of scope, requiring
an explicit flush.

While using "{" and "}" does create a smaller scope, variables don't
exist solely within that scope unless you create them there with "my".

	Mark

[Cgi-session-user] V 4.03: Problem with load(), delete() and flush()

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

Hi Folks

It seems to me that there is a problem here. Code is at the end.

Line numbers refer to Session.pm.

Flow of control in the code:

o I create a session, defaulting to type file

o I capture the id

o I call load($id) in a new scope

o load($id) sets up:
=09- $$self{_DATA}{_SESSION_ID} as undef @ line 579
=09- $$self{_CLAIMED_ID'} as $id @ line 603

o I call $session -> id() which returns undef:
=09- This may be deliberate design decision, but...
=09- This is the first indication of a problem

o I call delete() which is loitering with intent @ line 279

o The program exits, which causes DESTROY() @ line 67 to be called

o This causes flush() @ line 179 to be called

o But look at line 182:
    return unless $self->id;            # <-- empty session
Since id() returns undef I can never delete the session via line 194:
        defined($driver->remove($self->id)) or

-----><8-----
#!/usr/bin/perl
#
# Name:
#=09test-flush.pl.
#
# Note:
#=09\t =3D 4 spaces || die.

use strict;
use warnings;

use CGI::Session;

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

my($dir_name) =3D 'c:/temp';

chdir($dir_name) || die "Can't chdir($dir_name): $!";

my($id);
my($session);

{
=09$session=09=3D CGI::Session -> new();
=09$id=09=09=09=3D $session -> id();

=09print "Inner scope. New session: $session. id: $id. \n";
}

print "Original scope. id: $id. \n";

$session =3D CGI::Session -> load($id);

print "Original scope. Old session: $session. id: ", $session -> id(), ".=
 \n";

if ($session -> is_empty() )
{
=09print "Original scope. Empty. \n";

=09$session -> delete();
}
-----><8-----
-- 
Cheers
Ron Savage, ro...@sa... on 12/01/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

RE: [Cgi-session-user] Failing DB_File tests

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

Sorry guys, I think I accidentally added those *.db and *.id files to the
distribution, they shouldn't have been there.

I'll take care of it.

> -----Original Message-----
> From: cgi...@li... 
> [mailto:cgi...@li...] On 
> Behalf Of Mark Stosberg
> Sent: Friday, December 16, 2005 9:58 PM
> To: David Steinbrunner
> Cc: List - CGI-Session
> Subject: Re: [Cgi-session-user] Failing DB_File tests
> Importance: High
> 
> 
> On Fri, Dec 16, 2005 at 08:42:29PM -0500, David Steinbrunner wrote:
> > 
> > > I had the same problem in FreeBSD. The MANIFEST.SKIP in 
> svn discludes
> > > these files so the next release should install cleanly.
> > 
> > So no need to create a bug report via CPAN's RT?
> 
> That's right. Matt was one step ahead of you.
> 
>     Mark
> 
> -- 
> http://mark.stosberg.com/ 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep 
> through log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  
> DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
> 
> 

Re: [Cgi-session-user] Failing DB_File tests

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

On Fri, Dec 16, 2005 at 08:42:29PM -0500, David Steinbrunner wrote:
> 
> > I had the same problem in FreeBSD. The MANIFEST.SKIP in svn discludes
> > these files so the next release should install cleanly.
> 
> So no need to create a bug report via CPAN's RT?

That's right. Matt was one step ahead of you.

    Mark

-- 
http://mark.stosberg.com/ 

Re: [Cgi-session-user] Failing DB_File tests

[David S. <ca...@po...>]

Matt LeBlanc wrote:

> Ah, this is due to a cgisess.db being included in the t directory. Try
> the following from the cpan shell:
> 
> cpan> get CGI::Session
> cpan> look CGI::Session
> # rm -f t/cgisess*
> # exit
> cpan> install CGI::Session

Removing the cgisess.db and cgisess.id files did allow for the test to pass
for me, at least on Mac OS X.

> I had the same problem in FreeBSD. The MANIFEST.SKIP in svn discludes
> these files so the next release should install cleanly.

So no need to create a bug report via CPAN's RT?

Thanks,

--
David Steinbrunner

Re: [Cgi-session-user] Failing DB_File tests

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

On Fri, 16 Dec 2005 07:48:49 -0500, David Steinbrunner wrote:

Hi David

>> Is DB_File installed? Try:
>> shell>perl -MDB_File -e "print qq|$DB_File::VERSION\n|"
>> I get:
>> 1.810
> That is what I am getting on both Mac OS X and OpenBSD.

In that case I've run out of ideas.
-- 
Cheers
Ron Savage, ro...@sa... on 17/12/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] Failing DB_File tests

[David S. <ca...@po...>]

Ron Savage wrote:
 
> Is DB_File installed? Try:
> 
> shell>perl -MDB_File -e "print qq|$DB_File::VERSION\n|"
> 
> I get:
> 1.810

That is what I am getting on both Mac OS X and OpenBSD.

--
David Steinbrunner

Re: [Cgi-session-user] Failing DB_File tests

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

On Thu, 15 Dec 2005 17:04:08 -0500, David Steinbrunner wrote:

Hi David

>  On both platforms the test involving the DB_File fail while all
> other test pass.

Is DB_File installed? Try:

shell>perl -MDB_File -e "print qq|$DB_File::VERSION\n|"

I get:
1.810
-- 
Cheers
Ron Savage, ro...@sa... on 16/12/2005
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

[Cgi-session-user] Failing DB_File tests

[David S. <ca...@po...>]

Hello,

I am currently using CGI::Session on Mac OS X 10.4 and OpenBSD 3.8.  On both
platforms the test involving the DB_File fail while all other test pass.

Here is the test output I get on Mac OS X 10.4 for the failing tests:

t/api3_db_file..................NOK 10#     Failed test (t/api3_db_file.t at
line 46)
Can't call method "id" on an undefined value at t/api3_db_file.t line 48.
# Looks like you planned 14 tests but only ran 10.
# Looks like your test died just after 10.
t/api3_db_file..................dubious
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 10-14
        Failed 5/14 tests, 64.29% okay

t/api3_db_file_storable.........NOK 10#     Failed test
(t/api3_db_file_storable.t at line 47)
Can't call method "id" on an undefined value at t/api3_db_file_storable.t
line 48.
# Looks like you planned 14 tests but only ran 10.
# Looks like your test died just after 10.
t/api3_db_file_storable.........dubious
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 10-14
        Failed 5/14 tests, 64.29% okay

t/api3_db_file_storable_incr....NOK 11#     Failed test
(t/api3_db_file_storable_incr.t at line 51)
Can't call method "id" on an undefined value at
t/api3_db_file_storable_incr.t line 52.
# Looks like you planned 15 tests but only ran 11.
# Looks like your test died just after 11.
t/api3_db_file_storable_incr....dubious
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 11-15
        Failed 5/15 tests, 66.67% okay

t/api3_obj_store_db_file........Can't call method "id" on an undefined value
at t/api3_obj_store_db_file.t line
        55 (#1)
    (F) You used the syntax of a method call, but the slot filled by the
    object reference or package name contains an undefined value.  Something
    like this will reproduce the error:
    
        $BADREF = undef;
        process $BADREF 1,2,3;
        $BADREF->process(1,2,3);
    
Uncaught exception from user code:
        Can't call method "id" on an undefined value at
t/api3_obj_store_db_file.t line 55.
 at t/api3_obj_store_db_file.t line 55
t/api3_obj_store_db_file........dubious
        Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 5-8
        Failed 4/8 tests, 50.00% okay

I would like to be able to install CGI::Session via the CPAN shell without
using force and hence would like to get to the bottom of these test
failures.

Does anyone have any ideas why this might be occurring or suggestions on
things to look into?

Thanks,

--
David Steinbrunner

Re: [Cgi-session-user] problem with CGI::Session and mod_perl - resolved

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

On 12/6/05, Senthil Nathan <rs...@gm...> wrote:
> Hi Mark / Cees,
>
> I just resolved the problem. It's a bug in my code which created that
> problem.
>
> So, REALLY REALLY SORRY for the inconvenience.

These mailing lists are for helping people with problems, so there is
no reason to feel sorry about asking a question.

> But I have some issues with mod_perl, for which this is not the right pla=
ce.
> Let me know if I can post you.

You really should consider asking specific mod_perl questions on the
mod_perl mailing list.  There are thousands of users on that list and
you are much more likely to get an answer to your question there.=20
Also, the docs at http://perl.apache.org/ have a lot of info that
might help you.  If you are porting your CGI applications to mod_perl
you should really have a look at these pages first:

http://search.cpan.org/~gozer/mod_perl-1.29/cgi_to_mod_perl.pod
http://search.cpan.org/~gozer/mod_perl-1.29/mod_perl_traps.pod

Cheers,

Cees

Re: [Cgi-session-user] problem with CGI::Session and mod_perl - resolved

[Senthil N. <rs...@gm...>]

Hi Mark / Cees,

I just resolved the problem. It's a bug in my code which created that
problem.

So, REALLY REALLY SORRY for the inconvenience.

But I have some issues with mod_perl, for which this is not the right place=
.
Let me know if I can post you.

Thanks.
Senthil

On 12/6/05, Cees Hek <ce...@gm...> wrote:
>
> On 12/6/05, Senthil Nathan <rs...@gm...> wrote:
> > I see that the session is created and the session_id is sent as a
> cookie.
> > But when I store a value in the session with a key and try to load
> another
> > page and the same session is loaded but the data is lost. The same
> > application worked well on cgi/perl. But with mod_perl i see the sessio=
n
> > data is lost.
>
> This usually means that your session object is not going out of scope.
> The session object doesn't write out it's changes to the data store
> until the session object is destroyed.  In mod_perl, since the process
> is persistent across multiple requests, it is possible to create a
> global variable that never goes out of scope, and hence your session
> data is never written out to the store.
>
> You can either put an explicit $session->flush (or $session =3D undef;)
> at the end of your code somewhere, or you can try to figure out why
> your session object is not going out of scope.
>
> Cheers,
>
> Cees
>

Re: [Cgi-session-user] problem with CGI::Session and mod_perl

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

On 12/6/05, Senthil Nathan <rs...@gm...> wrote:
> I see that the session is created and the session_id is sent as a cookie.
> But when I store a value in the session with a key and try to load anothe=
r
> page and the same session is loaded but the data is lost. The same
> application worked well on cgi/perl. But with mod_perl i see the session
> data is lost.

This usually means that your session object is not going out of scope.
 The session object doesn't write out it's changes to the data store
until the session object is destroyed.  In mod_perl, since the process
is persistent across multiple requests, it is possible to create a
global variable that never goes out of scope, and hence your session
data is never written out to the store.

You can either put an explicit $session->flush (or $session =3D undef;)
at the end of your code somewhere, or you can try to figure out why
your session object is not going out of scope.

Cheers,

Cees

Re: [Cgi-session-user] problem with CGI::Session and mod_perl

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

On Tue, Dec 06, 2005 at 02:00:42PM +0530, Senthil Nathan wrote:
> Hi All,
> 
> I used CGI::Session in my application and stored data in the server and
> retrieved it properly.
> 
> But later I moved to mod_perl for performance improvement and faced some
> problems.
> 
> I see that the session is created and the session_id is sent as a cookie.
> But when I store a value in the session with a key and try to load another
> page and the same session is loaded but the data is lost. The same
> application worked well on cgi/perl. But with mod_perl i see the session
> data is lost.


Thanks for the feedback. Please file a bug report for this in RT:

http://rt.cpan.org/NoAuth/Bugs.html?Dist=CGI-Session

Include as much detail as possible, including versions involved, and
steps to reproduce. ( It could be be pseudo-code if a working reduced case
isn't practical.)

> Let me is there any problem is using CGI::Session with mod_perl.

It sounds like you are letting /us/ know. 

I'm using CGI::Session 3.95 with mod_perl, but I haven't tried yet with
the 4.x branch.

Has anyone else? 

    Mark

[Cgi-session-user] problem with CGI::Session and mod_perl

[Senthil N. <rs...@gm...>]

Hi All,

I used CGI::Session in my application and stored data in the server and
retrieved it properly.

But later I moved to mod_perl for performance improvement and faced some
problems.

I see that the session is created and the session_id is sent as a cookie.
But when I store a value in the session with a key and try to load another
page and the same session is loaded but the data is lost. The same
application worked well on cgi/perl. But with mod_perl i see the session
data is lost.

Let me is there any problem is using CGI::Session with mod_perl.

Thanks
Senthil Nathan R

[Cgi-session-user] Fwd: several new CGI::Session updates to review

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

Matt LeBlanc  has contributed several updates to the CGI::Session
repository lately. We're happy to have him as our newest committer (that
I'm aware of...). 

The details of his changes are below. It seems to me there has probably
been enouch activity to merit a new release soon, even if it's a
developer release to collect more feedback.

    Mark

----- Forwarded message from Matt LeBlanc <mle...@cp...> -----

Date: Sun, 04 Dec 2005 04:56:04 -0600
From: Matt LeBlanc <mle...@cp...>
To: Mark Stosberg <ma...@su...>
Subject: Commits

Mark,

I've made 11 commits to CGI::Session's subversion server so you may want 
to check them out. Among the changes are:

* Fixed the Data::Dumper options to serialize correctly in 
CGI::Session::Serialize::default
* CGI::Session::Serialize::default handles overloaded objects correctly
* CGI::Session::Driver::file now respects $CGI::Session::File::FileName 
to be consistent with 3.9x
* CGI::Session::Driver::file's retrieve now locks the file in shared mode
* CGI::Session::Driver::file has localized filehandles for retrieve and 
store to avoid problems in persistent environments
* g4_mysql_freezethaw.t and g4_mysql_storable.t have been updated to 
respect environmental variables the same way as g4_mysql.t

Please check out the updates.

Thanks,
Matt LeBlanc

[Cgi-session-user] puzzled over two flavors of DB drivers

[<ms...@so...>]

I have a question on CGI::Session::MySQL vs. CGI::Session::Driver::mysql 
(which derives from CGI::Session::Driver::DBI).
I attempted to use a CGI::Session (version 3.95) with this code... 

use CGI::Session;
CGI::Session->new(
	"driver:MySQL", $cgi,
	{TableName  => $TBL,
	 DataSource => $DSN,
	 User       => $USER,
	 Password   => $PWD }
); 

but found that the code balked when it did not find a default-named table 
"sessions". That is, it was ignoring my TableName spec above. And this was 
because it was using the older CGI::Session::MySQL rather than the DBI 
approach. I thought this worked for me many months ago when I first looked 
at it, but perhaps I am imagining it :-) So what is the proper incantation 
for the above code to work? 

Re: [Cgi-session-user] database vs. file storage

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

On Wed, Nov 30, 2005 at 03:12:36PM +0200, Aton wrote:
> hello, all.
> i've read the POD on CPAN but it's still unclear to me what is the major 
> difference in the way i store the sessions. is database storage faster 
> then file or is it safer, why should one preffer db to files?

I prefer database storage. 

The rest of my application data is already in there. A database can have 
better security, because it has its own permission and authentication
system, while file-based sessions often end up owned by "nobody", which
other users on a shared system can access.

I'm not so concerned about "faster", since databse storage is "fast
enough". 

I think the only reason /not/ to use database storage is because the
database isn't be used for anything else. In that case, I would consider
file storage for simplicity.

    Mark

-- 
http://mark.stosberg.com/ 

[Cgi-session-user] database vs. file storage

[Aton <me...@ya...>]

hello, all.
i've read the POD on CPAN but it's still unclear to me what is the major 
difference in the way i store the sessions. is database storage faster 
then file or is it safer, why should one preffer db to files?

		
___________________________________________________________ 
Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/