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