cgi-session-user Mailing List for CGI-Session (Page 23)

Brought to you by: sherzodr

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

You can subscribe to this list here.

2002	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (4)
2003	Jan	Feb	Mar (13)	Apr (6)	May (2)	Jun (3)	Jul (2)	Aug (10)	Sep (9)	Oct (15)	Nov (1)	Dec (4)
2004	Jan	Feb	Mar (7)	Apr	May (1)	Jun	Jul (1)	Aug (1)	Sep	Oct	Nov	Dec (1)
2005	Jan (1)	Feb (8)	Mar (1)	Apr (1)	May (9)	Jun	Jul (14)	Aug (32)	Sep (34)	Oct (16)	Nov (6)	Dec (15)
2006	Jan (5)	Feb (27)	Mar (60)	Apr (12)	May (17)	Jun (24)	Jul (27)	Aug (16)	Sep (13)	Oct (19)	Nov (22)	Dec (29)
2007	Jan (23)	Feb (33)	Mar (42)	Apr (30)	May (14)	Jun (5)	Jul (12)	Aug	Sep (1)	Oct	Nov	Dec
2008	Jan (6)	Feb (9)	Mar (48)	Apr (20)	May	Jun	Jul (1)	Aug	Sep	Oct (2)	Nov (9)	Dec
2009	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug (1)	Sep (11)	Oct (2)	Nov	Dec
2010	Jan (9)	Feb (28)	Mar	Apr (12)	May (13)	Jun	Jul (3)	Aug	Sep (1)	Oct (3)	Nov	Dec (9)
2011	Jan	Feb	Mar (6)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun	Jul (4)	Aug	Sep	Oct	Nov	Dec (8)
2015	Jan	Feb (4)	Mar	Apr	May (2)	Jun	Jul (5)	Aug	Sep	Oct	Nov	Dec
2024	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

Flat | Threaded

<< < 1 .. 21 22 23 24 25 .. 29 > >> (Page 23 of 29)

RE: [Cgi-session-user] O_TRUNC change? (was: (Doc)bug 4.0.2: Automagic flushing)

From: Sherzod R. <she...@ha...> - 2005-09-13 04:09:44

> In particular, the O_TRUNC attribute was 
> removed. Anyone
> know why?

I had received reports from users complaining about cases of session data
file corruption. truncate()ing after flock() seemed to solve the problem.

I would be surprised if it had something to do with K.G.'s report.

--  
Sherzod

[Cgi-session-user] O_TRUNC change? (was: (Doc)bug 4.0.2: Automagic flushing)

From: Mark S. <ma...@su...> - 2005-09-13 03:20:02

On Mon, Sep 12, 2005 at 01:35:53AM -0400, Sherzod Ruzmetov wrote:
> 
> So far few people complained about session not being automatically flushed,
> but no one was able to recreate the problem in a test script.

Matt LeBlanc noted to me that the call to sysopen() has changed in the
default driver. In particular, the O_TRUNC attribute was removed. Anyone
know why?

His follow-up message to K.G. was along these lines, but we haven't
gotten a response from K.G. yet. 

I researched O_TRUNC some and could find very little about when to use
it and avoid it, so I can't recommend one variation as preferable over
the other.

However, I'm inclined to put it back how it was unless there is a
compelling reason to change it, as that should maximize compatibility.

    Mark

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

Re: [Cgi-session-user] CGI::Session does not seem to be working for me

From: Cees H. <ce...@gm...> - 2005-09-13 03:19:19

On 9/12/05, Sherzod Ruzmetov <she...@ha...> wrote:
> Vahid
> P.S. You would discover this eventually, but you should look into
> CGI::Application and HTML::Template (Or Template Toolkit). The way you're
> doing things right now (with if/else, and embedded 'HTML'), you can only =
go
> so far.

I thought I'd take the opportunity to show how easy this can actually
be done, and how CGI::Application can really simplify your web apps.=20
And also if I may, I'll take a second to show off the new
Authentication plugin for CGI::Application (which can use CGI::Session
to keep things on topic).  The new Authentication plugin will be on
CPAN by the end of the week, but a preview version is available here:=20
http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin-Authentica=
tion-0.01.tar.gz

Also, I should note that there is no LDAP driver yet, but it is very
easy to build new authentication drivers (and LDAP is a planned
addition).

For simplicity, just put all the following files into a web enabled
directory and call myapp.cgi from a web browser:

--------------------------------------
myapp.cgi
--------------------------------------
#!/usr/bin/perl

use strict;
use warnings;
use lib qw/./;

use MyApp;
MyApp->new->run;

--------------------------------------
MyApp.pm
--------------------------------------
package MyApp;

use base qw/CGI::Application/;

use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::AutoRunmode;
use CGI::Application::Plugin::Authentication;

MyApp->auth->config(
    #DRIVER =3D> [ 'LDAP', DSN =3D> $dsn, PASSWORD =3D> $password ],
    DRIVER =3D> [ 'Generic', { user1 =3D> '123', user2 =3D> '1234' } ],
    STORE  =3D> 'Session',
    LOGOUT_RUNMODE =3D> 'start',
);

sub setup {
    my $self =3D shift;
    $self->tmpl_path('./');
    $self->auth->protected_runmodes('protected');
}

sub start : StartRunmode {
    my $self =3D shift;
    my $session =3D $self->session;
    my $template =3D $self->load_tmpl('start.tmpl');
    $template->param(
        id =3D> $session->id,
        new_session =3D> $session->is_new
    );
    return $template->output;
}

sub protected : Runmode {
    my $self =3D shift;
    my $session =3D $self->session;
    my $auth =3D $self->auth;
    my $template =3D $self->load_tmpl('protected.tmpl');
    $template->param(
        id =3D> $session->id,
        username =3D> $auth->username,
    );
    return $template->output;
}

1;

--------------------------------------
start.tmpl
--------------------------------------
<html>
<body>
<h2>Start page</h2>

