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

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

[Jonathan S. <sw...@po...>]

On Jan 27, 2010, at 7:48 AM, Mark Stosberg wrote:

>
>> Thanks Mark. I thought of this idea too. But will this end up  
>> creating
>> a session if someone simply *reads* a session parameter? I'd like to
>> only create the session if someone actually *writes* a session
>> parameter. The latter will occur far less often.
>
> I see.  The ::Session plugin recommends a bit different logic:
>
> sub cgiapp_postrun {
>   my $self = shift;
>   $self->session->flush if $self->session_loaded;;
> }
>
> However, this process does keep the "last_access_time" up-to-date,
> which may be interesting to have.
>
> To repeat your solution:
>
>    1   my $session = CGI::Session->new(...);
>    2   $session->_unset_status(CGI::Session::STATUS_MODIFIED);
>    3
>    4   # ... web code gets executed here ...
>    5
>    6   if (!$session->_test_status(CGI::Session::STATUS_MODIFIED)) {
>    7       $session->_reset_status;
>    8   }
>    9   $session->flush();
>
> You are right, there is not a public way to do that. It would be  
> reasonable to
> add an "is_modified()" method for that, which would be consistent  
> with is_new()
> and is_expired();
>
> That docs could not that this approach has the trade-off of possibly  
> losing
> "last access time" data in favor of performance.
>
> Anyone else have input on this?

That takes care of line 6.

And if I pass the undocumented $update_atime feature to load(), I can  
get rid of line 2. (Why is that undocumented? Seems useful).

That just leaves line 7 with no public API. Line 7 was just the  
easiest way I could find to ensure that the session did not get  
written, but if there's another way to do that...

Jon

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

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

> Thanks Mark. I thought of this idea too. But will this end up creating  
> a session if someone simply *reads* a session parameter? I'd like to  
> only create the session if someone actually *writes* a session  
> parameter. The latter will occur far less often.

I see.  The ::Session plugin recommends a bit different logic:

 sub cgiapp_postrun {
   my $self = shift;
   $self->session->flush if $self->session_loaded;;
 }

However, this process does keep the "last_access_time" up-to-date,
which may be interesting to have.

To repeat your solution:

    1   my $session = CGI::Session->new(...);
    2   $session->_unset_status(CGI::Session::STATUS_MODIFIED);
    3
    4   # ... web code gets executed here ...
    5
    6   if (!$session->_test_status(CGI::Session::STATUS_MODIFIED)) {
    7       $session->_reset_status;
    8   }
    9   $session->flush();

You are right, there is not a public way to do that. It would be reasonable to
add an "is_modified()" method for that, which would be consistent with is_new()
and is_expired();

That docs could not that this approach has the trade-off of possibly losing
"last access time" data in favor of performance.

Anyone else have input on this?

    Mark

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

[Jonathan S. <sw...@po...>]

On Jan 27, 2010, at 6:41 AM, Mark Stosberg wrote:

> On Tue, 26 Jan 2010 16:42:38 -0800
> Jonathan Swartz <SW...@PO...> wrote:
>
>> On our site we create a new CGI::Session object at the beginning of
>> the request, so that it can be used anywhere in the web code.
>>
>> However, sessions are rarely written to, so at the end of the request
>> I'd like to avoid actually writing out a new session to backing store
>> unless a param actually got set. The expense of writing out new
>> sessions, and cleaning them up later, has become significant.
>
> Jon,
>
> For a model of how to do this, see CGI::Application::Plugin::Session.
> I think you'll find the concepts there portable to your own code.
> Here's the overview:
>
> session_config() collects the necessary config details, but doesn't do
> anything with them. This runs on every request and just takes a  
> momeent.
>
> session() lazy-loads a CGI::Session object using the details collected
> in session_config(). That is to say, the session is not loaded until  
> you
> call a method on CGI::Session somewhere in your code like:
>
> $self->session->param('foo');
>
> Many CGI::Application plugins are designed this way, often deferring
> loading even the helper modules themselves. This is one of the design
> principles that helps CGI::Application projects run well under CGI,
> because in a sense you only pay for what you use.
>

Thanks Mark. I thought of this idea too. But will this end up creating  
a session if someone simply *reads* a session parameter? I'd like to  
only create the session if someone actually *writes* a session  
parameter. The latter will occur far less often.

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

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

On Tue, 26 Jan 2010 16:42:38 -0800
Jonathan Swartz <SW...@PO...> wrote:

> On our site we create a new CGI::Session object at the beginning of  
> the request, so that it can be used anywhere in the web code.
> 
> However, sessions are rarely written to, so at the end of the request  
> I'd like to avoid actually writing out a new session to backing store  
> unless a param actually got set. The expense of writing out new  
> sessions, and cleaning them up later, has become significant.

Jon,

For a model of how to do this, see CGI::Application::Plugin::Session.
I think you'll find the concepts there portable to your own code.
Here's the overview:

session_config() collects the necessary config details, but doesn't do
anything with them. This runs on every request and just takes a momeent.

session() lazy-loads a CGI::Session object using the details collected
in session_config(). That is to say, the session is not loaded until you
call a method on CGI::Session somewhere in your code like:

$self->session->param('foo'); 

Many CGI::Application plugins are designed this way, often deferring
loading even the helper modules themselves. This is one of the design
principles that helps CGI::Application projects run well under CGI,
because in a sense you only pay for what you use.

    Mark

