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

Re: [Cgi-session-user] Question

[Peter S. <pt...@ms...>]

> Date: Wed, 19 Nov 2008 12:49:57 -0500
> From: ma...@su...
> To: cgi...@li...
> Subject: Re: [Cgi-session-user] Question
> 
> >  if (scalar@row1 == "6")
> >  {        @entry1 = ("@required" . "@row1")
> >  };
> >  if (scalar@row2 == "6")
> >  {        @entry2 = ("@required" . "@row2")
> >  };
> >  if (scalar@row3 == "6")
> >  {        @entry3 = ("@required" . "@row3")
> >  };
> >  if (scalar@row4 == "6")
> >  {        @entry4 = ("@required" . "@row4")
> >  };
> >  if (scalar@row5 == "6")
> >  {        @entry5 = ("@required" . "@row5")
> >  };
> 
> I doubt this part is related.
>
 
Figured just wanted to provide a little more info.

> >  #session handling
> >  $session = new CGI::Session(undef, undef, {Directory=>'../tmp/http_sessions'}) or die CGI::Session->errstr;
> >  
> >  print $session->header();
> >  
> >  $session->save_param(["@entry1","@entry2","@entry3","@entry4","@entry5"]);
> 
> - What version are you using? Try the latest if you aren't using it.

DESCRIPTION  Session management in CGI  applications
    CPAN_USERID  SHERZODR (Sherzod Ruzmetov <she...@cp...>)
    CPAN_VERSION 4.36
    CPAN_FILE    M/MA/MARKSTOS/CGI-Session-4.36.tar.gz
    UPLOAD_DATE  2008-09-13
    DSLIP_STATUS RdpOp (released,developer,perl,object-oriented,Standard-Perl)
    MANPAGE      CGI::Session - persistent session data in CGI applications
    INST_FILE    /usr/local/lib/perl5/site_perl/5.10.0/CGI/Session.pm
    INST_VERSION 4.36

> - Check $session->errstr after every call, and possibly CGI::Session->errstr, too.

I'm a newbie to perl so where should i put those calls?

> - Just before you get the error:  use Data::Dumper; warn Dumper ($session);
>   Is it empty, or something else? 
> - I would also recommend CGI::Session->new instead of "new CGI::Session" ... it shouldn't
>   make a difference but is considered a better practice.
> 

This is the new code.

#session handling
$session = CGI::Session->new (undef, undef, {Directory=>'../tmp/http_sessions'});

print $session->header();

$session->save_param(["@entry1","@entry2","@entry3","@entry4","@entry5"]);
warn Dumper ($session);

>     Mark

Thanks!


_________________________________________________________________
Get more done, have more fun, and stay more connected with Windows Mobile®. 
http://clk.atdmt.com/MRT/go/119642556/direct/01/

Re: [Cgi-session-user] Question

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

>  if (scalar@row1 == "6")
>  {        @entry1 = ("@required" . "@row1")
>  };
>  if (scalar@row2 == "6")
>  {        @entry2 = ("@required" . "@row2")
>  };
>  if (scalar@row3 == "6")
>  {        @entry3 = ("@required" . "@row3")
>  };
>  if (scalar@row4 == "6")
>  {        @entry4 = ("@required" . "@row4")
>  };
>  if (scalar@row5 == "6")
>  {        @entry5 = ("@required" . "@row5")
>  };

I doubt this part is related.

>  #session handling
>  $session = new CGI::Session(undef, undef, {Directory=>'../tmp/http_sessions'}) or die CGI::Session->errstr;
>  
>  print $session->header();
>  
>  $session->save_param(["@entry1","@entry2","@entry3","@entry4","@entry5"]);

- What version are you using? Try the latest if you aren't using it.
- Check $session->errstr after every call, and possibly CGI::Session->errstr, too.
- Just before you get the error:  use Data::Dumper; warn Dumper ($session);
  Is it empty, or something else? 
- I would also recommend CGI::Session->new instead of "new CGI::Session" ... it shouldn't
  make a difference but is considered a better practice.

    Mark

[Cgi-session-user] Question

[Peter S. <pt...@ms...>]

 
Hopefully a quick question,

I have added the following code to my cgi script:
 
=======================================================================================================

 if (scalar@row1 == "6")
 {        @entry1 = ("@required" . "@row1")
 };
 if (scalar@row2 == "6")
 {        @entry2 = ("@required" . "@row2")
 };
 if (scalar@row3 == "6")
 {        @entry3 = ("@required" . "@row3")
 };
 if (scalar@row4 == "6")
 {        @entry4 = ("@required" . "@row4")
 };
 if (scalar@row5 == "6")
 {        @entry5 = ("@required" . "@row5")
 };
 
 #session handling
 $session = new CGI::Session(undef, undef, {Directory=>'../tmp/http_sessions'}) or die CGI::Session->errstr;
 
 print $session->header();
 
 $session->save_param(["@entry1","@entry2","@entry3","@entry4","@entry5"]);
 