<p>Session ID: <TMPL_VAR id></p>
<p>New Session: <TMPL_IF new_session>Yes<TMPL_ELSE>No</TMPL_IF></p>
<p><a href=3D"?rm=3Dprotected">View Protected Page</a></p>
</body>
</html>

--------------------------------------
protected.tmpl
--------------------------------------
<html>
<body>
<h2>Protected page</h2>

<p>Session ID: <TMPL_VAR id></p>
<p>Username: <TMPL_VAR username></p>
<p><a href=3D"?rm=3Dstart">View Start Page</a></p>
<p><a href=3D"?auth_logout=3D1">Logout</a></p>
</body>
</html>

There are lots of other things you can do to simplify things (for
example using template page headers), and also I would personally use
Template Toolkit, but this should be a good showcase of some of the
things that can be done with CGI::Application.

Cheers,

Cees

RE: [Cgi-session-user] CGI::Session does not seem to be working for me

From: Sherzod R. <she...@ha...> - 2005-09-13 01:11:36

Vahid

Try the following short script to test. If everything goes well, you =
should
see a persistent session id, and a counter which should increment each =
time
the page is revisited or refreshed (see
http://author.handalak.com/cgi-bin/session ). If it doesn't, there =
really is
a problem and we'll work on it.

P.S. You would discover this eventually, but you should look into
CGI::Application and HTML::Template (Or Template Toolkit). The way =
you're
doing things right now (with if/else, and embedded 'HTML'), you can only =
go
so far.


#!/usr/bin/perl -w

use strict;
use CGI;
use CGI::Carp ('fatalsToBrowser');
use CGI::Session;

my $query =3D CGI->new();
my $session =3D CGI::Session->new(undef, undef, {Directory=3D>'/tmp'});
my $counter =3D $session->param('counter') || 0;
$session->param('counter', ++$counter);

my $cookie =3D $query->cookie(-name=3D>$session->name, =
-value=3D>$session->id,
-expires=3D>"+1h");
print $query->header(-cookie=3D>$cookie),
        $query->start_html("CGI::Session - " . $session->VERSION),
        $query->h1("Testing CGI::Session " . $session->VERSION),
        $query->h2($session->name . " : " . $session->id),
        $query->h3("Counter: $counter"),
        $query->end_html();

If it works, there's a problem with your code.



> -----Original Message-----
> From: cgi...@li...=20
> [mailto:cgi...@li...] On=20
> Behalf Of Vahid Hedayati
> Sent: Monday, September 12, 2005 11:26 AM
> To: cgi...@li...
> Subject: [Cgi-session-user] CGI::Session does not seem to be=20
> working for me
> Importance: High
>=20
>=20
> CGI::Session  version (3) /  Perl v.5.8.6  :  on FreeBSD 4.7
>=20
> I have been trying for many hours to get CGI::Session to work:
>=20
> Here is my outcome after many hours of online searching testing:
>=20
> Trying to run a cgi script which authenticates after step 1 and then=20
> runs specfic actions once authenticated..
>=20
> Here is the web results:
>=20
>=20
> _____+++++++
> Original Session ID is
> ++++
>=20
> Welcome vahid you are now logged in
>=20
> Global username =3D vahid ::: 8d257f413fab17680ea94a176b3d71a6Clik me=20
> <http://logmgr/cgi-bin/Provision2.cgi?act=3Dvf>
>=20
> __________________Once clicked shows no STORED Session ID =20
> and no global=20
> username at the bottom has a new SESSION ID:  -->
>=20
> ___+++++++
> Original Session ID is
> ++++
> Global username =3D ::: 6afdaa81cb7c88dc195e1aaab41adf59Clik me=20
> <http://logmgr/cgi-bin/Provision2.cgi?act=3Dvf>
>=20
>=20
> Basically what ever i have tried i end up with new session ids..
>=20
>=20
> here is the code:
>=20
>=20
> This is the top of the script:
>=20
>=20
>=20
> if ($act eq '' ) {
>   $cg =3D new CGI;
>   $session =3D new CGI::Session(undef,undef,{Directory=3D>"/tmp/"});
>   $cookie =3D $cg->cookie(CGISESSID =3D> $session->id);
>   print $cg->header( -cookie=3D>$cookie );
>   $sid=3D$session->id;
>   print "Session ID is $sid<br>";
>   &startup();
> } else {
>   $cg =3D new CGI;
>   $sid=3D$cg->cookie("CGISESSID");
>   print "_____$sid+++++++<br>";
>   $session =3D new CGI::Session(undef,$sid,{Directory=3D>"/tmp/"});
>   print "Original Session ID is $sid<br>";
>   $sid =3D $session->id();
>   print "++++$sid_____<br>";
>   &$act;
> }
>=20
> sub startup {
>=20
>  $value=3D"logon2.htm";
>  &do($value);
> }
>=20
>=20
>=20
> sub login {
>  $username=3D$cgi->param(username);
>  $pass=3D$cgi->param(pass);
>  if (($pass eq '') || ($username eq '' ) ) {
>    print "<hr size=3D3 width=3D100%>";
>    print "Missing Fields please hit back and try again - =20
> process halted";
>    print "<hr size=3D3 width=3D100%>";
>  } else {
>    my $result =3D $ldap->bind("uid=3D$username,$base", =
password=3D>$pass);
>    if($result->is_error()){
>      my $errorMessage =3D $result->error();
>      print "$errorMessage";
>    } else {
>      $session->param( "user_name","$username" );
>      print "<p class=3Dtd align=3Dcenter>Welcome $username you are now =

> logged in</p>";
>      &vf;
>     # print=20
> "<script>\nwindow.location.replace(\"/cgi-bin/$formname?act=3Dvf
> \");\n</script>";
>    }
>  }
> }
>=20
> sub vf {
>   #$gname=3D cookie($gusername);
>   $gname =3D $session->param("user_name");
>=20
>    print "Global username =3D  $gname  ::: $sid";
>   print "<a href=3D/cgi-bin/Provision2.cgi?act=3Dvf>Clik me</a>";
> }
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development=20
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *=20
> Testing & QA
> Security * Process Improvement & Measurement *=20
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>=20
>=20

RE: [Cgi-session-user] (Doc)bug 4.0.2: Automagic flushing

From: Charles B. <ba...@ne...> - 2005-09-12 17:34:56

--On September 12, 2005 1:35:53 AM -0400 Sherzod Ruzmetov 
<she...@ha...> wrote:

> Charles
>
> At first it sounded like you were answering my question on why flush isn't
> autoflusing sometimes, but I kind of lost you somewhere in the middle.
>
>> since the order of global destruction is undefined, it's
>> possible that
>> sub-objects held in the session object will be destroyed
>> before the session
>> itself, so by the time the the call to CGI::Session::flush()
>> is made, the
>> driver may not be defined.
>
> Would you be able to re-create this case in a test script? Since
> sub-objects are held as CGI::Session's attributes, won't they be
> collected AFTER session object is destroyed?

Sorry; I think I was a little too concise.

Perl's (current) global destruction phase differs from the usual GC 
mechanism in that it doesn't track references or otherwise try to sort out 
relationships among SVs; it just wades in and starts freeing them up.  That 
means sub-objects may be destroyed before their parents, etc.

This isn't usually a problem -- after all, it's global destruction, so 
presumably nobody wants the data anymore.  However, objects' DESTROY 
methods are called before the object is deallocated, and may want the data 
for just a little bit longer.  DESTROY is guaranteed that simple scalars in 
the object will be around (specifically, objects are cleaned up before 
non-blessed refs), but sub-objects may have already been dumped, leaving 
behind an C<undef>.

To avoid this, one either has to insure that objects are undefined (go out 
of scope, are C<undef>d, or the like) before global destruction, or the 
DESTROY method must test for the existence of each sub-object, and recover 
appropriately if it's "mysteriously" disappeared.  The first option is more 
common -- it's free if one follows the recommended practice of using 
lexicals/strict for most purposes, since the lexicals will go out of scope 
before global destruction starts.  One can also used END blocks or other 
cleanup handlers to free up objects that need to be global.

As far as reproducing the problem, here's a short script that demonstrates 
the basic issue:

    #!/usr/local/bin/perl -W
    use Data::Dumper;
    $foo = bless {NAME => 'globifoo'}, 'Foo';
    $bar = bless {NAME => 'globibar'}, 'Bar';
    $bar->{Foo} = $foo;
    my $mfoo = bless { NAME => 'lexifoo' }, 'Foo';
    my $mbar = bless { NAME => 'lexibar' }, 'Bar';
    $mbar->{Foo} = $mfoo;
    sub Bar::DESTROY {
        print Data::Dumper->Dump([ $_[0] ], [ $_[0]->{NAME} ]);
    }

The tough thing is that, since global destruction is "unordered", it's 
often a heisenbug.  For instance, if one moves the definition of 
Bar::DESTROY up in the test script, the problem resolves (on my machine 
using 5.9.2; YMMV).

For CGI::Session, the following does it for me:

    #!/usr/local/bin/perl -W
    use CGI::Session;
    $sess = new CGI::Session;
    print "Session id is", $sess->id;

No session data is saved to disk, and the "(in cleanup) Can't call method 
"store" on undefined value" warning is generated.

> So far few people complained about session not being automatically
> flushed, but no one was able to recreate the problem in a test script.

I'm not sure whether they're seeing this problem, but it'd be on the list 
of suspects if they're using globals and relying on automagic flushing. 
Turning on warnings and seeing something like the above in the error log, 
or resolution of the problem when a cleanup handler is added would help to 
confirm the source of trouble.

I hope this helps.

--
Regards,
Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
Newman Center at the University of Pennsylvania

[Cgi-session-user] CGI::Session does not seem to be working for me

From: Vahid H. <vah...@bu...> - 2005-09-12 15:26:14

CGI::Session  version (3) /  Perl v.5.8.6  :  on FreeBSD 4.7

I have been trying for many hours to get CGI::Session to work:

Here is my outcome after many hours of online searching testing:

Trying to run a cgi script which authenticates after step 1 and then 
runs specfic actions once authenticated..

Here is the web results:


_____+++++++
Original Session ID is
++++

Welcome vahid you are now logged in

Global username = vahid ::: 8d257f413fab17680ea94a176b3d71a6Clik me 
<http://logmgr/cgi-bin/Provision2.cgi?act=vf>

__________________Once clicked shows no STORED Session ID  and no global 
username at the bottom has a new SESSION ID:  -->

___+++++++
Original Session ID is
++++
Global username = ::: 6afdaa81cb7c88dc195e1aaab41adf59Clik me 
<http://logmgr/cgi-bin/Provision2.cgi?act=vf>


Basically what ever i have tried i end up with new session ids..


here is the code:


This is the top of the script:



if ($act eq '' ) {
  $cg = new CGI;
  $session = new CGI::Session(undef,undef,{Directory=>"/tmp/"});
  $cookie = $cg->cookie(CGISESSID => $session->id);
  print $cg->header( -cookie=>$cookie );
  $sid=$session->id;
  print "Session ID is $sid<br>";
  &startup();
} else {
  $cg = new CGI;
  $sid=$cg->cookie("CGISESSID");
  print "_____$sid+++++++<br>";
  $session = new CGI::Session(undef,$sid,{Directory=>"/tmp/"});
  print "Original Session ID is $sid<br>";
  $sid = $session->id();
  print "++++$sid_____<br>";
  &$act;
}

sub startup {

 $value="logon2.htm";
 &do($value);
}



sub login {
 $username=$cgi->param(username);
 $pass=$cgi->param(pass);
 if (($pass eq '') || ($username eq '' ) ) {
   print "<hr size=3 width=100%>";
   print "Missing Fields please hit back and try again -  process halted";
   print "<hr size=3 width=100%>";
 } else {
   my $result = $ldap->bind("uid=$username,$base", password=>$pass);
   if($result->is_error()){
     my $errorMessage = $result->error();
     print "$errorMessage";
   } else {
     $session->param( "user_name","$username" );
     print "<p class=td align=center>Welcome $username you are now 
logged in</p>";
     &vf;
    # print 
"<script>\nwindow.location.replace(\"/cgi-bin/$formname?act=vf\");\n</script>";
   }
 }
}

sub vf {
  #$gname= cookie($gusername);
  $gname = $session->param("user_name");

   print "Global username =  $gname  ::: $sid";
  print "<a href=/cgi-bin/Provision2.cgi?act=vf>Clik me</a>";
}

RE: [Cgi-session-user] (Doc)bug 4.0.2: Automagic flushing

From: Sherzod R. <she...@ha...> - 2005-09-12 05:35:56

Charles

At first it sounded like you were answering my question on why flush =
isn't
autoflusing sometimes, but I kind of lost you somewhere in the middle.

> since the order of global destruction is undefined, it's=20
> possible that=20
> sub-objects held in the session object will be destroyed=20
> before the session=20
> itself, so by the time the the call to CGI::Session::flush()=20
> is made, the=20
> driver may not be defined.

Would you be able to re-create this case in a test script? Since =
sub-objects
are held as CGI::Session's attributes, won't they be collected AFTER =
session
object is destroyed?

So far few people complained about session not being automatically =
flushed,
but no one was able to recreate the problem in a test script.

-- =20
Sherzod

[Cgi-session-user] (Doc)bug 4.0.2: Automagic flushing

From: Charles B. <ba...@ne...> - 2005-09-11 15:42:56

A quick note on 4.02 --  the pod (down in C<flush()>) currently states:

    Synchronizes data in the buffer with its copy in disk.
    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.

The first case "just before the program terminates" can get one in trouble: 
since the order of global destruction is undefined, it's possible that 
sub-objects held in the session object will be destroyed before the session 
itself, so by the time the the call to CGI::Session::flush() is made, the 
driver may not be defined.

If the application uses lexical var to store the session object, I think 
all will be well, since it'll typically go out of scope before global 
destruction starts.  (I'm not sure about flie-scope lexicals, but my guess 
-- without testing -- is that they'll go away, too, when a notional 
"file-wide" scope is exited.)  However, if the session is stored in a 
global, the coder needs to explicitly C<undef> it or C<flush> it, or risk 
mysterious/inconsistent failures to write session data.  (I just tripped 
over this in TWiki's SessionPlugin, so I know at least one instance exists 
in the wild. :-))