[Cgi-session-user] writing CGI::Session sessions only when necessary

[Jonathan S. <SW...@PO...>]

On our site we create a new CGI::Session object at the beginning of  
the request, so that it can be used anywhere in the web code.

However, sessions are rarely written to, so at the end of the request  
I'd like to avoid actually writing out a new session to backing store  
unless a param actually got set. The expense of writing out new  
sessions, and cleaning them up later, has become significant.

I couldn't figure out a way to do this with the public CGI::Session  
API, but I managed to get it to work this way:

    1   my $session = CGI::Session->new(...);
    2   $session->_unset_status(CGI::Session::STATUS_MODIFIED);
    3
    4   # ... web code gets executed here ...
    5
    6   if (!$session->_test_status(CGI::Session::STATUS_MODIFIED)) {
    7       $session->_reset_status;
    8   }
    9   $session->flush();

I initially reset the modified bit on line 2. Then on line 6, if the  
modified bit is still unset (meaning no param was ever set), I clear  
the status entirely, which causes the flush() on line 9 to be a no-op.

Is there a better, e.g. supported, way to do this? How do other people  
prevent new sessions from getting written to the backing store  
unnecessarily?

Thanks
Jon

Re: [Cgi-session-user] Session form field data not camptured by database (mssql)

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

Hello Peter,

Have you tried to manually flush the session?

http://search.cpan.org/dist/CGI-Session/lib/CGI/Session.pm#flush%28%29
http://search.cpan.org/dist/CGI-Session/lib/CGI/Session.pm#A_Warning_about_Auto-flushing

Maybe something is happening w/ the MSSQL dbh handle that isn't allowing it to autoflush.

Take Care,

Lee