=======================================================================================================

 and once I attempt to run the script i receive this error in my http log:
 
 Can't call method "param" on unblessed reference at /usr/local/lib/perl5/site_perl/5.10.0/CGI/Session.pm line 360., referer: http://localhost
 
 
 Any and all help is much appreciated.
 
 Thank you,

_________________________________________________________________
Access your email online and on the go with Windows Live Hotmail.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access_112008

[Cgi-session-user] Session gets dropped when using a HTTP redirect within CGI::Application

[Axo <axo...@ax...>]

Hi, I´m having a bit of a problem with this issue, and is driving me crazy,
am I doing something wrong here?

If I set a couple of session vars, call flush (or not, its the same) and
redirect to another url, in the second run mode a new empty session is
created although
the cookie doesn't change, so I cant access any of my previous session vars.
This only happens the first time for a given client.
Its easier to understand looking at the code and the logfile (see below).

System details:
Perl, v5.8.7 built for i486-linux-gnu-thread-multi on Linux u15292264
2.6.23.16-20080211a #1 SMP
$CGI::Session::VERSION  = '4.38';
$CGI::Application::VERSION = '4.06';

Code to reproduce:

Application.pm file:

package TEST::Application;
use base 'CGI::Application';
use strict;
use CGI::Application::Plugin::Session;
use Data::Dumper;

open(STDERR, q{>>},'logfiletest');

sub cgiapp_init {
    my $self = shift;

    $self->session_config(
        CGI_SESSION_OPTIONS => [ "driver:File", $self->query,
{Directory=>'/var/tmp'} ],
        SEND_COOKIE => 1,
        COOKIE_PARAMS => {
            -expires => "+1h"
        },
        DEFAULT_EXPIRY => "1h"
    );
}

sub cgiapp_prerun {
    my $self = shift;
    my $q = $self->query;

    warn "Mode: ".Dumper($q->path_info)."\n";
}

sub setup {
    my $self = shift;

    $self->start_mode('index');
    $self->mode_param( path_info => -1 );

    $self->run_modes([qw/
        index
        ren
    /]);
}

#######################################################################################
####  Run Modes
#######################################################################################
sub index {
    my $self = shift;
    my $session = $self->session;

    $session->param('md5','123456');
    $session->param('logged_user', 'pepe');
    $session->flush();

    warn "index mode session=".$session->id;

    my $logged_user = $self->check_session;

    warn "doing redir...";
    $self->redir("/indextest.pl/ren");

    return "index mode session=".$session->id;
}

sub ren {
    my $self = shift;
    my $session = $self->session;

    my $logged_user = $self->check_session;

    warn "ren logged user=".$logged_user;

    return "ren mode session=".$session->id;
}

#######################################################################################
####  Utility functions
#######################################################################################
sub check_session {
    my $self = shift;
    return unless my $session = $self->session;
    warn "session id=".$session->id;
    warn "dataref=".Dumper($session->dataref());
    warn "cookie =CGISESSID".$self->query->cookie('CGISESSID');

    return unless $session->param('md5');
    return $session->param('logged_user') if $session->param('md5');
}

sub redir {
    my $self = shift;
    my $url = shift;
    $self->header_type('redirect');
    $self->header_props(-url=>$url);
    return "Redirecting to $url";
}

1;


indextest.pl File:

#!/usr/bin/perl -w

use strict;
use CGI::Carp qw(fatalsToBrowser);
use TEST::Application;

open(STDERR, '>>logfiletest');

my $app = new TEST::Application;

$app->run();




Resulting logfiletest:

[Fri Nov  7 14:09:04 2008] indextest.pl: Mode: $VAR1 = '';
[Fri Nov  7 14:09:04 2008] indextest.pl:
[Fri Nov  7 14:09:05 2008] indextest.pl: index mode
session=8931907b0822e3696087a3797ff79fe9 at TEST/Application.pm line 52.
[Fri Nov  7 14:09:05 2008] indextest.pl: session
id=8931907b0822e3696087a3797ff79fe9 at TEST/Application.pm line 79.
[Fri Nov  7 14:09:05 2008] indextest.pl: dataref=$VAR1 = {
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_ETIME' => 3600,
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_ID' =>
'8931907b0822e3696087a3797ff79fe9',
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_ATIME' =>
1226084945,
[Fri Nov  7 14:09:05 2008] indextest.pl:           'logged_user' => 'pepe',
[Fri Nov  7 14:09:05 2008] indextest.pl:           'md5' => '123456',
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_REMOTE_ADDR' =>
'190.18.144.128',
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_CTIME' =>
1226084945
[Fri Nov  7 14:09:05 2008] indextest.pl:         };
[Fri Nov  7 14:09:05 2008] indextest.pl: cookie
=CGISESSIDf5f4635a8899929d4649d53074d890c2 at TEST/Application.pm line 81.
[Fri Nov  7 14:09:05 2008] indextest.pl: doing redir... at
TEST/Application.pm line 56.
[Fri Nov  7 14:09:05 2008] indextest.pl: Mode: $VAR1 = '/ren';
[Fri Nov  7 14:09:05 2008] indextest.pl:
[Fri Nov  7 14:09:05 2008] indextest.pl: session
id=6f5b87b3c56709591d34e2e8920654fa at TEST/Application.pm line 79.
[Fri Nov  7 14:09:05 2008] indextest.pl: dataref=$VAR1 = {
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_ETIME' => 3600,
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_ID' =>
'6f5b87b3c56709591d34e2e8920654fa',
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_ATIME' =>
1226084945,
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_REMOTE_ADDR' =>
'190.18.144.128',
[Fri Nov  7 14:09:05 2008] indextest.pl:           '_SESSION_CTIME' =>
1226084945
[Fri Nov  7 14:09:05 2008] indextest.pl:         };
[Fri Nov  7 14:09:05 2008] indextest.pl: cookie
=CGISESSIDf5f4635a8899929d4649d53074d890c2 at TEST/Application.pm line 81.
[Fri Nov  7 14:09:05 2008] indextest.pl: Use of uninitialized value in
concatenation (.) or string at TEST/Application.pm line 68.
[Fri Nov  7 14:09:05 2008] indextest.pl: ren logged user= at
TEST/Application.pm line 68.


Steps to reproduce:
1- delete all sessions from /var/tmp
2- go to http://webserver/indextest.pl

In the logfile you can see that the session id changes after the redirect
even if the cookie its the same. Upon inspection of the session dir, 2
different files (sessions) where created.