The simplest fix would be to add a note to the docs reminding the user to 
clear the session object before the program terminates.  If you wanted to 
make things "just work" for the global case, you might also consider more 
complex tricks:

  - keep track (via weak refs) of all instantiated CGI::Sessions, and
    add an END block to flush 'em.  Of course, there's no guarantee
    about order of execution relative to the user's END blocks, in
    which they might manipulate the session, but I suspect these
    collisions are  more rare than global destruction failures.

  - Keep a non-object reference to all of the sub-objects in the
    $session, and recreate/work around missing sub-objects in
    flush() as needed.  (It looks like a minimum solution would be
    to carry around a serialized version of the $session and recreate
    the driver to store it.)  This should be possible with current
    Perls, but strikes me as pretty complicated, and prone to future
    breakage, given the need to maintain the "compensation" code, and
    the reliance on Perl's ability (always true thus far but not
    guaranteed, afaik) ability to construct new objects during
    global destruction.

I'm happy to contribute a patch if it'd help; just let me know wheter it 
should be a doc fix or a shot at magic.

--
Regards,
Charles Bailey  < bailey _at_ newman _dot_ upenn _dot_ edu >
Newman Center at the University of Pennsylvania

Re: [Cgi-session-user] RE: Session not saving data files

From: K.G. W. <kg...@se...> - 2005-09-09 21:11:52