----- Original Message ----
> From: Peter Munoz <pm...@be...>
> To: cgi...@li...
> Sent: Mon, January 11, 2010 11:51:26 AM
> Subject: [Cgi-session-user] Session form field data not camptured by database (mssql)
> 
> Hello
> 
> I have a cgi sessions problem that i can not figure out, i was hoping 
> someone could take a look at it and maybe point me in the right 
> direction. My problem occurs when i(sessions) write to the 
> database(MSSQL), i know i can connect and write to the database, but for 
> some reason or another none of my form fields are being captured and 
> written to the database table, it almost looks like it gets cut off .  
> The only thing that gets written to the database session table is the 
> "_session_id" and "_session_Atime".  
> 
> Here is what gets written to the database table "sessions" in the 
> "_a_session" field.
> 
> $D = {'_SESSION_ID' => 
> 'c035a6cc9acee1417507a89dc139a6cc','_SESSION_ATIME' => 12
> 
> I would expect to see something like this(these are the results if i 
> write to a text file, mysql,or pgdb)...
> 
> $D = {'email' => undef,'_SESSION_ID' =>
> 'f54d371a4bede56d55b77777d152b9f15dd','_SESSION_ATIME' =>
> 1262913258,'_SESSION_REMOTE_ADDR' => '127.0.0.1','_SESSION_EXPIRE_LIST'
> => {},'name' => 'Peter','_SESSION_CTIME' => 1262913230};;$D
> 
> 
> Thank you for taking the time, any advise would be great
> 
> Thank you
> -pm
> 
> 
> 
> Here is my code
> 
> #!/usr/bin/perl
> use CGI::Carp qw( fatalsToBrowser );
> use CGI::Session;
> use CGI;
> use DBI;
> 
> use Time::Local;
> use Tie::IxHash;
> use DBD::Sybase;
> 
> my $session;
> my $cgi = new CGI;
> 
> require CGI::Session::Driver::DBI;
> @ISA = qw( CGI::Session::Driver::DBI );
> 
> 
> my $dbname="dbname";
> my $host="server:port";
> my $db_user="user";
> my $db_pass="password";
> my $db_driver="sybase";
> #my $connectionInfo="dbi:$db_driver:$host:$dbname";
> 
> #establish a database connection
> $dbh = DBI->connect($connectionInfo,$db_user, $db_pass) ||  "Can't 
> connect to $dbname: $DBI::errstr";
> 
> #set the sesssion and what session driver to use
> $session = new CGI::Session("driver:odbc", $cgi, {Handle=>$dbh,
> TableName => 'CollectorDev.dbo.sessions'});
> 
> #Define cookie that with the same session id that is in the databse, so
> we can referrence this record
> my $cookie = $cgi->cookie(-name=>'CGISESSID', -value=>$session->id,
> -expires=>'+1d');
> 
> #set the cookie/session on the users station (computer)
> print $cgi->header(-cookie=>$cookie);
> 
> my $sid = $session->id();
> 
> 
> 
> ###############################################################
> 
> $name = $cgi->param("name");
> 
> $session->param(name, $name);
> 
> $name = $session->param("name");
> 
> print "My name is $name 
";
> print "My sid is $sid 
";
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user

[Cgi-session-user] Session form field data not camptured by database (mssql)

[Peter M. <pm...@be...>]

Hello

I have a cgi sessions problem that i can not figure out, i was hoping 
someone could take a look at it and maybe point me in the right 
direction. My problem occurs when i(sessions) write to the 
database(MSSQL), i know i can connect and write to the database, but for 
some reason or another none of my form fields are being captured and 
written to the database table, it almost looks like it gets cut off .  
The only thing that gets written to the database session table is the 
"_session_id" and "_session_Atime".   

Here is what gets written to the database table "sessions" in the 
"_a_session" field.

$D = {'_SESSION_ID' => 
'c035a6cc9acee1417507a89dc139a6cc','_SESSION_ATIME' => 12

I would expect to see something like this(these are the results if i 
write to a text file, mysql,or pgdb)...

$D = {'email' => undef,'_SESSION_ID' =>
'f54d371a4bede56d55b77777d152b9f15dd','_SESSION_ATIME' =>
1262913258,'_SESSION_REMOTE_ADDR' => '127.0.0.1','_SESSION_EXPIRE_LIST'
=> {},'name' => 'Peter','_SESSION_CTIME' => 1262913230};;$D


Thank you for taking the time, any advise would be great

Thank you
-pm



Here is my code

#!/usr/bin/perl
use CGI::Carp qw( fatalsToBrowser );
use CGI::Session;
use CGI;
use DBI;

use Time::Local;
use Tie::IxHash;
use DBD::Sybase;

my $session;
my $cgi = new CGI;

require CGI::Session::Driver::DBI;
@ISA = qw( CGI::Session::Driver::DBI );


my $dbname="dbname";
my $host="server:port";
my $db_user="user";
my $db_pass="password";
my $db_driver="sybase";
#my $connectionInfo="dbi:$db_driver:$host:$dbname";

#establish a database connection
$dbh = DBI->connect($connectionInfo,$db_user, $db_pass) ||  "Can't 
connect to $dbname: $DBI::errstr";

#set the sesssion and what session driver to use
$session = new CGI::Session("driver:odbc", $cgi, {Handle=>$dbh,
TableName => 'CollectorDev.dbo.sessions'});

#Define cookie that with the same session id that is in the databse, so
we can referrence this record
my $cookie = $cgi->cookie(-name=>'CGISESSID', -value=>$session->id,
-expires=>'+1d');

#set the cookie/session on the users station (computer)
print $cgi->header(-cookie=>$cookie);

my $sid = $session->id();



###############################################################

$name = $cgi->param("name");

$session->param(name, $name);

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

print "My name is $name <BR>";
print "My sid is $sid <BR>";

Re: [Cgi-session-user] Problem while using CGI::Session module

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

On Fri, 9 Oct 2009 17:52:27 -0400
Srikanth Murthy <sri...@gm...> wrote:

> Hi,
> 
>  I am currently developing a website which is hosted on startlogic.com. I
> was trying to implement sessions on my site and have tried to use the
> CGI:Session module as described on the CPAN site. I am able to generate a
> session header and a cookie for the session, but the problem I am facing is
> that I am unable to retrive the session information on the next page.

Try adding $session->flush() to the bottom of the first page code. 

Also, consider adding "use strict" and "use warnings" as a best practice. 

   Mark

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

[Cgi-session-user] Problem while using CGI::Session module

[Srikanth M. <sri...@gm...>]

Hi,

 I am currently developing a website which is hosted on startlogic.com. I
was trying to implement sessions on my site and have tried to use the
CGI:Session module as described on the CPAN site. I am able to generate a
session header and a cookie for the session, but the problem I am facing is
that I am unable to retrive the session information on the next page.
Following is the sample code that I have tried :

******* code on page 1 **************************

#!/usr/bin/perl
use CGI::Carp 'fatalsToBrowser';
use LWP::Simple;
use CGI qw(:standard);
use CGI::Session;
import CGI;

print "Content-type:text/html\n\n";


$session = new CGI::Session();
$CGISESSID = $session->id();
print $session->header();
$session->param('user',"XYZ");

print "hi!\n";
print $session->param('user');
print "<a href=session2.cgi>Try this on page 2</a>";



******************** Code on Page 2 *******************

#!/usr/bin/perl
use LWP::Simple;
use DBI;
use CGI qw(:standard);
use CGI::Session;
import CGI;

print "Content-type:text/html\n\n";

$session =  new CGI::Session();
    $CGISESSID = $session->id();
   print $session->header();
$user=$session->param('user');


print "<h2>User is $user</h2>";

**************************************


The print $session->param('user'); prints the result 'XYZ' on the first
page, but is just *returning a blank on the second page*. I have tried many
different combination of codes to make it work, but it still is giving the
same problem.

Iv tried to read many related forums, but am unable to find a solution.

Kindly let me know if there is a solution to this. Any kind of help would be
greatly appreciated. Thank you for your time.

Regards,
Srikanth

Re: [Cgi-session-user] CGI::Session: IP_MATCH and RT#47795

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

Hi Folks

Mark Stosberg wrote:
>> Opinions?
>
> Ron, thanks for the detailed look into this.
>
> I want to ask another question. This has apparently been seriously broken
> for
> some time, and is not even documented in the main CGI::Session POD.


Correct.


> I think that gives us some flexibilty for more radical solutions. Are
> there other completely different approaches we should consider to
> addres the core security issue?


I'm open to alternatives.

My solution ignores some sessions, but that means the user cannot provide
an option as the whether or not they want to ignore them. Giving them an
option would be good.


I'd like to see the taint solution released first. I don't mean that as
pressure on you. Just that it'd be frustrating for users.


> For example, maybe something could be done with the new 'layered' driver:
>
> http://search.cpan.org/~crein/CGI-Session-Driver-layered-0.7/lib/CGI/Session/Driver/layered.pm
>
>  Where one layer could be a "security" layer.
>  CGI-Session-Driver-layered-0.7
>
> Or more generally: is there a way security concerns like this can be
> addressed
> in the drivers or serializer layers?


I'll have to think about how this module applies to the case in question.
Or could someone explain it to me :-)?

Also:  Here is a quote from the docs for CGI::Session::Driver::layered:

"When fetching a session, the driver with the most recent copy of the
session is used. The drivers are searched in the order they were
configured."

Can you see how those 2 stmts contradict each other?

You can only know which is the most recent if you check (one of) the
a/e/m-times of /all/ of them, and compare those times. So the search
/order/ doesn't make sense to me, when all simply have to be searched.

Or, am I missing something :-)?