[Cgi-session-user] Sorry: Re: [rt.cpan.org #34668] Documentation on 'delete()' is misleading

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

I thought I would explain how some messages about closing this ticket got
routed to the list.

I found an option an RT to notify additional addresses for activity in
the CGI::Session bug queue. It didn't say exactly *which* activity. I 
was hoping it was just announcements of new bugs being reported, but
apparently it was all traffic, which clearly doesn't work in the case
where a bug reporter is not subscribed to the list.

So, I consider that experiment a failure and have disabled that option now.

However, if any one would like to directly subscribe the bug queue traffic,
please let me know.  CGI::Session is your module, and it is your interest to
now about and patch the bugs.

I am a user who has volunteered to help with maintenance myself. However, I
only use a subset of the drivers and serializers, and am not personally
motivated to deal with every issue that comes up.

Currently, the bug queue is just about cleared out, so perhaps we will be
entering a period of stability and calmness with the project anyway.

A special thanks goes to Ron Savage, who has stepped up in this way, am I'm
very grateful for his help.

    Mark

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

[Cgi-session-user] CGI::Session 4.38 released

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

Thanks to Ron Savage and numerous bug reporters, CGI::Session 4.38 has now been
released.

The changes since the lats release are below:

* INTERNAL: Rename SimpleObjectClass to CGI::Session::Test::SimpleObjectClass 
            to avoid namespace ownership issue (Mark Stosberg). 
* INTERNAL: We now list CGI.pm 3.26 or greater as a dependency. You are still  
            welcome to use other query objects, but this version of CGI.pm
            fixes a bug in the strictness of HTTP expiration times, which
            Safari in particular is sensitive to. So, if you are using
            CGI.pm, you should upgrade to at least this version.  RT#34216,
            thanks to Astar, Michael Hampton, Ron Savage and Mark Stosberg. 
* INTERNAL: return explicit values in _set_status and _unset_status 
            (RT#39201, Mario Domgoergen, Mark Stosberg) 

* FIX: RT#37877: The storable serializer wasn't properly inheriting the 'errstr'
       method. This could have resulted an error like:
       "Can't locate errstr via package "CGI::Session::Serialize::storable"
       Thanks to Michael Greenish, Mark Stosberg.  
* FIX: RT#40405 reported a case where the default serializer would have a problem after the user
  	   set a parameter's value to undef, in certain circumstances.
	   A test file was kindly provided by cowomally[...]nullium.net.
	   The fix was spelled out by Matt LeBlanc
* FIX: RT#39679 pointed out a simplification in method remove() in CGI::Session::Driver::file.
  	   By calling _file() instead of duplicating code, we get the benefit of extra error checking.
  	   Thanx to Sergiy Borodych for noticing this
* FIX: Stop using the return value of delete() in t/find.t. This means that when the patch
  	   provided in RT#37752 is applied, t/find.t will not start failing

    http://search.cpan.org/~markstos/CGI-Session-4.38/

        Mark

[Cgi-session-user] RT 17299: No session data is saved unless $session->flush() is called

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

Hi Folks

I've just added a note to ticket 17299 on RT since I have encountered
this problem myself for the first time, and believe it was due to a
specific bug in my code.

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

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

[Cgi-session-user] Clients handle expiration commands in unexpected ways

[Neil R. <ne...@ie...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Hi,

I read the docs for both CGI::Session and CGI::Session::Tutorial,
Google'd around, searched this list, and asked in some IRC channels,
but despite some
suggestions for workarounds so far I'm still stumped as to the root
cause.  Since I don't see lots of people with the same problem, I
figure it's either a configuration error or I'm misunderstanding what
the docs mean.

During logout, client-side cookies aren't reacting the way I expect
them to.  Here's the various commands I've tried and their results
(obviously I only use one at a time):


# Expected: immediate expiration
# Actual: Sets to expire at end of session
#$session->expire("-1d");

# Expected: Expiration in 1 second
# Actual: Works, but if the user clicks anything before it expires
# than the timer gets restarted and the user can stay logged in
# indefinitely
#$session->expire("15s");

# Expected: Clear all cookie fields
# Actual: Doesn't seem to affect client-side cookies (at least not in
# a way that helps me)
#$session->clear();

# Expected: Delete cookie from server, possibly from client
# Actual: Deletes from server, leaves client alone (and then gets
# recreated)
#$session->delete();

# Expected: Deletes cookies from server and forces action to be taken
# immediately
# Actual: uncertain, seems to create a second cookie with no name and
# path of '/cgi-bin/' instead of '/'
#$session->delete(); $session->flush();


What am I missing?  Pointers to docs or previous threads I maybe
missed would be greatly appreciated.


Thanks,

- -Neil R.



- --
Supreme Lord High Commander and Keeper of the Holy Potato
PGP fingerprint: 0xE098F32E
- ----------
Press CTRL-ALT-DEL to edit...



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iEYEARECAAYFAkjnkZcACgkQejb4F+CY8y4eJACg0EZesenFMMGp6N3mhGnociae
RWMAn0wBTWclIdSjVRnNWuTQhQN2x4FJ
=i7Bo
-----END PGP SIGNATURE-----

[Cgi-session-user] CGI::Session 4.33 released

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

I've just sent CGI::Session 4.33 to CPAN. It includes the following changes
since 4.32, committed by Ron Savage with help from bug reporters. Thanks 
to all!

* FIX: Patch CGI::Session::Driver::mysql to replace 'REPLACE INTO ...' with
       'INSERT INTO ... ON DUPLICATE KEY UPDATE ...'. See RT#37069.
       Thanks to Steve Kirkup for the patch. I (Ron) installed MySQL V 5.0.51a for testing.
       Note: http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-45.html and similar docs
       list various MySQL errors fixed recently for the above new syntax. Also, the new version
       is now much more like the Postgres code, which is another reason it has been adopted.

* FIX: t/mysql.t used to test setting the global variable $CGI::Session::MySQL::TABLE_NAME.
       The test for this (in t/mysql.t) was introduced in V 4.00_09.
       However, since V 4.29_1, changes to CGI::Session::Driver's new() method mean
       this way of setting the session table's name no longer works, and so the variable
       $CGI::Session::MySQL::TABLE_NAME is now not used. Hence it has been removed.
       Code in CGI::Session::Driver::DBI used to set $class::TABLE_NAME for all database drivers.
       This code has also been removed. Moral: Don't use global variables.
       Call $session = CGI::Session -> new(..., ..., (TableName => 'new_name'}) or,
       after creating the object, call $session -> table_name('new_name').
       To retrieve the name, call $name = $session -> table_name().

###

    Mark

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

[Cgi-session-user] CGI::Session 4.30 released

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

With much work from Ron Savage and contributions from several others,
CGI::Session 4.30 has now been released to CPAN.  Here are the changes
since the last stable release. 

http://search.cpan.org/~markstos/CGI-Session-4.30/

    Mark

####

4.30 - Friday, April 25, 2008

    * FIX: Patch POD for CGI::Session in various places, to emphasize
even more that auto-flushing is unreliable, and that flush() should
always be called explicitly before the program exits. The changes are a
new section just after SYNOPSIS and DESCRIPTION, and the PODs for
flush(), and delete(). See RT#17299 and RT#34668
    * NEW: Add t/new_with_undef.t and t/load_with_undef.t to explicitly
demonstrate the effects of calling new() and load() with various types
of undefined or fake parameters. See RT#34668
    * FIX: Patch POD for new() and load() to clarify the result of
calling these with undef, or with an initialized CGI object with an
undefined or fake CGISESSID. See RT#34668. Specifically: You are
strongly advised to run the old-fashioned 'make test
TEST_FILES=t/new_with_undef.t TEST_VERBOSE=1' or the new-fangled 'prove
-v t/new_with_undef.t', for both new*.t and load*.t, and examine the
output
    * FIX: Patch POD in various tiny ways to improve the grammar

4.29_2 - Thursday, March 27, 2008

    * FIX: stop ExtUtils::MakeMaker trying to create Build.PL (Ron
Savage)
    * FIX: Disable trying to use utf8 in tests. (Ron Savage) Ref
RT#21981, RT#28516

4.29_1 - Saturday, March 15, 2008

    Special Thanks to Ron Savage who did the bulk of the work to put
this release together. 

    * FIX: Patch CGI::Session to fix RT#29138 (Patch by Barry Friedman)
    * NEW: Add a note to CGI::Session's POD referring to utf8 problems,
and include references to RT#21981 (Reported by erwan) and RT#28516
(Reported by jasoncrowther)
    * FIX: Patch CGI::Session::Driver::DBI.pm to fix RT#24601 (Patch by
latypoff)
    * FIX: Patch CGI::Session::Driver::DBI.pm to fix RT#24355 (Reported
by fenlisesi, patch by Ron Savage)
	* NEW: Add t/bug24285.t to ensure session data files are
created properly when the user specifies a directory other than /tmp
(Reported by William Pearson RT#24285, patch by Ron Savage)
    * FIX: Patch t/ip_matches.t and t/bug21592.t to remove test files
left in /tmp, to fix RT#29969 (Reported by ANDK, patch by Ron Savage)
    * FIX: Patch POD for CGI::Session::Driver::file to clarify how to
use the option to change the file name pattern used to created session
files (Report by appleaday RT#33635, patch by Ron Savage)
    * FIX: Patch CGI::Session::Driver::sqlite to add sub DESTROY to fix
RT#32932 (Patch by Alexander Batyrshin, corrected by Ron Savage)
    * FIX: Remove CGI::Session::Seralize::json and t/g4_dbfile_json.t
until such time as this code can be made to work reliably. Both
JSON::Syck and JSON::XS have been tried, and in both cases
t/g4_dbfile_json.t dies horribly (but differently). Patch POD for
CGI::Session to remove references to JSON. RT#25325 (Reported by bkw,
patch by Ron Savage)
    * NEW: Patch CGI::Session's POD and load() to allow the
session/cookie name default of CGISESSID to be overridden. (Patch by
Lee Carmichael RT#33437, reformatted by Ron Savage). Lee has also
patched t/name.t to test the new functionality
    * NEW: Split CGI::Session::Serialize::yaml out into its own distro.
Get it hot from CPAN!
    * NEW: Add Build.PL for Module::Build users. This also requires
adding PL_FILES => {} to Makefile.PL to beat ExtUtils::MakeMaker over
the head, otherwise it executes 'perl Build.PL Build'
    * NEW: Support specification of both the id column name and the
a_session column name in the sessions table, by extending the options
acceptable in CGI::Session->new(..,..,{here}). Allow:   {TableName =>
'session',  IdColName => 'my_id', DataColName => 'my_data'}. Default:
{TableName => 'sessions', IdColName => 'id',    DataColName =>
'a_session'}. Allow any 1, 2 or 3 of these options. Missing keys
default as specified. (Patch by Chris RT#2224. Implemented differently
by Ron Savage). Supported drivers: o MySQL (native to CGI::Session) o
ODBC (separate distro, CGI::Session::Driver::odbc V 1.01) o Oracle
(separate distro, CGI::Session::Driver::oracle V 1.01) o Postgres
(native) o SQLite (native)



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

Re: [Cgi-session-user] Cookies not set with RegisterFilter

[Tony v. d. H. <lis...@va...>]

On 21 Apr at 17:54 Mark Stosberg <ma...@su...> wrote in message
<480...@su...>

[snip]
>>>
> > Yes, I tried that. Am I right in thinking that $session->header should
> > return that content? This is weird, because it always seems to return an
> > empty string, both in the working and non-working versions. Which makes
> > me wonder how and where the cookie information gets added under
> > Registry.
>
> From the docs, it appears it would return the headers. What happens if you
> delete the cookie, does it re-appear in either case?
>
If I delete the cookie for the Registy version, it's recreated with the next
access.

No cookie is created for the RegistryFilter version.

The code is identical, except for the .htaccess file, which in one case
contains:

PerlModule Apache::DBI
PerlModule Apache::Filter
PerlInitHandler Apache::Reload
PerlHandler Apache::RegistryFilter
PerlHandler Apache::Dynagzip
PerlSetVar Filter On
AddHandler perl-script .pl
PerlSendHeader On
PerlSetupEnv On

And in the other:

PerlModule Apache::DBI
PerlModule Apache::Filter
PerlInitHandler Apache::Reload
PerlHandler Apache::Registry
AddHandler perl-script .pl
PerlSendHeader On
PerlSetupEnv On

The latter works; the former doesn't.

> Maybe something changed in your application so cookies are not being sent
> at all any more, and because of a URL difference, you happen to see an old
> cookie with Apache::Registry, and no cookie at all with the gzip'ing
> solution.

No, I've been there. The cookies are being correctly recreated with
Registry. I just don't understand how they're getting there. Certainly not
from print $session->header.
>
> I would say if $session->header() is always empty, the bug is somewhere in
> your application, and dig deeper to find out why those headers aren't
> being set.

Hmm, I'll pursue that; thanks again.

Cheers, Tony.

-- 
Tony van der Hoff        | mailto:to...@va...
Buckinghamshire, England

Re: [Cgi-session-user] Cookies not set with RegisterFilter

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

>> I assume you'll find that the cookies aren't being sent with
>> RegistryFilter. You could check with them to see if that's a bug or a
>> "known issue". 
> 
> No, the cookies aren't being sent. I'll try getting help from the
> RegistryFilter developers.
> 
>> You could also add debugging statements in your application
>> just before sending the headers, to confirm the headers that you think you
>> are sending.
>>
> Yes, I tried that. Am I right in thinking that $session->header should
> return that content? This is weird, because it always seems to return an
> empty string, both in the working and non-working versions. Which makes me
> wonder how and where the cookie information gets added under Registry.

 From the docs, it appears it would return the headers. What happens if 
you delete the cookie, does it re-appear in either case?

Maybe something changed in your application so cookies are not being 
sent at all any more, and because of a URL difference, you happen to see 
an old cookie with Apache::Registry, and no cookie at all with the 
gzip'ing solution.

I would say if $session->header() is always empty, the bug is somewhere 
in your application, and dig deeper to find out why those headers aren't 
being set.

    Mark

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

Re: [Cgi-session-user] Cookies not set with RegisterFilter

[Tony v. d. H. <lis...@va...>]

Thanks very much, Mark for your prompt and helpful response.

On 21 Apr at 14:26 Mark Stosberg <ma...@su...> wrote in message
<480...@su...>

> Tony van der Hoff wrote:
> > Hi,
>> 
> > I've been using Cgi::Session for quite a while, with no problems.
>> 
> > I recently decided to speed up my delivery over slow links by
> > compressing the data using Apache::Dynagzip. This entailed using
> > Apache::RegistryFilter in place of Apache::Registry, and enabling
> > Apache::Filter. Indeed, the output is now gzipped, and is delivered very
> > much faster.
>> 
> > The bummer is that the session cookies are not being set on the client;
> > I suspect they're not even being sent. Reverting back to
> > Apache::Register sets them correctly, but no gzip. Frankly, I'm baffled
> > as to where to look for this problem, so I'm trying here as a first
> > step. Google's not being my friend :(
>> 
> > Has anyone come across this before, or has anyone got any suggestions on
> > how to fix this, please?
[snip]

> I recommend reviewing the headers that are sent in both cases. You could
> use the LWP command line tool "GET" for this, or Firefox also has some
> nice extensions to help with this: The Web Developer Toolbar or the "Live
> HTTP Headers" extension. My preferred method now is the Web Developer
> Toolbar, as it is a general purpose swiss army knife for website
> development.
>
Indeed, I already use the Web Developer extension for my website
development, but hadn't realised that it can show the response headers. It
gets better all the time!

> I assume you'll find that the cookies aren't being sent with
> RegistryFilter. You could check with them to see if that's a bug or a
> "known issue". 

No, the cookies aren't being sent. I'll try getting help from the
RegistryFilter developers.

> You could also add debugging statements in your application
> just before sending the headers, to confirm the headers that you think you
> are sending.
>
Yes, I tried that. Am I right in thinking that $session->header should
return that content? This is weird, because it always seems to return an
empty string, both in the working and non-working versions. Which makes me
wonder how and where the cookie information gets added under Registry.

> Finally, consider an alternative gzip'ing solution to work around the
> issue. We use Apache::Registry and mod_gzip together, without special
> effort.
>
Unfortunately my hosting provider only supports Dynagzip, so my options
there are a bit limited.

Thanks again for your time.

Cheers, Tony
-- 
Tony van der Hoff        | mailto:to...@va...
Buckinghamshire, England

Re: [Cgi-session-user] Cookies not set with RegisterFilter

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

Tony van der Hoff wrote:
> Hi,
> 
> I've been using Cgi::Session for quite a while, with no problems.
> 
> I recently decided to speed up my delivery over slow links by compressing
> the data using Apache::Dynagzip. This entailed using Apache::RegistryFilter
> in place of Apache::Registry, and enabling Apache::Filter. Indeed, the
> output is now gzipped, and is delivered very much faster.
> 
> The bummer is that the session cookies are not being set on the client; I
> suspect they're not even being sent. Reverting back to Apache::Register sets
> them correctly, but no gzip. Frankly, I'm baffled as to where to look for
> this problem, so I'm trying here as a first step. Google's not being my
> friend :(
> 
> Has anyone come across this before, or has anyone got any suggestions on how
> to fix this, please?

Tony,

You've already done some good debugging by realizing that 
Apache::RegistryFilter is somehow related.

I recommend reviewing the headers that are sent in both cases. You could 
use the LWP command line tool "GET" for this, or Firefox also has some 
nice extensions to help with this: The Web Developer Toolbar or the 
"Live HTTP Headers" extension. My preferred method now is the Web 
Developer Toolbar, as it is a general purpose swiss army knife for 
website development.

I assume you'll find that the cookies aren't being sent with 
RegistryFilter. You could check with them to see if that's a bug or a 
"known issue". You could also add debugging statements in your 
application just before sending the headers, to confirm the headers that 
you think you are sending.

Finally, consider an alternative gzip'ing solution to work around the 
issue. We use Apache::Registry and mod_gzip together, without special 
effort.

     Mark


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

[Cgi-session-user] Cookies not set with RegisterFilter

[Tony v. d. H. <lis...@va...>]

Hi,

I've been using Cgi::Session for quite a while, with no problems.

I recently decided to speed up my delivery over slow links by compressing
the data using Apache::Dynagzip. This entailed using Apache::RegistryFilter
in place of Apache::Registry, and enabling Apache::Filter. Indeed, the
output is now gzipped, and is delivered very much faster.

The bummer is that the session cookies are not being set on the client; I
suspect they're not even being sent. Reverting back to Apache::Register sets
them correctly, but no gzip. Frankly, I'm baffled as to where to look for
this problem, so I'm trying here as a first step. Google's not being my
friend :(

Has anyone come across this before, or has anyone got any suggestions on how
to fix this, please?

Cheers,
-- 
Tony van der Hoff        | mailto:to...@va...
Buckinghamshire, England

Re: [Cgi-session-user] driver undefined during flush()

[Michael S. <ebs...@on...>]

Hi Ron

Am Donnerstag, den 17.04.2008, 17:13 +1000 schrieb Ron Savage:

> Hi Michael
> 
> > > For the to-be-released next version of CGI::Session, I've changed the
> > > docs a number of times, all emphasizing that explicit flushing is deemed
> > > to be mandatory until we get auto-flushing to work every single time.
> > for me not even an explicit flush will work, I've to do $dbh->commit
> > too whenever I write any data to the session as my database connection
> > is set up with 'AutoCommit => 0'.
> 
> Ahh. So the sessions are stored in the database!
> 
> I will add a note to the docs.
> 

fine, this took me quite some time to find out, as a newbie to the
Session module.  :)


> > I use CGI::Session 4.20 and would be happy, if it would not depend on
> > the huge CGI Module which I do not use anyway.
> 
> But using CGI.pm is optional!
> 

Shame on me, have missed this part in the tutorial.

> Just add:
> (1)
> use CGI::Simple;
> (2)
> sub cgiapp_get_query
> {
> 	my($self) = @_;
> 
> 	return CGI::Simple -> new();
> 
> } # End of cgiapp_get_query.
> 
> to your app, and CGI::Application will use CGI::Simple.
> 
> Simple!
> 

Thank you very much, works great and should speed up my applications.

cu,
Michael

Re: [Cgi-session-user] driver undefined during flush()

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

Hi Michael

> > For the to-be-released next version of CGI::Session, I've changed the
> > docs a number of times, all emphasizing that explicit flushing is deemed
> > to be mandatory until we get auto-flushing to work every single time.
> for me not even an explicit flush will work, I've to do $dbh->commit
> too whenever I write any data to the session as my database connection
> is set up with 'AutoCommit => 0'.

Ahh. So the sessions are stored in the database!

I will add a note to the docs.

> I'm not sure if this is the way it's supposed to be. Beside that
> everything works like a charm. :)

Glad to hear it.

> I use CGI::Session 4.20 and would be happy, if it would not depend on
> the huge CGI Module which I do not use anyway.

But using CGI.pm is optional!

Just add:
(1)
use CGI::Simple;
(2)
sub cgiapp_get_query
{
	my($self) = @_;

	return CGI::Simple -> new();

} # End of cgiapp_get_query.

to your app, and CGI::Application will use CGI::Simple.

Simple!

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] driver undefined during flush()

[Michael S. <ebs...@on...>]

Hi,

Am Donnerstag, den 17.04.2008, 09:43 +1000 schrieb Ron Savage:


> For the to-be-released next version of CGI::Session, I've changed the
> docs a number of times, all emphasizing that explicit flushing is deemed
> to be mandatory until we get auto-flushing to work every single time.

for me not even an explicit flush will work, I've to do $dbh->commit too
whenever I write any data to the session as my database connection is
set up with 'AutoCommit => 0'.
I'm not sure if this is the way it's supposed to be. Beside that
everything works like a charm. :)
I use CGI::Session 4.20 and would be happy, if it would not depend on
the huge CGI Module which I do not use anyway.

cu,
Michael

Re: [Cgi-session-user] driver undefined during flush()

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

Hi Phillip

> Upon closer inspection, I now believe that bug 17299 represents my
> problem pretty well.

OK. Let's define that as Progress...

> In any case, I will continue to flush() explicitly until I can upgrade
> to a version newer than 4.02 that doesn't have the problem.  Actually,
> there's no harm in always flushing explicitly, so maybe I'll just keep
> doing it that way forever.  The only major letdown for me is that if
> my program "die"s after the session has been created/modified but not
> flushed, then it won't get flushed.

For the to-be-released next version of CGI::Session, I've changed the
docs a number of times, all emphasizing that explicit flushing is deemed
to be mandatory until we get auto-flushing to work every single time.

As for version numbers, I'm sure Mark was referring to CGI::Session. The
version of CGI is less important, but upgrading to the latest of
everything is both a pain and an advantage, because - believe it or not
- the number of bugs actually goes down as time passes. Hopefully the
severity of individual bugs goes down too...
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] driver undefined during flush()