Matt,
I just want to say that since 3.95 works fine for me I'm not pressed to =
get to 4,02.=20
I can try running things next week.=20
I'm gone from the office.
-
KG
-
KG Woltz
SEWP Web Master
301-614-7120
BB 240-304-5451
--------- WWW.SEWP.NASA.GOV --------

Sent from my BlackBerry Wireless Handheld (www.BlackBerry.net)


-----Original Message-----
From: cgi...@li... =
<cgi...@li...>
To: cgi...@li... =
<cgi...@li...>
Sent: Fri Sep 09 16:59:55 2005
Subject: [Cgi-session-user] RE: Session not saving data files

KG,

Can you try the following one-liner and tell me if it succeeds?

# following writes "hello" to a file in pwd called f.tmp
perl -MFcntl=3D:DEFAULT,:flock,:mode =
-le'sysopen(FH,"f.tmp",O_WRONLY|O_CREAT) or die $!;flock(FH,LOCK_EX)or =
die $!;truncate(FH,0) or die $!;print FH "hello";close FH' && cat f.tmp =
&& rm f.tmp

And just for debugging information, please try the following script:

#!/usr/bin/perl -w
use File::Spec;
use Test::More qw/no_plan/;
   =20
use CGI::Session;

if (CGI::Session->VERSION >=3D 4) {
    *CGI::Session::DESTROY =3D sub {=20
                                    my $s =3D shift;
                                    $s->flush() or die "Flush seems to =
have failed: ".$s->errstr;
                                 };
}

my $dir =3D File::Spec->catdir('t', 'sessiondata');
my $id;
my $ses =3D CGI::Session->new(undef,undef,{Directory=3D> $dir });
$id =3D $ses->id();
ok($id, "found session id");
END { ok(-r "$dir/cgisess_".$id, "found session data file"); }

If you want to test it against 4.02 without reinstalling it, download =
CGI-Session 4.02 =
<http://search.cpan.org/CPAN/authors/id/S/SH/SHERZODR/CGI-Session-4.02.ta=
r.gz> , unpack it in the pwd and run with:=20
perl -ICGI-Session-4.02/lib script.pl

Thanks,
Matt LeBlanc=20

[Cgi-session-user] RE: Session not saving data files