> I don't use the -ip_match feature myself, and don't expect to in the
> future,
> so I don't feel strongly about which way the logic is implemented.

Same here.

Nevertheless, since we've had a ticket raised, someone's using this
feature, and what worries me is how many are using it and are not on this
mailing list? Ans: An unknowable number.

This just means the feature has to be supported into the future.

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

Re: [Cgi-session-user] CGI::Session: IP_MATCH and RT#47795

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

> Opinions?

Ron, thanks for the detailed look into this.

I want to ask another question. This has apparently been seriously broken for
some time, and is not even documented in the main CGI::Session POD.

I think that gives us some flexibilty for more radical solutions. Are
there other completely different approaches we should consider to
addres the core security issue?

For example, maybe something could be done with the new 'layered' driver:

http://search.cpan.org/~crein/CGI-Session-Driver-layered-0.7/lib/CGI/Session/Driver/layered.pm

 Where one layer could be a "security" layer. 
 CGI-Session-Driver-layered-0.7 

Or more generally: is there a way security concerns like this can be addressed
in the drivers or serializer layers?

I don't use the -ip_match feature myself, and don't expect to in the future, 
so I don't feel strongly about which way the logic is implemented.
    
    Mark

[Cgi-session-user] CGI::Session: IP_MATCH and RT#47795

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

Hi Folks

Right at the end of CGI::Session::Tutorial there is a discussion of IP
matching and session handling.

I won't repeat the text here.

IP_MATCH does not appear in the POD for CGI::Session itself.

The problem is that when $CGI::Session::IP_MATCH is set (e.g. to 1),
calling find() calls load(), and this automatically and unexpectedly
deletes all sessions where the IP's do not match.

There are various issues:

o The POD in CGI::Session::Tutorial is wrong. The code does not die as
stated, when the IPs don't match. Search for 'checking if previous
session ip matches current ip' in the source of CGI::Session to find the
logic. The POD can easily be fixed.

o The POD in CGI::Session lacks a discussion of $CGI::Session::IP_MATCH.
That can easily be fixed.

o What exactly do we want the code to do (when $CGI::Session::IP_MATCH
is set)?

1) When load() is called /by the user/, deleting all sessions with
mismatching IP addresses, which is what happens now, seems unnecessarily
drastic, but that's the documented behaviour, so I assume we're stuck
with it. However...

2) When load() is called /via find()/, do we:
- Return only sessions with matching IPs, and ignore the others; or
- Return the sessions with matching IPs, and delete the others?

I think that the mismatches should not be deleted, since it's not just
undocumented, and hence unexpected, from a call to find(), it's due to
the implementation of find(), and users should not be disadvantaged by
how find() operates.

Opinions?

Lastly: Is there anything else which needs to be considered?

Background:
To investigate this problem, I've written a new test, t/find.ip.match.t,
which I use to create and find sets of sessions, with
$CGI::Session::IP_MATCH set and reset.

To help, I've patched the code so now the last param to load() as a
hashref always, if there are 4 params.

Previously there was an undocumented scalar $dont_update_atime possible
as the 4th param, /or/ a hashref. It's now a hash key (as update_atime
actually).

And there's a new key, find_is_caller, so we know if the user or find()
is the caller. All tests still pass.

These, internal-only, changes will be in the next version, after the
patch for RT#48733 (taint prob with 5.10.0) is released (having been
fixed already).

These patches don't change the behaviour of the code, yet.

But the problem remains, what exactly should the code do?

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

Re: [Cgi-session-user] Cgi-session-user Digest, Vol 26, Issue 2

[<mca...@ma...>]

> I haven't looked at this closely, but my hope is that there is not a not need
> for CGI::Session to add two new methods for every attribute that  
> exists in CGI::Cookie.
> ( Example: httponly() and is_httponly(). )
>
> I would hope there is a design where can do the minimum amount  
> possible in our cookie() method, and pass everything on through to  
> CGI::Cookie.
>
>     Mark
>
>

so the only way to develop a secure session is this?

use CGI::Cookie;
my $query = new CGI;
my $cookie= undef;

$cookie = new CGI::Cookie(  	-secure     => $secure,
		                -httponly   => 1,
		                -name       =>$session->name,
		                -value      =>$session->id,
		                -expires    => '+' .$session->expire. 's',
                     );

print $query->header(-cookie=>$cookie, -type=>'text/html', charset =>  
'utf-8');