[Phillip H. <ss...@gm...>]

On Wed, Apr 16, 2008 at 1:50 AM, Ron Savage <ro...@sa...> wrote:

> On this page:
> http://rt.cpan.org/Public/Bug/Display.html?id=17299
> there is a ticket for a related problem, and down that page you'll see a
> reference to another similar problem.
> Is your error one of those?
>

Upon closer inspection, I now believe that bug 17299 represents my problem
pretty well.

In any case, I will continue to flush() explicitly until I can upgrade to a
version newer than 4.02 that doesn't have the problem.  Actually, there's no
harm in always flushing explicitly, so maybe I'll just keep doing it that
way forever.  The only major letdown for me is that if my program "die"s
after the session has been created/modified but not flushed, then it won't
get flushed.

Phillip

Re: [Cgi-session-user] driver undefined during flush()

[Phillip H. <ss...@gm...>]

On Wed, Apr 16, 2008 at 8:49 AM, Mark Stosberg <ma...@su...> wrote:

>
> I recommend upgrading to 4.x or later as the way forward. If it "used to
> work" without code changes using your 2.x code, then something else in your
> environment must have changed to cause the breakage.
>

Hi Mark.  That is the response I figured I would get :)

Hmm, I thiunk I might be confused about version numbers though.  Are we
talking about the version number of CGI or of CGI::Session?  Because I have
CGI 2.91, but I have CGI::Session 4.02.