From: Matt L. <mle...@cp...> - 2005-09-09 21:01:05

KG,

Can you try the following one-liner and tell me if it succeeds?

# following writes "hello" to a file in pwd called f.tmp
perl -MFcntl=:DEFAULT,:flock,:mode 
-le'sysopen(FH,"f.tmp",O_WRONLY|O_CREAT) or die $!;flock(FH,LOCK_EX)or 
die $!;truncate(FH,0) or die $!;print FH "hello";close FH' && cat f.tmp 
&& rm f.tmp

And just for debugging information, please try the following script:

#!/usr/bin/perl -w
use File::Spec;
use Test::More qw/no_plan/;
   
use CGI::Session;

if (CGI::Session->VERSION >= 4) {
    *CGI::Session::DESTROY = sub {
                                    my $s = shift;
                                    $s->flush() or die "Flush seems to 
have failed: ".$s->errstr;
                                 };
}

my $dir = File::Spec->catdir('t', 'sessiondata');
my $id;
my $ses = CGI::Session->new(undef,undef,{Directory=> $dir });
$id = $ses->id();
ok($id, "found session id");
END { ok(-r "$dir/cgisess_".$id, "found session data file"); }

If you want to test it against 4.02 without reinstalling it, download 
CGI-Session 4.02 
<http://search.cpan.org/CPAN/authors/id/S/SH/SHERZODR/CGI-Session-4.02.tar.gz>, 
unpack it in the pwd and run with:
perl -ICGI-Session-4.02/lib script.pl

Thanks,
Matt LeBlanc

Re: [Cgi-session-user] Session not saving data files

From: Mark S. <ma...@su...> - 2005-09-08 17:43:01

On Thu, Sep 08, 2005 at 01:13:30PM -0400, K.G. Woltz wrote:
> OK I had the UNIX guy roll-back to CGI::Session 3.95.
> It works now.
> I can try the different things mentioned last night if I go back up to
> 4.x.
> 
> But I'm wondering .....
> ... was there a good reason for making changes that require me to "ADD
> MORE code" to my script?
> What am I missing here?

KG,

As I mentioned in my response last night, I believe you are missing that
CGI::Session was not the only thing you upgraded.

The test script I provided failed with both 3.95 and 4.02, indicating
that either the reduction of your test case or mine was inaccurate, or
something else such as the Perl upgrade made a difference.

If you feel there is a bug in CGI::Session, you are welcome to provide a
Test::More test script and/or a patch to further illustrate it.

    Mark

RE: [Cgi-session-user] Session not saving data files

From: K.G. W. <kg...@se...> - 2005-09-08 17:14:46

OK I had the UNIX guy roll-back to CGI::Session 3.95.
It works now.
I can try the different things mentioned last night if I go back up to
4.x.

But I'm wondering .....
... was there a good reason for making changes that require me to "ADD
MORE code" to my script?
What am I missing here?
Thanks,
-=20
KG
 -----Original Message-----
From: cgi...@li...
[mailto:cgi...@li...] On Behalf Of K.G.
Woltz
Sent: Wednesday, September 07, 2005 4:01 PM
To: cgi...@li...
Subject: [Cgi-session-user] Session not saving data files

I was using CGI::Session 3.95 last week and the UNIX(Sun Solaris) folks
rolled out a new server and installed CGI::Session 4.02.
Also the Perl version was 5.8.2 and now it's 5.6.1.
Now when I use my CGI app the session data isn't saving in the dir I
told it to.
I tried removing the dir and the app rebuilds the dir but no data files.
Anyone know why I'm not saving the data?
Here is my Perl:
$sid =3D $query->cookie("MySesId") || undef;
$session =3D new CGI::Session(undef, $sid,
{Directory=3D>"$server_path/cgi-bin/session/"}) or die
CGI::Session->errstr;

-=20
KG=20



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Cgi-session-user mailing list
Cgi...@li...
https://lists.sourceforge.net/lists/listinfo/cgi-session-user

Re: [Cgi-session-user] Session not saving data files (a final answer?)

From: Mark S. <ma...@su...> - 2005-09-08 01:23:43

On Wed, Sep 07, 2005 at 05:49:22PM -0400, K.G. Woltz wrote:
> Mark,
> Yes it was working before the UNIX server was rebuilt.
> The files were written to the dir specified.
> I don't know when, during or after, it doesn't matter to the script.
> The files need to be there for the next call to the CGI.

I checked on this with the following test. This is the same as t/flush.t in the distribution,
except I've commented out the braces to make it identical to your case.

   use File::Spec;
   use Test::More qw/no_plan/;
   use strict;

   use CGI::Session;
   my $dir = File::Spec->catdir('t', 'sessiondata');
   my $id;
   #{
       my $ses = CGI::Session->new(undef,undef,{Directory=> $dir });
       $id = $ses->id();
       ok($id, "found session id");
   #}

   ok(-r "$dir/cgisess_".$id, "found session data file");

It fails with 3.95 and 4.02 with Perl 5.8.6.

Thus, I suspect it was your Perl upgrade or another factor that caused the
change in behavior.