I don't recommend use the method:

print $session->header();

because not use the flag httponly, so an attacker could steal the  
cookie with javascript


	Miguel

Re: [Cgi-session-user] [Fwd: Re: CGI Session not support HTTPONLY]

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

Hi Folks

On Fri, 2009-09-04 at 09:22 -0400, Mark Stosberg wrote:
> > > I'dont really remember, but a I'think the code look like this: 
> > > 
> > > sub is_httponly  { return defined($_[0]->dataref) ? 
> > > $_[0]->dataref->{_HTTPONLY}: 0 }
> > > 
> > > sub is_secure  { return defined($_[0]->dataref) ? 
> > > $_[0]->dataref->{_SECURE}: 0 }
> 
> I haven't looked at this closely, but my hope is that there is not a not need
> for CGI::Session to add two new methods for every attribute that exists in CGI::Cookie.
> ( Example: httponly() and is_httponly(). )


Agreed.


> I would hope there is a design where can do the minimum amount possible in our cookie() method, and pass everything on through to CGI::Cookie.

Miguel has sent me his version of Session.pm.

Here's the diff between the soon-to-be-released 4.43 and his 4.42:

ron@zoe:~/repos/cgi-session$ diff lib/CGI/Session.pm ~/Session.pm 
10c10
< $CGI::Session::VERSION  = '4.43';
---
> $CGI::Session::VERSION  = '4.42';
19a20,44
> 
> #Added
> sub httponly {
>     my $self = shift;
>     my $httponly = shift || 0;
> 
>     my $dataref = $self->{_DATA};
>     $dataref->{_HTTPONLY} = $httponly;
>     $self->_set_status( STATUS_MODIFIED );
>     
>     return $self;
> }
> 
> #Added
> sub secure {
>     my $self = shift;
>     my $secure = shift || 0;
> 
>     my $dataref = $self->{_DATA};
>     $dataref->{_SECURE} = $secure;
>     $self->_set_status( STATUS_MODIFIED );
>     
>     return $self;
> }
> 
89a115
>         $dataref->{_HTTPONLY} = 1;
104c130,134
< sub is_expired      { $_[0]->_test_status( STATUS_EXPIRED ) }
---
> #original
> # sub is_expired      { $_[0]->_test_status( STATUS_EXPIRED ) }
> 
> #modified
> sub is_expired      { return ( $_[0]->dataref->{_SESSION_ATIME} +
$_[0]->{_DATA}->{_SESSION_ETIME} <= time() ) ? 1 : 0 }


If you search the source for 'checking for expiration ticker' you'll see
this replacement for is_expired() repeats the code which sets
STATUS_EXPIRED, so I don't see the point of the patch.


115a146,151
> #Added
> sub is_httponly     { return defined($_[0]->dataref) ?
$_[0]->dataref->{_HTTPONLY}      : 0 }
> 
> #Added
> sub is_secure       { return defined($_[0]->dataref) ?
$_[0]->dataref->{_SECURE}        : 0 }
> 
335a372,374
> 
> #original
> =item
352a392
> =cut
353a394,396
> #modified
> sub cookie {
>     my $self = shift;
354a398,427
>     my $query = $self->query();
>     my $cookie= undef;
> 
>     if ( $self->is_expired ) {
> 
>         $cookie = $query->cookie(   -secure=> $self->is_secure, 
>                                     -httponly=> $self->is_httponly, 
>                                     -name=> $self->name, 
>                                     -value=> $self->id, 
>                                     -expires=> '-1d', @_ 
>                             );


If the cookie has expired, would there be any need to set secure and
httponly?


>     } 
>     elsif ( my $t = $self->expire ) {
>         $cookie = $query->cookie(   -secure=> $self->is_secure, 
>                                     -httponly=> $self->is_httponly, 
>                                     -name=> $self->name, 
>                                     -value=> $self->id, 
>                                     -expires=> '+' . $t . 's', @_ 
>                         );
>     } 
>     else {
>         $cookie = $query->cookie(   -secure=> $self->is_secure, 
>                                     -httponly=> $self->is_httponly, 
>                                     -name=> $self->name, 
>                                     -value=> $self->id, @_ 
>                             );
>     }
> 
>     return $cookie;
> }
643a717
>             _HTTPONLY       => 1,
1415c1489
< checking out the code repository. You can browse the git repository
from here:
---
> checking out the code repository. You can browse the Subversion
repository from here:
1417c1491
<  http://github.com/cromedome/cgi-session/tree/master
---
>  http://svn.cromedome.net/repos/CGI-Session
1419c1493
< or check out the code with:
---
> Or check it directly with C<svn> from here:
1421c1495
<  git clone git://github.com/cromedome/cgi-session.git
---
>  https://svn.cromedome.net/repos/CGI-Session
1473a1548
>


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

Re: [Cgi-session-user] [Fwd: Re: CGI Session not support HTTPONLY]

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

> > I'dont really remember, but a I'think the code look like this: 
> > 
> > sub is_httponly  { return defined($_[0]->dataref) ? 
> > $_[0]->dataref->{_HTTPONLY}: 0 }
> > 
> > sub is_secure  { return defined($_[0]->dataref) ? 
> > $_[0]->dataref->{_SECURE}: 0 }