Phillip

Re: [Cgi-session-user] driver undefined during flush()

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

> Hi.  Thanks for the reference.  I looked at some of the posts and the 
> symptom is related, but the underlying problem appears to be different.  
> Also, I am using version 2.91 while most people are using 3.95 or 4.02.

Phillip,

I recommend upgrading to 4.x or later as the way forward. If it "used to 
work" without code changes using your 2.x code, then something else in 
your environment must have changed to cause the breakage.

    Mark

Re: [Cgi-session-user] driver undefined during flush()

[Phillip H. <ss...@gm...>]

On Wed, Apr 16, 2008 at 1:50 AM, Ron Savage <ro...@sa...> wrote:

> Hi Phillip
>
> > If I flush explicitly then all is well, but if I don't and the session
> > gets flushed during DESTROY, the driver is undefined, which causes an
> > error on this line in Session.pm:
>
> On this page:
> http://rt.cpan.org/Public/Bug/Display.html?id=17299
> there is a ticket for a related problem, and down that page you'll see a
> reference to another similar problem.
> Is your error one of those?


Hi.  Thanks for the reference.  I looked at some of the posts and the
symptom is related, but the underlying problem appears to be different.
Also, I am using version 2.91 while most people are using 3.95 or 4.02.


> Also, can you please post the error message you get.
>

Sure, but I don't think it will explain any more than what I already said
($driver is null when it tries to flush).  But anyway, here's the error
message:

        (in cleanup) Can't call method "store" on an undefined value at
C:/Perl/site/lib/CGI/Session.pm line 192 during global destruction.

Phillip

Re: [Cgi-session-user] driver undefined during flush()

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

Hi Phillip

> If I flush explicitly then all is well, but if I don't and the session
> gets flushed during DESTROY, the driver is undefined, which causes an
> error on this line in Session.pm:

On this page:
http://rt.cpan.org/Public/Bug/Display.html?id=17299
there is a ticket for a related problem, and down that page you'll see a
reference to another similar problem.
Is your error one of those?
Also, can you please post the error message you get.
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

[Cgi-session-user] driver undefined during flush()

[Phillip H. <ss...@gm...>]

If I flush explicitly then all is well, but if I don't and the session gets
flushed during DESTROY, the driver is undefined, which causes an error on
this line in Session.pm:

        defined( $driver->store($self->id, $datastr) ) or

What could be going on?  I don't have this problem on Linux, only on
Windows.

I'm using Apache 2.2.8, Perl 5.8.8, CGI 2.91, and CGI::Session 4.02.  Do I
need to upgrade?

Phillip