If you want, try downgrading CGI::Session to 3.95 and see if that works
for you. ( Based on my test above, it shouldn't ).  

    Mark

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

RE: [Cgi-session-user] Session not saving data files

From: Sherzod R. <she...@ha...> - 2005-09-08 00:25:09

Directories are created at driver's init() stage, but sessions are written
at session's DESTROY() stage. Could you try adding:

	$session->flush();

at the end of your program and see if that changes anything? Some errors
generated during DESTROY() may not be noticed in the interface of your
program, but in your server's error logs. Check them.

Are you running under mod_perl or similar environment? If so, failing to
declare variables without my() creates global variables, that do not get
destroyed within the scope of your program. In this case calling flush() is
the only way to make sessions persist (or declaring them with my()).

Are your programs running as a designated user? Try to "su" to that user,
"cd" into the directory where you're expecting sessions written into, and
try to "touch":

	% touch works-fine

Please let us know about your findings.

--  
Sherzod Ruzmetov





> -----Original Message-----
> From: cgi...@li... 
> [mailto:cgi...@li...] On 
> Behalf Of K.G. Woltz
> Sent: Wednesday, September 07, 2005 5:49 PM
> To: cgi...@li...
> Subject: RE: [Cgi-session-user] Session not saving data files
> Importance: High
> 
> 
> Mark,
> Yes it was working before the UNIX server was rebuilt.
> The files were written to the dir specified.
> I don't know when, during or after, it doesn't matter to the script.
> The files need to be there for the next call to the CGI.
> 
> -
> KG
> -----Original Message-----
> From: Mark Stosberg [mailto:ma...@su...] 
> Sent: Wednesday, September 07, 2005 4:48 PM
> To: K.G. Woltz
> Cc: cgi...@li...
> Subject: Re: [Cgi-session-user] Session not saving data files
> 
> On Wed, Sep 07, 2005 at 04:00:38PM -0400, K.G. Woltz wrote:
> > I was using CGI::Session 3.95 last week and the UNIX(Sun Solaris)
> folks
> > rolled out a new server and installed CGI::Session 4.02.
> > Also the Perl version was 5.8.2 and now it's 5.6.1.
> > Now when I use my CGI app the session data isn't saving in the dir I
> > told it to.
> > I tried removing the dir and the app rebuilds the dir but no data
> files.
> > Anyone know why I'm not saving the data?
> > Here is my Perl:
> >
> > $sid = $query->cookie("MySesId") || undef;
> > $session = new CGI::Session(undef, $sid,
> > {Directory=>"$server_path/cgi-bin/session/"}) or die
> > CGI::Session->errstr;
> 
> KG,
> 
> I'm sorry we broke NASA.
> 
> I think I understand the issue, but I would like opinions from other
> developers about what do about it.
> 
> Files are written when the session is explicitly flushed or closed, or
> automatically when the object goes out of scope.
> 
> In your example, I'm not sure either happens before the end of the
> script. 
> 
> I suspect this would work for you: 
> 
> # Braces establish scope
> {
>  $sid = $query->cookie("MySesId") || undef;
>  $session = new CGI::Session(undef, $sid,
>  {Directory=>"$server_path/cgi-bin/session/"}) or die
> CGI::Session->errstr;
> }
> 
> Are you saying your application broke after the upgrade, because
> CGI::Session 3.95 was automatically flushing your session to disk with
> your
> example code, but 4.02 isn't? 
> 
>     Mark
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development 
> Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * 
> Testing & QA
> Security * Process Improvement & Measurement * 
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
> 
>

RE: [Cgi-session-user] Session not saving data files

From: K.G. W. <kg...@se...> - 2005-09-07 21:50:24

Mark,
Yes it was working before the UNIX server was rebuilt.
The files were written to the dir specified.
I don't know when, during or after, it doesn't matter to the script.
The files need to be there for the next call to the CGI.

-
KG
-----Original Message-----
From: Mark Stosberg [mailto:ma...@su...]=20
Sent: Wednesday, September 07, 2005 4:48 PM
To: K.G. Woltz
Cc: cgi...@li...
Subject: Re: [Cgi-session-user] Session not saving data files

On Wed, Sep 07, 2005 at 04:00:38PM -0400, K.G. Woltz wrote:
> I was using CGI::Session 3.95 last week and the UNIX(Sun Solaris)
folks
> rolled out a new server and installed CGI::Session 4.02.
> Also the Perl version was 5.8.2 and now it's 5.6.1.
> Now when I use my CGI app the session data isn't saving in the dir I
> told it to.
> I tried removing the dir and the app rebuilds the dir but no data
files.
> Anyone know why I'm not saving the data?
> Here is my Perl:
>
> $sid =3D $query->cookie("MySesId") || undef;
> $session =3D new CGI::Session(undef, $sid,
> {Directory=3D>"$server_path/cgi-bin/session/"}) or die
> CGI::Session->errstr;

KG,

I'm sorry we broke NASA.

I think I understand the issue, but I would like opinions from other
developers about what do about it.

Files are written when the session is explicitly flushed or closed, or
automatically when the object goes out of scope.

In your example, I'm not sure either happens before the end of the
script.=20

I suspect this would work for you:=20

# Braces establish scope
{
 $sid =3D $query->cookie("MySesId") || undef;
 $session =3D new CGI::Session(undef, $sid,
 {Directory=3D>"$server_path/cgi-bin/session/"}) or die
CGI::Session->errstr;
}

Are you saying your application broke after the upgrade, because
CGI::Session 3.95 was automatically flushing your session to disk with
your
example code, but 4.02 isn't?=20

    Mark

RE: [Cgi-session-user] Session not saving data files

From: K.G. W. <kg...@se...> - 2005-09-07 21:03:25

Jason,
As stated below I let the script create the dir and it still didn't
write the files.
Yes the dir has write attributes.
-
KG

-----Original Message-----
From: Jason A. Crome [mailto:pe...@cr...]=20
Sent: Wednesday, September 07, 2005 4:24 PM
To: K.G. Woltz
Cc: cgi...@li...
Subject: Re: [Cgi-session-user] Session not saving data files

If I had to guess, I would say that $server_path/cgi-bin/session is =20
not writable by the web server.  Have you checked the permissions of =20
that directory to ensure that the webserver can write to it?

Jason

Re: [Cgi-session-user] Session not saving data files

From: Mark S. <ma...@su...> - 2005-09-07 20:48:32

On Wed, Sep 07, 2005 at 04:00:38PM -0400, K.G. Woltz wrote:
> I was using CGI::Session 3.95 last week and the UNIX(Sun Solaris) folks
> rolled out a new server and installed CGI::Session 4.02.
> Also the Perl version was 5.8.2 and now it's 5.6.1.
> Now when I use my CGI app the session data isn't saving in the dir I
> told it to.
> I tried removing the dir and the app rebuilds the dir but no data files.
> Anyone know why I'm not saving the data?
> Here is my Perl:
>
> $sid = $query->cookie("MySesId") || undef;
> $session = new CGI::Session(undef, $sid,
> {Directory=>"$server_path/cgi-bin/session/"}) or die
> CGI::Session->errstr;

KG,

I'm sorry we broke NASA.

I think I understand the issue, but I would like opinions from other
developers about what do about it.

Files are written when the session is explicitly flushed or closed, or
automatically when the object goes out of scope.

In your example, I'm not sure either happens before the end of the
script. 

I suspect this would work for you: 

# Braces establish scope
{
 $sid = $query->cookie("MySesId") || undef;
 $session = new CGI::Session(undef, $sid,
 {Directory=>"$server_path/cgi-bin/session/"}) or die CGI::Session->errstr;
}

Are you saying your application broke after the upgrade, because
CGI::Session 3.95 was automatically flushing your session to disk with your
example code, but 4.02 isn't? 

    Mark

[Cgi-session-user] Session not saving data files

From: K.G. W. <kg...@se...> - 2005-09-07 20:01:42

I was using CGI::Session 3.95 last week and the UNIX(Sun Solaris) folks
rolled out a new server and installed CGI::Session 4.02.
Also the Perl version was 5.8.2 and now it's 5.6.1.
Now when I use my CGI app the session data isn't saving in the dir I
told it to.
I tried removing the dir and the app rebuilds the dir but no data files.
Anyone know why I'm not saving the data?
Here is my Perl:
$sid =3D $query->cookie("MySesId") || undef;
$session =3D new CGI::Session(undef, $sid,
{Directory=3D>"$server_path/cgi-bin/session/"}) or die
CGI::Session->errstr;

-=20
KG=20

Re: [Cgi-session-user] CGI::Session driver:File - tainted session data?

From: Thomas L. S. <tsh...@io...> - 2005-09-06 07:14:08

Whoa, talk about deja-vu!  See "CGI::Session, taint mode, and tainted session file input data"  http://www.perlmonks.com/?node_id=451074
where I discovered this problem the 'first' time, and described it much better.  And I did as suggested, which was to switch to using a database for storage, and promptly forgot all about the problem!

Anyway, got my module for Catalyst together, http://search.cpan.org/~tshinnic/Catalyst-Plugin-Session-CGISession-0.02/, with a note about tainted data with 'File' driver.  ;)


At 17:36 9/4/2005, Mark Stosberg wrote:
>On Sat, Sep 03, 2005 at 11:52:50PM -0500, Thomas L. Shinnick wrote:
>
>> I am having problems with tainted session data, using CGI::Session 3.95 and "driver:File".  I am putting together another session module for Catalyst, and want to verify that it works under 3.95 before installing 4.0x.
>> 
>> Using "driver:MySQL" I have no problems.  After switching the DSN to "driver:File" I blow up the first time I try to use a value from retrieved session data in a 'sensitive' way.  Note that this is the same code - I'm only changing the DSN. 
>> 
>> So I'm left to wonder:
>>   - is session data from 3.95 File always tainted?
>>   - is session data from 3.95 MySQL _not_ tainted?
>
>For definitive answer, I would check the source of those driver modules. 
>
>>   - and will 4.0x act any differently?
>
>Generally, if it does act differently it's a bug, unless something
>managed to be badly broken all along. 
>
>>   - is there a 'nice' way to untaint a whole session data ref?
>
>My opinion is "No". From 'perldoc perlsec': 
>
>"don't just blindly untaint anything, or you defeat the entire mechanism".
>
>My approach is to not use "-T", and handle data that would be tainted
>carefully. Too often I see solutions that /do/ blindly untaint things,
>defeating the point of it. 
>
>Even the current CGI::Session source for the default driver does this:
>
> # blindly untaint...
> my ($safe_string) = $string =~ m/^(.*)$/s;
>
>It allows you to say "look, I'm using taint mode!", but it not actually
>performing any checks on the data before considering it safe.
>
>Now at this point, I imagine we would break backwards compatibility if
>this behavior changed. 
>
>    Mark
>
>-- 
>http://mark.stosberg.com/

Re: [Cgi-session-user] CGI::Session driver:File - tainted session data?

From: Mark S. <ma...@su...> - 2005-09-04 22:37:09

On Sat, Sep 03, 2005 at 11:52:50PM -0500, Thomas L. Shinnick wrote:

> I am having problems with tainted session data, using CGI::Session 3.95 and "driver:File".  I am putting together another session module for Catalyst, and want to verify that it works under 3.95 before installing 4.0x.
> 
> Using "driver:MySQL" I have no problems.  After switching the DSN to "driver:File" I blow up the first time I try to use a value from retrieved session data in a 'sensitive' way.  Note that this is the same code - I'm only changing the DSN. 
> 
> So I'm left to wonder:
>   - is session data from 3.95 File always tainted?
>   - is session data from 3.95 MySQL _not_ tainted?

For definitive answer, I would check the source of those driver modules. 

>   - and will 4.0x act any differently?

Generally, if it does act differently it's a bug, unless something
managed to be badly broken all along. 

>   - is there a 'nice' way to untaint a whole session data ref?

My opinion is "No". From 'perldoc perlsec': 

"don't just blindly untaint anything, or you defeat the entire mechanism".

My approach is to not use "-T", and handle data that would be tainted
carefully. Too often I see solutions that /do/ blindly untaint things,
defeating the point of it. 

Even the current CGI::Session source for the default driver does this:

 # blindly untaint...
 my ($safe_string) = $string =~ m/^(.*)$/s;

It allows you to say "look, I'm using taint mode!", but it not actually
performing any checks on the data before considering it safe.

Now at this point, I imagine we would break backwards compatibility if
this behavior changed. 

    Mark

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

[Cgi-session-user] CGI::Session driver:File - tainted session data?

From: Thomas L. S. <tsh...@io...> - 2005-09-04 04:53:20

I am having problems with tainted session data, using CGI::Session 3.95 and "driver:File".  I am putting together another session module for Catalyst, and want to verify that it works under 3.95 before installing 4.0x.

Using "driver:MySQL" I have no problems.  After switching the DSN to "driver:File" I blow up the first time I try to use a value from retrieved session data in a 'sensitive' way.  Note that this is the same code - I'm only changing the DSN. 

So I'm left to wonder:
  - is session data from 3.95 File always tainted?
  - is session data from 3.95 MySQL _not_ tainted?
  - is there a 'nice' way to untaint a whole session data ref?
  - and will 4.0x act any differently?

Other details you might ask are: DBI 1.46, DBD::mysql 2.9004, MySQL 3.23.54, Redhat Linux 7.2 (yes, I hang on to old things ;)



-- 
I'm a pessimist about probabilities; I'm an optimist about possibilities.
    Lewis Mumford  (1895-1990)

RE: [Cgi-session-user] Re: Fwd: CGI::Session::Serialize::default (committed)

From: Sherzod R. <she...@ha...> - 2005-09-03 01:32:53

> Matt explained the related patch on IRC tonight, and I committed it on
> his behalf.

You did it, Matt! Great job.

--  
Sherzod

[Cgi-session-user] Re: Fwd: CGI::Session::Serialize::default (committed)

From: Mark S. <ma...@su...> - 2005-09-03 00:20:45

On Fri, Sep 02, 2005 at 11:07:07AM -0500, Mark Stosberg wrote:
> 
> I doubt this path will be seen as a very good addition to CGI::Session. 
> However, I've written it and here it is.
> 
> This patch allows CGI::Sessions that use default as the serializer to 
> actually store blessed items. If the object is overloaded, no worries. I 
> tried several approaches to get around the fact that the objects were 
> blessed in a Safe compartment. The coding style is...well...not pretty. 
> Anyway, enjoy =P

Matt explained the related patch on IRC tonight, and I committed it on
his behalf.

Now, off to watch the news about Katrina...

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

[Cgi-session-user] Fwd: CGI::Session::Serialize::default

From: Mark S. <ma...@su...> - 2005-09-02 16:19:46

--KDt/GgjP6HVcx58l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Here's a submission that didn't make it into 4.0.

I'm not sure I understand what it is good for. Comments from others are
welcome. 

    Mark

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

Date: Fri, 26 Aug 2005 15:28:55 -0500
From: Matt LeBlanc <mle...@cp...>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
To: Mark Stosberg <mar...@cp...>
Subject: CGI::Session::Serialize::default


----- End forwarded message -----

--KDt/GgjP6HVcx58l
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Disposition: inline

Mark,

I doubt this path will be seen as a very good addition to CGI::Session. 
However, I've written it and here it is.

This patch allows CGI::Sessions that use default as the serializer to 
actually store blessed items. If the object is overloaded, no worries. I 
tried several approaches to get around the fact that the objects were 
blessed in a Safe compartment. The coding style is...well...not pretty. 
Anyway, enjoy =P

Thanks,
Matt LeBlanc

--KDt/GgjP6HVcx58l
Content-Type: text/plain; charset=us-ascii;
	name="cgi-session-serialize-default.pm.diff"
Content-Disposition: inline; filename="cgi-session-serialize-default.pm.diff"

--- default.pm.orig	Fri Aug 26 14:34:37 2005
+++ default.pm	Fri Aug 26 15:22:58 2005
@@ -8,6 +8,8 @@
 use Safe;
 use Data::Dumper;
 use CGI::Session::ErrorHandler;
+use Scalar::Util qw(blessed reftype);
+use Carp "croak";
 
 @CGI::Session::Serialize::default::ISA = qw( CGI::Session::ErrorHandler );
 $CGI::Session::Serialize::default::VERSION = '1.4';
@@ -30,14 +32,53 @@
     my ($class, $string) = @_;
 
     # To make -T happy
-    my ($safe_string) = $string =~ m/^(.*)$/;
-    my $rv = Safe->new()->reval( $safe_string );
+    my ($safe_string) = $string =~ m/^(.*)$/s;
+    my $rv = Safe->new->reval( $safe_string );
     if ( my $errmsg = $@ ) {
         return $class->set_error("thaw(): couldn't thaw. $@");
     }
+    __walk($rv);
     return $rv;
 }
 