I haven't looked at this closely, but my hope is that there is not a not need
for CGI::Session to add two new methods for every attribute that exists in CGI::Cookie.
( Example: httponly() and is_httponly(). )

I would hope there is a design where can do the minimum amount possible in our cookie() method, and pass everything on through to CGI::Cookie.

    Mark

[Cgi-session-user] [Fwd: Re: CGI Session not support HTTPONLY]

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

-------- Forwarded Message --------
> From: Miguel (LINTI) <mca...@ma...>
> To: Ron Savage <ro...@sa...>
> Subject: Re: CGI Session not support HTTPONLY
> Date: Thu, 03 Sep 2009 22:48:36 -0300
> 
> Hi, Ron
> 
> sorry copy and paste error, ;)
> 
> I'dont really remember, but a I'think the code look like this: 
> 
> sub is_httponly  { return defined($_[0]->dataref) ? 
> $_[0]->dataref->{_HTTPONLY}: 0 }
> 
> sub is_secure  { return defined($_[0]->dataref) ? 
> $_[0]->dataref->{_SECURE}: 0 }
> 
> I'm not on my notebook
> 
> Miguel
> 
> > On Thu, 2009-09-03 at 16:27 -0300, Carbone Miguel wrote:
> >   
> >> Thanks for help, but $session->cookie( -httponly => 1 ) doesn't work
> >>
> >>
> >> this methods are added by myself (rencently updated to CGI::Session 4.42)
> >>
> >> sub httponly {
> >>     my $self = shift;
> >>
> >>     my $dataref = $self->{_DATA};
> >>     $dataref->{_HTTPONLY} = 1;
> >>     $self->_set_status( STATUS_MODIFIED );
> >>
> >>     return $self;
> >> }
> >>
> >> sub secure {
> >>     my $self = shift;
> >>     my $secure = shift || 0;
> >>
> >>     my $dataref = $self->{_DATA};
> >>     $dataref->{_SECURE} = $secure;
> >>     $self->_set_status( STATUS_MODIFIED );
> >>
> >>     return $self;
> >> }
> >>
> >>
> >> sub cookie {
> >>     my $self = shift;
> >>
> >>     my $query = $self->query();
> >>     my $cookie= undef;
> >> # FIXME se esta repitiendo, se podria generalizar
> >>     if ( $self->is_expired ) {
> >>
> >>         $cookie = $query->cookie(   -secure=> $self->is_secure,
> >>     
> >
> >
> > I think this is a bug. Surely is_secure() has to return
> > $dataref->{_SECURE}, instead of $self, for this to work?
> >
> >
> >   
> >>                                     -httponly=> $self->is_httponly,
> >>     
> >
> >
> > I think this is a bug. Surely is_httponly() has to return
> > $dataref->{_HTTPONLY}, instead of $self, for this to work?
> >
> >
> >   
> >>                                     -name=>$self->name,
> >>                                     -value=>$self->id,
> >>                                     -expires=> '-1d', @_
> >>                             );
> >>     }
> >>     elsif ( my $t = $self->expire ) {
> >>         $cookie = $query->cookie(   -secure=> $self->is_secure,
> >>                                     -httponly=> $self->is_httponly,
> >>                                     -name=>$self->name,
> >>                                     -value=>$self->id,
> >>                                     -expires=> '+' . $t . 's', @_
> >>                         );
> >>     }
> >>     elsif ( $self->is_httponly ) {
> >>         $cookie = $query->cookie( -secure=> $self->is_secure, 
> >> -httponly=> $self->is_httponly, -name=>$self->name, -value=>$self->id, 
> >> @_ );
> >>     }
> >>     else {
> >>         $cookie = $query->cookie( -name=>$self->name, -value=>$self->id, 
> >> @_ );
> >>     }
> >>     return $cookie;
> >> }
> >>
> >> Miguel
> >>
> >> ---------------------------------
> >> Carbone Miguel
> >> Proyecto KOHA
> >> LINTI - Facultad de Informática
> >> Universidad Nacional de La Plata
> >> http://koha.linti.unlp.edu.ar/
> >>
> >>
> >> Mark Stosberg <ma...@su...> escribió:
> >>
> >>     
> >>>> Is there a way to do this without modifying the method? This could bring
> >>>> problems when updating the CGI::Session version.
> >>>>
> >>>>      elsif ( $self->is_httponly ) {
> >>>>          $cookie = $query->cookie( -httponly=> 1, -name=>$self->name,
> >>>>  -value=>$self->id, @_ );
> >>>>         
> >>> Where does the "is_httponly" method come from?
> >>>
> >>> Can't you just do this?
> >>>
> >>>     $session->cookie( -httponly => 1 )
> >>>
> >>> The cookie() method appears to be made to pass through any arguments 
> >>> it does not recognize.
> >>>
> >>> Future questions should be directed to the CGI::Session users list, 
> >>> not the maintainers directly.
> >>>
> >>>     Mark
> >>>
> >>>
> >>>       
> >>
> >>     
> 
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] CGI Session not support HTTPONLY

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

Hi