+sub __walk {
+    my %seen;
+    my @filter = shift;
+    
+    while (defined(my $x = shift @filter)) {
+        $seen{$x}++ and next;
+          
+        my $r = reftype $x or next;
+        if ($r eq "HASH") {
+            push @filter, __scan(@{$x}{keys %$x});
+        } elsif ($r eq "ARRAY") {
+            push @filter, __scan(@$x);
+        } elsif ($r eq "SCALAR" || $r eq "REF") {
+            push @filter, __scan($$x);
+        }
+    }
+}
+
+sub __scan {
+    for (@_) {
+        if (blessed $_) {
+            if (overload::Overloaded($_)) {
+                my $r = reftype $_;
+                if ($r eq "HASH") {
+                    $_ = bless { %$_ }, ref $_
+                } elsif ($r eq "ARRAY") {
+                    $_ = bless [ @$_ ], ref $_
+                } elsif ($r eq "SCALAR" || $r eq "REF") {
+                    $_ = bless \do{my $o = $$_},ref $_
+                } else {
+                    croak "Do not know how to reconstitute blessed object of base type $r";
+                }
+            } else {
+                bless $_, ref $_
+            }
+        }
+    }
+}
 
 1;
 

--KDt/GgjP6HVcx58l--

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

Re: [Cgi-session-user] Re: [cpan #14414] method remote_addr() was removed in version 4.01

From: root <ro...@s1...> - 2005-09-02 15:04:10

 A patch is welcome (should be easy), or someone else get to this soon.
> 
> We'll also want an automated test to that checks for this as well.
> 

I'm working on it!

142 messages has been excluded from this view by a project administrator.

Flat | Threaded

<< < 1 .. 21 22 23 24 25 .. 29 > >> (Page 23 of 29)