On Thu, 2009-09-03 at 16:27 -0300, Carbone Miguel wrote:
> Thanks for help, but $session->cookie( -httponly => 1 ) doesn't work
> 
> 
> this methods are added by myself (rencently updated to CGI::Session 4.42)
> 
> sub httponly {
>     my $self = shift;
> 
>     my $dataref = $self->{_DATA};
>     $dataref->{_HTTPONLY} = 1;
>     $self->_set_status( STATUS_MODIFIED );
> 
>     return $self;
> }
> 
> sub secure {
>     my $self = shift;
>     my $secure = shift || 0;
> 
>     my $dataref = $self->{_DATA};
>     $dataref->{_SECURE} = $secure;
>     $self->_set_status( STATUS_MODIFIED );
> 
>     return $self;
> }
> 
> 
> sub cookie {
>     my $self = shift;
> 
>     my $query = $self->query();
>     my $cookie= undef;
> # FIXME se esta repitiendo, se podria generalizar
>     if ( $self->is_expired ) {
> 
>         $cookie = $query->cookie(   -secure=> $self->is_secure,


I think this is a bug. Surely is_secure() has to return
$dataref->{_SECURE}, instead of $self, for this to work?


>                                     -httponly=> $self->is_httponly,


I think this is a bug. Surely is_httponly() has to return
$dataref->{_HTTPONLY}, instead of $self, for this to work?


>                                     -name=>$self->name,
>                                     -value=>$self->id,
>                                     -expires=> '-1d', @_
>                             );
>     }
>     elsif ( my $t = $self->expire ) {
>         $cookie = $query->cookie(   -secure=> $self->is_secure,
>                                     -httponly=> $self->is_httponly,
>                                     -name=>$self->name,
>                                     -value=>$self->id,
>                                     -expires=> '+' . $t . 's', @_
>                         );
>     }
>     elsif ( $self->is_httponly ) {
>         $cookie = $query->cookie( -secure=> $self->is_secure, 
> -httponly=> $self->is_httponly, -name=>$self->name, -value=>$self->id, 
> @_ );
>     }
>     else {
>         $cookie = $query->cookie( -name=>$self->name, -value=>$self->id, 
> @_ );
>     }
>     return $cookie;
> }
> 
> Miguel
> 
> ---------------------------------
> Carbone Miguel
> Proyecto KOHA
> LINTI - Facultad de Informática
> Universidad Nacional de La Plata
> http://koha.linti.unlp.edu.ar/
> 
> 
> Mark Stosberg <ma...@su...> escribió:
> 
> >> Is there a way to do this without modifying the method? This could bring
> >> problems when updating the CGI::Session version.
> >>
> >>      elsif ( $self->is_httponly ) {
> >>          $cookie = $query->cookie( -httponly=> 1, -name=>$self->name,
> >>  -value=>$self->id, @_ );
> >
> > Where does the "is_httponly" method come from?
> >
> > Can't you just do this?
> >
> >     $session->cookie( -httponly => 1 )
> >
> > The cookie() method appears to be made to pass through any arguments 
> > it does not recognize.
> >
> > Future questions should be directed to the CGI::Session users list, 
> > not the maintainers directly.
> >
> >     Mark
> >
> >
> 
> 
> 
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] CGI Session not support HTTPONLY

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

Hi Folks

On Fri, 2009-09-04 at 11:31 +1000, Ron Savage wrote:
> Hi Miguel
> 
> On Thu, 2009-09-03 at 16:27 -0300, Carbone Miguel wrote:
> > Thanks for help, but $session->cookie( -httponly => 1 ) doesn't work
> 
> I'm not surprised. The class CGI::Session does not have a cookie()
> method.

Oops. My mistake. I was searching the HTML version of the POD, not the
source :-(.

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

Re: [Cgi-session-user] CGI Session not support HTTPONLY

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

Hi Miguel

On Thu, 2009-09-03 at 16:27 -0300, Carbone Miguel wrote:
> Thanks for help, but $session->cookie( -httponly => 1 ) doesn't work

I'm not surprised. The class CGI::Session does not have a cookie()
method.

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

Re: [Cgi-session-user] CGI Session not support HTTPONLY

[Carbone M. <mca...@ma...>]

> Hi, I am using CGI-Session-4.42 in a project and I need the cookie to 
> support the httponly (http://www.owasp.org/index.php/HTTPOnly) flag, I 
> modified the cookie method to support it.
> Is there a way to do this without modifying the method? This could 
> bring problems when updating the CGI::Session version.
>
> this methods are added by myself (rencently updated to CGI::Session 4.42)
>
> sub httponly {
>     my $self = shift;
>
>     my $dataref = $self->{_DATA};
>     $dataref->{_HTTPONLY} = 1;
>     $self->_set_status( STATUS_MODIFIED );
>
>     return $self;
> }
>
> sub secure {
>     my $self = shift;
>     my $secure = shift || 0;
>
>     my $dataref = $self->{_DATA};
>     $dataref->{_SECURE} = $secure;
>     $self->_set_status( STATUS_MODIFIED );
>
>     return $self;
> }
>
>
> sub cookie {
>     my $self = shift;
>
>     my $query = $self->query();
>     my $cookie= undef;
> # FIXME se esta repitiendo, se podria generalizar
>     if ( $self->is_expired ) {
>
>         $cookie = $query->cookie(   -secure=> $self->is_secure,
>                                     -httponly=> $self->is_httponly,
>                                     -name=>$self->name,
>                                     -value=>$self->id,
>                                     -expires=> '-1d', @_
>                             );
>     }
>     elsif ( my $t = $self->expire ) {
>         $cookie = $query->cookie(   -secure=> $self->is_secure,
>                                     -httponly=> $self->is_httponly,
>                                     -name=>$self->name,
>                                     -value=>$self->id,
>                                     -expires=> '+' . $t . 's', @_
>                         );
>     }
>     elsif ( $self->is_httponly ) {
>         $cookie = $query->cookie( -secure=> $self->is_secure, 
> -httponly=> $self->is_httponly, -name=>$self->name, -value=>$self->id, 
> @_ );
>     }
>     else {
>         $cookie = $query->cookie( -name=>$self->name, 
> -value=>$self->id, @_ );
>     }
>     return $cookie;
> }
>
> Regards, Miguel
>

[Cgi-session-user] Taint bug reported for CGI::Session, affecting 5.10 and higher

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

You may be interested in this newly reported CGI::Session bug:

#48733: Fatal taint error in CGI::Session::ErrorHandler, starting with perl 5.10.
https://rt.cpan.org/Ticket/Display.html?id=48733

This is not one I plan to get to myself soon. Tests and patches for the bug are
welcome and can posted to the ticket. You can also post a comment there to
declare that you are "taking" the ticket to work on.

    Mark

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

[Cgi-session-user] Locking a session

[Bernie C. <be...@re...>]

What I need to do is *lock* a particular session.  The problem is arising 
because some browsers [probably all these days] can/do make multiple 
parallel HTTP connections as they load a page, and what I'm seeing is 
that my sessions are getting messed up because two CGIs [probably three, 
actually, in the case at hand!] are overlapping, and so one process's 
changes to the session are getting clobbered by another's.  It is a 
standard parallel-access problem, and generally the way you deal with it 
is to lock the resource so that the second process will wait until the 
first is done....  My problem is that I can't figure out a way to do that 
within the context of CGI::Session.  I'd like to find some sort of clean 
way to handle this, although I might have to resort to brute force [using 
some kind of filesystem lock in /tmp or something like that].  

Anyhow, I was wondering: have any others run into this problem of 
"parallel" CGI access to a session and ways to cope with it?  THANKS!!

  /Bernie\


-- 
Bernie Cosell                   RevNet Technologies
mailto:be...@re...           Roanoke, VA

[Cgi-session-user] Progress on auto-flushing

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

Hi Folks

This message is basically for people subscribed to this list but not
subscribed to the CGI::Application list.

Recently, on the latter list, discussions on the failure of CGI::Session
to perform auto-flushing have uncovered some fascinating information.

I have patched the docs -but not the code - for CGI:Session, and a draft
can be seen here:

http://savage.net.au/Session.html

Only the sections on auto-flushing and credits have been changed.

There is no plan to patch the code for CGI::Session.

Feedback on the new docs is welcome on this list.

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

Re: [Cgi-session-user] Question

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

> Date: Thu, 20 Nov 2008 11:39:54 -0500
> From: ma...@su...
> To: cgi...@li...
> Subject: Re: [Cgi-session-user] Question
> 
> 
> After a second look:
> 
> >  @entry1 = ("@required" . "@row1") 
> 
> That looks like invalid Perl. Does @entry1 have the value
> you expect after do this? What is your intent here? Do you
> want to join two arrays together? That would be:
> 
>     @entry1 = @required, @row1;
> 
> > $session->save_param(["@entry1","@entry2","@entry3","@entry4","@entry5"]);
> 
> Compare this syntax to the documented ways to call this method:
> http://search.cpan.org/~markstos/CGI-Session-4.38/lib/CGI/Session.pm#save_param()
> 
> The "save_param()" looks like invalid Perl, and invalid call to save_param,
> which usually takes a query object as the first argument. You are using arrays
> as strings here as well.
> 
> It's seems like there's still some learning to do about the fundamentals of Perl.
> 
> I suggest taking advantage of the resources here:
> http://perl-begin.org/
> 
> Until you understand how arrays, hashes, scalars and concatenation works, using
> modules like CGI::Session will likely remain frustrating and full of debugging.
> 
>     Mark

Mark,

Thank you very much for your patience and time spent on this already.  I appreciate the references and will take a look at them.

Could you please show me the proper way to save multiple array's using save_param()?  This is something that I need a resolution to quickly, plus I learn better this way :).

Thanks



_________________________________________________________________
Color coding for safety: Windows Live Hotmail alerts you to suspicious email.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008 

Re: [Cgi-session-user] Question

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

After a second look:

>  @entry1 = ("@required" . "@row1") 

That looks like invalid Perl. Does @entry1 have the value
you expect after do this? What is your intent here? Do you
want to join two arrays together? That would be:

    @entry1 = @required, @row1;

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

Compare this syntax to the documented ways to call this method:
http://search.cpan.org/~markstos/CGI-Session-4.38/lib/CGI/Session.pm#save_param()

The "save_param()" looks like invalid Perl, and invalid call to save_param,
which usually takes a query object as the first argument. You are using arrays
as strings here as well.

It's seems like there's still some learning to do about the fundamentals of Perl.

I suggest taking advantage of the resources here:
http://perl-begin.org/

Until you understand how arrays, hashes, scalars and concatenation works, using
modules like CGI::Session will likely remain frustrating and full of debugging.

    Mark