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

Re: [Cgi-session-user] proposed refinements to load() and find() interfaces

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

On Sat, 10 Jun 2006 16:11:38 -0500, Matt LeBlanc wrote:

Hi Matt

> Ok then. find is now changed back to three args (sorry Ron) but
> most of the documentation from Ron's patch remains. I've also
> updated the documentation to show how to create an anonymous sub to
> call a coderef with extra parameters.

It'll be fine with me as long as there is /some sort/ of mechanism whereby 
parameters can be passed to the find and then to the callback, and that's=
 what 
appears to be the case, so release and be damned!

-- 
Cheers
Ron Savage, ro...@sa... on 11/06/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] Updates

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

On Sat, 10 Jun 2006 15:16:53 -0400, Mark Stosberg wrote:

Hi Mark, Matt

Firstly, many thanx for taking my patch on board.

(Matt: I'd had no indication it's been accepted).

I'd prefer the latest docs (now on RT) to be used, even though they are=
 almost 
word-for-word the same, since - for one thing - I corrected an error in the=
 
original (not my previous) example, in calling is_expired() and not=
 expired().

Also the docs refer to load() and perhaps should refer to _load(). Up to=
 you. 
Feel free the patch my patch on this matter.

And yes, there's a nice new test which is definitely worth including. Source=
 is 
on RT.
-- 
Cheers
Ron Savage, ro...@sa... on 11/06/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] proposed refinements to load() and find() interfaces

[Matt L. <mle...@cp...>]

On 6/10/06, *Mark Stosberg* <ma...@su...> wrote:
> Here's another refactor:
>
> 1. Leave things generally alone with load(), but add extra param,
>   for internal use only, just be clearer than load/_load
>
>   load($dsn,$query, \%dsn_args, $update_atime);
>
All right. _load's been ditched and load now accepts a fourth parameter. 
No documentation has been added about the fourth option and should be 
considered for internal use only.
> 2. Leave find() mostly alone as well, and don't add update_atime flag.
>    Back out the coderef_args option patch in favor of documenting how
>    to use a higher order function for this.
>
>   find( $dsn,
>                 inspect( look => 'closely'), # will return a code ref
>         \%dsn_args );
Ok then. find is now changed back to three args (sorry Ron) but most of 
the documentation from Ron's patch remains. I've also updated the 
documentation to show how to create an anonymous sub to call a coderef 
with extra parameters.
> Better?
Yeah, if all tests pass for everyone else, let's release.

-Matt

Re: [Cgi-session-user] Updates

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

On Sat, Jun 10, 2006 at 02:08:51PM -0500, Matt LeBlanc wrote:
> On 6/10/06, *Ron Savage* <ro...@sa...> wrote:
> >
> > Please check RT ticket 16069 for another patch, with docs and a test.
> This has actually been applied since April 15th and will also be 
> available for next release.

I think there is a new "t/find.t" file in the ticket that has not been
applied.  I was waiting to wrap up the conversation on the find()
interface to address that.

	Mark

Re: [Cgi-session-user] proposed refinements to load() and find() interfaces

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

On Sat, Jun 10, 2006 at 01:47:18PM -0500, Matt LeBlanc wrote:
> On 6/10/06, *Mark Stosberg* <ma...@su...> wrote:
> 
>    "load" vs "_load" is not clear.
> 
> load is part of the documented public interface, _load is not. This is a 
> change to internals, nothing else.

I understand. Still, having two names that are nearly identical can be a
sign that something is amiss, and is confusing for those who maintain
the code.

In this case, this difference is basically whether the ATIME gets
updated. 

I'm suggesting keeping one load() routine, and adding a "update_atime"
option, which we could possibly leave undocumented, since as far as we
are aware, it will only be turned off in one place interally, by find(). 

> The point of the change that I'm making is to allow us to inspect the 
> session as the user has left it without changing anything. I strongly 
> feel that the current behavior of find is wrong. find is supposed to 
> manage the sessions as the user has left them.

I like the change to not have find() modify ATIME. 

> I wouldn't mind coding them if I agreed with them =)

Fair enough. I don't mind leaving out the update_atime option to find, 
since you feel strongly about that. 

Here's another refactor:

1. Leave things generally alone with load(), but add extra param,
  for internal use only, just be clearer than load/_load

  load($dsn,$query, \%dsn_args, $update_atime);

2. Leave find() mostly alone as well, and don't add update_atime flag.
   Back out the coderef_args option patch in favor of documenting how
   to use a higher order function for this. 

  find( $dsn,   
		inspect( look => 'closely'), # will return a code ref
        \%dsn_args );

Better?

	Mark	

Re: [Cgi-session-user] Updates

[Matt L. <mle...@cp...>]

On 6/10/06, *Ron Savage* <ro...@sa...> wrote:
>
> Please check RT ticket 16069 for another patch, with docs and a test.
This has actually been applied since April 15th and will also be 
available for next release.

-Matt LeBlanc

Re: [Cgi-session-user] proposed refinements to load() and find() interfaces

[Matt L. <mle...@cp...>]

On 6/10/06, *Mark Stosberg* <ma...@su...> wrote:

    "load" vs "_load" is not clear.


load is part of the documented public interface, _load is not. This is a 
change to internals, nothing else.

    I propose instead the following:

    1. A named-parameters interface for load():

      load(
            dsn      => $dsn,
            dsn_args => \%dsn_args,
            query    => $query,
            update_atime => 1, # defaults to 1
      );

    2. And also a named-parameters interface for find()

    find(
       dsn       => $dsn,
       dsn_args  => \%dsn_args,
       code      => inspect( look => 'closely'),
       update_atime => 0, # defaults to 0 here!
    )

    Notice that "dsn" and "dsn_args" are now together, which is nice. Also
    notice that the "coderef_args" is not needed. Instead, higher order
    functions can used, which have worked well in the Data::FormValidator
    4.0 interface. If coderefs args would be needed, a closure can be
    returned whic provides them. Here's an example what "inspect()" might
    look like:

            sub inspect {
                    my %args = @_;
                    return sub {
                            my $session = shift;
                            my $coderef_args =  \%args;
                            # do something...

                    }
            }


The point of the change that I'm making is to allow us to inspect the 
session as the user has left it without changing anything. I strongly 
feel that the current behavior of find is wrong. find is supposed to 
manage the sessions as the user has left them. If you wish to add 
something to the session, no problem. Call param on the session as you 
normally would and the changes will be made but the access time will 
not. If someone really wants to update the access time, then they can 
either load the session or we can add an update_atime method.

    Matt,

    If you agree with these refactorings, would you mind coding them up?


I wouldn't mind coding them if I agreed with them =)

-Matt

[Cgi-session-user] proposed refinements to load() and find() interfaces

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

Thanks for your work on this Matt.

> 18442 will probably be the one that needs discussion. I have created a 
> _load method that does everything that load does except it doesn't 
> change the access time (off of which expiration is determined) nor does 
> it mark the session as modified. If any parameters are expired, they 
> will not be available in the session. The bugfix alters find to use the 
> new _load instead of load. The bug report informs us that if the cron 
> job runs at an interval less than the expiration time, sessions will 
> never expire. By changing find over to use _load, the user is the only 
> one who changes the access time and thus our sessions will expire 
> because of the user's browsing habits and not our attempts at managing 
> the sessions.

I think there is room for some refinement in this area. 

"load" vs "_load" is not clear. 

Already load() can take up to 3 args, plus now an option to
call "_load()" directly, effectively creating another option.

It's also proposed that find now take 4 args: 

 find( $dsn, \&code, \%dsn_args, \%coderef_args )

I propose instead the following:

1. A named-parameters interface for load():

  load(
  	dsn      => $dsn, 
	dsn_args => \%dsn_args,
	query    => $query, 
	update_atime => 1, # defaults to 1
  );

2. And also a named-parameters interface for find()

 find( 
   dsn       => $dsn, 
   dsn_args  => \%dsn_args,
   code      => inspect( look => 'closely'),
   update_atime => 0, # defaults to 0 here!
 )

Notice that "dsn" and "dsn_args" are now together, which is nice. Also
notice that the "coderef_args" is not needed. Instead, higher order
functions can used, which have worked well in the Data::FormValidator
4.0 interface. If coderefs args would be needed, a closure can be
returned whic provides them. Here's an example what "inspect()" might
look like:  

	sub inspect {
		my %args = @_;
		return sub {
			my $session = shift;
			my $coderef_args =  \%args;
			# do something...

		}
	}

Matt, 

If you agree with these refactorings, would you mind coding them up?

	Mark

Re: [Cgi-session-user] Updates

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

On Sat, 10 Jun 2006 15:12:21 +1000, Ron Savage wrote:

Hi Ron

> Please check RT ticket 16069 for another patch, with docs and a
> test.

I should mention this connects with a thread starting in April 2006:

http://sourceforge.net/mailarchive/message.php?msg_id=3D15407858

-- 
Cheers
Ron Savage, ro...@sa... on 10/06/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

Re: [Cgi-session-user] Updates

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

On Fri, 09 Jun 2006 15:01:21 -0500, Matt LeBlanc wrote:

Hi Matt

> If there are no objections, I recommend a release.

Please check RT ticket 16069 for another patch, with docs and a test.

-- 
Cheers
Ron Savage, ro...@sa... on 10/06/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company

[Cgi-session-user] Updates

[Matt L. <mle...@cp...>]

Dear merry CGI::Session users,

Fixes are currently in SVN to address bugs 18912, 18873, and 18442 (bugs 
listed at http://rt.cpan.org/Public/Dist/Display.html?Name=CGI-Session)

18912 gets fixed by returning $val when called as $s->param($key,$val). 
For the case of $s->param($key,$val,$key2,$val2), it still returns a 
true value.

18873 just does some untainting. I'm somewhat surprised this was never 
an issue for anyone. I guess not many people use taint and set the dsn 
from a config file?

18442 will probably be the one that needs discussion. I have created a 
_load method that does everything that load does except it doesn't 
change the access time (off of which expiration is determined) nor does 
it mark the session as modified. If any parameters are expired, they 
will not be available in the session. The bugfix alters find to use the 
new _load instead of load. The bug report informs us that if the cron 
job runs at an interval less than the expiration time, sessions will 
never expire. By changing find over to use _load, the user is the only 
one who changes the access time and thus our sessions will expire 
because of the user's browsing habits and not our attempts at managing 
the sessions.

If there are no objections, I recommend a release.

Thanks,
Matt LeBlanc

[Cgi-session-user] shelter

[Joanna B. <et...@qu...>]

Trade Date: Tuesday, June 6th, 2006
Company: BioElectronics Corporation
Symbol: BIEL
Price: $0.025

IS MOMENTUM BUILDING FOR THIS STOCK? CAN YOU MAKE SOME FAST MONEY ON IT?
RADAR BIEL FOR TUESDAY'S OPEN RIGHT NOW!!

THE ALERT IS ON!!!

RECENT NEWS HEADLINE: (GO READ ALL THE NEWS ON BIEL RIGHT NOW!)

BioElectronics Corporation Announces New 510(k) Market Clearance Application 
Filed With FDA!!


About BioElectronics Corporation (Source: News 5/18/2006)

BioElectronics currently manufactures and sells ActiPatch(TM), a drug-free 
anti-inflammatory patch with an embedded battery operated microchip that 
delivers weeks of continuous pulsed therapy for less than a dollar a day. 
The unique ActiPatch delivery system, using patented technology, provides 
a cost-effective, patient friendly method to reduce soft tissue pain and 
swelling.


GO READ ALL THE NEWS ON THIS ONE!! DO YOUR DUE DILIGENCE!!
RADAR IT FOR TUESDAY'S OPEN NOW! 


______________



Information within this report contains forward looking statements within 
the meaning of Section 27A of the Securities Act of 1933 and Section 21B 
of the SEC Act of 1934. Statements that involve discussions with respect 
to projections of future events are not statements of historical fact and 
may be  forward looking statements. Don't rely on them to make a decision. 
Past performance is never indicative of future results. We received four 
hundred thousand free trading shares in the past for our services. 
All those shares have been sold. We have received an additional one million 
free trading shares now. We intend to sell all one million shares now, 
which could cause the stock to go down, resulting in losses for you. 
The four hundred thousand shares and one million shares were received from 
two different third parties, not officers, directors or affiliate 
shareholders. This company has: an accumulated deficit, a negative net 
worth, a reliance on loans from officers directors and affiliates to pay 
expenses, and a nominal cash position. These factors raise substantial 
doubt about its ability to continue as a going concern. The company and 
its president are a defendant in a lawsuit. The publicly available float 
of stock is currently increasing. URGENT: Read the company's SEC filing 
before you invest. This report shall not be construed as any kind of 
investment advice or solicitation. WARNING: You can lose all your money 
by investing in this stock.

[Cgi-session-user] Invitation to join the jain2jaina4 group

[jain2jaina4 m. <jai...@ya...>]

Hello cgi...@li...,

jai...@ya... has invited to join the jain2jaina4 group
hosted by Yahoo! Groups, a free, easy-to-use community service.

By joining jain2jaina4, you will be able to receive
email announcements, share photos and files, coordinate events and more.

NOTE: This is an announcement or newsletter group, so only the group
moderator may post messages.

This invitation will expire in 30 days.

Here's an introductory message from jai...@ya...:
------------------------------------------------------------------------

FREE REGISTRATION

This group is started by

http://www.jain2jain.com

More Than 25000 Jain Matrimonial Bio-Data of 

Brides and Grooms From Different Jain Sections 

E.g.: Jain, Shah, Mehta, Bhandari, Goyal, Bansal etc. 

Largest Number of Well Educated & Cultured 

Jain Profiles Also Widower Divorcee

If you or your relative is looking for 

any Jain match than you can visit 

http://www.jain2jain.com

FREE REGISTRATION
 

------------------------------------------------------------------------

JOIN NOW, IT'S EASY: 

1) Go to the Yahoo! Groups site by clicking on this link:
   http://groups.yahoo.com/i?i=beB_8zWnCiPRQYZFCtGAvGU7Vqs&e=cgi-session-user%40lists%2Esourceforge%2Enet 

  (If clicking doesn't work, "Cut" and "Paste" the line above into your 
   Web browser's address bar.)

-OR-

2) REPLY to this email by clicking "Reply" and then "Send"
   in your email program

If you do not wish to join the jain2jaina4 group, please
ignore this invitation.

Report abuse:
------------------------------------------------------------------------
Yahoo! Groups is a free service that allows you to stay in touch with 
friends and family or meet new people who share your interests. 
Yahoo! Groups values your privacy. It is a violation of our service 
rules for Groups members to abuse this invitation feature. If you feel 
this has happened, please notify us:
http://help.yahoo.com/help/us/groups/abuse/index.html

You may also change your email preferences to stop receiving group 
invitations in the future. To do so, please go here:
http://groups.yahoo.com/s?tag=FWv2OnmFv5BUvO4jc68YiBz3PzfaSkZ1c1iNUtDHfDdUVTMq9ixmf7rxY3HzzvkBWTBeNqAbChYTzQyhaaGmBdmkR-G1V4KZTVyjVJo

Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

 

Re: [Cgi-session-user] Are CGI::Session session files removedautomatically?

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

I understand find() would be more convenient as an object method. But
calling new() to create an object also has a side effect, which is, it
creates a session file, which should be suppressed somehow. But find() as a
class method has the following syntax:

       find( \&code )
       find( $dsn, \&code )
       find( $dsn, \&code, \%dsn_args, \%coderef_args )

Sherzod


> -----Original Message-----
> From: cgi...@li...
> [mailto:cgi...@li...] On
> Behalf Of Mark Stosberg
> Sent: Monday, May 29, 2006 10:03 PM
> To: Sherzod Ruzmetov
> Cc: 'Ron Savage'; 'List - CGI-Session'
> Subject: Re: [Cgi-session-user] Are CGI::Session session
> files removedautomatically?
>
>
> On Mon, May 29, 2006 at 03:52:57AM -0400, Sherzod Ruzmetov wrote:
> > Ron,
> >
> > I never meant find() to be used as an object method, but as
> a class method,
> > as in CGI::Session->find(). But looking at your code, I think we can
> > re-write find() to work for both cases.
>
> As a class method, It's not clear how you'd communicate
> driver options,
> like where the tmp dir is located.
>
> 	Mark
>
>
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>
>

Re: [Cgi-session-user] To remove expired sessions from disk

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

On Tue, May 30, 2006 at 09:28:01AM -0700, David Levner wrote:
> 
> It appears that I have to read the session files instead of using
> CGI::Session to open them. If I use CGI::Session, then it will update
> _SESSION_ATIME (the last access time) as if the user had done
> something. My code would be much cleaner if there was a way to examine
> a session without updating the last access time.

I recall this being discussed before. I think it would be reasonable for
find() not to update _SESSION_ATIME, so patching CGI::Session to behave
that way could be a clean solution.

Either that, or pay more attention in your application to _SESSION_MTIME
instead, which would indicate that something actually changed in the
session.

	Mark

Re: [Cgi-session-user] To remove expired sessions from disk

[David L. <dav...@ya...>]

There is some very useful code in this thread, and I want to start by
thanking all the contributors.

My problem is related, but with a difference. I want to log out users,
and delete their session files, and *create logout transactions* in a
database almost as if the users had explicitly logged out. I don't want
CGI::Session to delete expired sessions behind the scenes without
creating logout transactions.

The solution I am implementing would use a cron job to read all the
existing sessions. If one is found that should be deleted, the cron job
writes the transaction to the database and deletes the session.

It appears that I have to read the session files instead of using
CGI::Session to open them. If I use CGI::Session, then it will update
_SESSION_ATIME (the last access time) as if the user had done
something. My code would be much cleaner if there was a way to examine
a session without updating the last access time.

I have another problem that is probably out of scope, but I'll mention
it anyway. The session files are owned by the www-data account, and I
can't modify or delete these files with a normal user account. I'm
working around this by having the cron job invoke a web page that
deletes the expired sessions. There is probably a way to set up the web
server (Apache) or cron to fix the permissions problem, but I don't
have root privileges on the machine and the administrator isn't very
responsive. I prefer to code around problems rather than ask for his
help.

I'm looking for suggestions that lead to a cleaner implementation for
creating logout transactions. Thanks for reading my post.

David Levner
dav...@ya...


  :Not that there"s anything wrong with that, but if you"re creating a 
  :purge method, is expiry the only reason to purge? Might we sometime 
  :want to purge all? Purge non-expired sessions, but which are over a 
  :certain age?
 
 That makes sense. In that case the only thing I can think of right 
 now is to introduce find() method for general purpose hosekeeping:
 
   CGI::Session->find(\&purge);
   sub purge {
       my ($session) = @_;
       next if $session->empty;   #<-- already expired 
       # delete sessions not accessed in the past 10 days
       $session->delete() if ($session->atime + 36000) <= time();
   }
 
 To remove all the session data from the disk regardless of age:
 
   CGI::Session->find( sub { $_[0]->delete unless $_[0]->empty } );
 
 To logout all the users who left your web site without doing so, but
do not
 purge their whole sessions.
 
   CGI::Session->find(\&logout);
   sub logout {
       my ($session) = @_;
       next if $session->empty();
       if ( ($session->atime+600 < time) &&
$session->param("_logged_in") ) {
 	  $session->clear(["_logged_in"]);
       }
   }
 
 If you"re using two-argument syntax of expire() you can replace the
above example with:
 
   CGI::Session->find( sub {} );
 
 which removes both expired sessions, and clears all the expired
session parameters.
 
 Unless anyone has a better proposal, I will start coding it tonight
and hopefully will
 have a beta-version out tomorrow.
 
 
 -- 
 Sherzod B. Ruzmetov <sherzodr@ha...>
 <URL: http://author.handalak.com >
 


			



From: John Horner <bounce@jo...>
Re: To remove expired sessions from disk  
2005-02-10 14:41

 >I was thinking of introducing purge() method into the stable release
to make
 >it even easier to remove expired sessions
 
 Not that there"s anything wrong with that, but if you"re creating a 
 purge method, is expiry the only reason to purge? Might we sometime 
 want to purge all? Purge non-expired sessions, but which are over a 
 certain age?
 
 I"m only thinking aloud, but perhaps we either want 
 "purge_expired()", or we want "purge( { where => "expired"} )"?
 


			



From: Sherzod Ruzmetov <sherzodr@ha...>
To remove expired sessions from disk  
2005-02-10 10:14

 It will work even finer with 4.x, just call load( $session_id ) for
 all the sessions stored in disk. It will delete all expired sessions
 as necessary without creating any new ones.
 
 I was thinking of introducing purge() method into the stable release
to make
 it even 
 easier to remove expired sessions:
 
 	CGI::Session->purge(undef, {Directory=>"/tmp"});
 	CGI::Session->purge("driver:mysql", {Handle=>$dbh});
 	CGI::Session->purge("serializer:storable;driver:sqlite",
 {DataSource=>"/tmp/sessions.sqlt"});
 
 Any better ideas? 
 
 
 
 > -----Original Message-----
 > From: B&#65533;r, Sebastian [mailto:Sebastian.Baer@3S...] 
 > Sent: Thursday, February 10, 2005 4:20 AM
 > To: Steven Bauer; cgi-session-user@li...
 > Subject: AW: [Cgi-session-user] CGI::Session 4.x
 > 
 > 
 > Hi Steven,
 > 
 > > Is there a way for expired sessions to be automatically deleted?
 > > 
 > > I have a site where the temp directory is getting continually
 > > clogged with
 > > expired session files.
 > 
 > If you use files to store sessions you can use a script like 
 > the one attached to get rid of expired sessions. Just start 
 > it via a cron job and everything will be fine ;-)
 > 
 > I haven"t had the time to see whether it still works with 4.x 
 > but I will update it once I know the differences. For 3.x it 
 > works for me.
 > 
 > Regards,
 > Sebastian
 > 
 > --
 > 
 > 
 > =head1 NAME
 > 
 > cleanup_sessions.pl - Remove outdated CGI-sessions.
 > 
 > =head1 SYNOPSIS
 > 
 >   cleanup_sessions.pl [-h|--help] [-p|--print-only] [-v|--verbose]
 > 
 > =head1 OPTIONS
 > 
 > =over 4
 > 
 > =item B<-h|--help>
 > 
 > Brings up a help screen.
 > 
 > =item B<-p|--print-only>
 > 
 > Print list sessions and exit without deleting them. Implies B<-v>.
 > 
 > =item B<-v|--verbose>
 > 
 > Show information for each session file.
 > 
 > =back
 > 
 > =head1 DESCRIPTION
 > 
 > Get rid of outdated sessions, the kind that will be created 
 > by timeouts or missing user logout (i.e. if the user closes 
 > the browser without a proper logout).
 > 
 > =cut
 > 
 > use strict;
 > 
 > use Getopt::Long;
 > use Pod::Usage;
 > 
 > {
 >   my $help     ="";
 >   my $printOnly="";
 >   my $removed  =0;  # Number of files removed.
 >   my $verbose  ="";
 > 
 >   GetOptions("h|help"       => \$help,
 >              "p|print-only" => \$printOnly,
 >              "v|verbose"    => \$verbose
 >             ) or pod2usage(1);
 > 
 >   pod2usage(-exitstatus => 0,
 >             -verbose    => 3
 >            ) if $help;
 > 
 >   # "--print-only" implies "--verbose":
 >   $verbose=1 if($printOnly);
 > 
 >   my $baseDir="/var/run/ssds";
 > 
 >   # Open the session directory...
 >   opendir(my $dir, $baseDir) or die("Cannot open session dir: " .
$!);
 > 
 >   # ... and scan it:
 >   while(my $filename=readdir($dir))
 >   {
 >     # Only touch session files:
 >     if($filename =~ /^cgisess_[a-f0-9]{32}$/)
 >     {
 >       my $etime=0;
 >       my $atime=0;
 >       my $file =$baseDir . "/" . $filename;
 > 
 >       if(open(my $fh, "<$file"))
 >       {
 >         $_=<$fh>;
 > 
 >         if(/_SESSION_ETIME" => "?(\d+)/)
 >         {
 >           $etime=$1;
 >         }
 > 
 > 
 >         if(/_SESSION_ATIME" => "?(\d+)/)
 >         {
 >           $atime=$1;
 >         }
 > 
 >         close($fh);
 >       }
 >       else
 >       {
 >         warn("Unable to open file: " . $!);
 >       }
 > 
 >       # Print the filename:
 >       print("$filename: ") if($verbose);
 > 
 >       if($etime)
 >       {
 >         # How many seconds are left?
 >         my $left=$etime+$atime-time();
 > 
 >         # To be sure no interaction with concurrent file 
 > access occurs we only
 >         # remove files that have expired at least a minute ago.
 >         if($left<-60)
 >         {
 >           print("Expired (at least a minute ago)\n") if($verbose);
 >         }
 >         else
 >         {
 >           if($left<0)
 >           {
 >             print("Expired (less than a minute ago) / 
 > keep\n") if($verbose);
 >           }
 >           else
 >           {
 >             print("Alive ($left sec remaining)\n");
 >           }
 >           next;
 >         }
 >       }
 >       else
 >       {
 >         print("Missing expiry time\n") if($verbose);
 >       }
 > 
 >       # Time to get rid of expired files:
 >       unless($printOnly)
 >       {
 >         unlink($file);
 >         $removed++;
 >       }
 >     }
 >   }
 > 
 >   closedir($dir);
 > 
 >   print("Removed $removed session files.\n");
 > }
 > 
 > 
 > --
 > Sebastian B&#65533;r, Software Developer, OSEK Business Division
 > 3SOFT GmbH - Member of the Elektrobit Group
 > 
 > 
 > -------------------------------------------------------
 > SF email is sponsored by - The IT Product Guide
 > Read honest & candid reviews on hundreds of IT Products from 
 > real users. Discover which products truly live up to the 
 > hype. Start reading now. 
 > http://ads.osdn.com/?ad_ide95&alloc_id396&op=ick
 > _______________________________________________
 > Cgi-session-user mailing list Cgi-session-user@li...
 > https://lists.sourceforge.net/lists/listinfo/cgi-session-user
 > 
 


			



From: <Sebastian.Baer@3S...>
AW: CGI::Session 4.x  
2005-02-10 01:19

 Hi Steven,
 
 > Is there a way for expired sessions to be automatically deleted?
 > 
 > I have a site where the temp directory is getting continually 
 > clogged with
 > expired session files.
 
 If you use files to store sessions you can use a script like the
 one attached to get rid of expired sessions.
 Just start it via a cron job and everything will be fine ;-)
 
 I haven"t had the time to see whether it still works with 4.x
 but I will update it once I know the differences. For 3.x
 it works for me.
 
 Regards,
 Sebastian
 
 --
 
 
 =head1 NAME
 
 cleanup_sessions.pl - Remove outdated CGI-sessions.
 
 =head1 SYNOPSIS
 
   cleanup_sessions.pl [-h|--help] [-p|--print-only] [-v|--verbose]
 
 =head1 OPTIONS
 
 =over 4
 
 =item B<-h|--help>
 
 Brings up a help screen.
 
 =item B<-p|--print-only>
 
 Print list sessions and exit without deleting them. Implies B<-v>.
 
 =item B<-v|--verbose>
 
 Show information for each session file.
 
 =back
 
 =head1 DESCRIPTION
 
 Get rid of outdated sessions, the kind that will be created by
timeouts or
 missing user logout (i.e. if the user closes the browser without a
proper
 logout).
 
 =cut
 
 use strict;
 
 use Getopt::Long;
 use Pod::Usage;
 
 {
   my $help     ="";
   my $printOnly="";
   my $removed  =0;  # Number of files removed.
   my $verbose  ="";
 
   GetOptions("h|help"       => \$help,
              "p|print-only" => \$printOnly,
              "v|verbose"    => \$verbose
             ) or pod2usage(1);
 
   pod2usage(-exitstatus => 0,
             -verbose    => 3
            ) if $help;
 
   # "--print-only" implies "--verbose":
   $verbose=1 if($printOnly);
 
   my $baseDir="/var/run/ssds";
 
   # Open the session directory...
   opendir(my $dir, $baseDir) or die("Cannot open session dir: " . $!);
 
   # ... and scan it:
   while(my $filename=readdir($dir))
   {
     # Only touch session files:
     if($filename =~ /^cgisess_[a-f0-9]{32}$/)
     {
       my $etime=0;
       my $atime=0;
       my $file =$baseDir . "/" . $filename;
 
       if(open(my $fh, "<$file"))
       {
         $_=<$fh>;
 
         if(/_SESSION_ETIME" => "?(\d+)/)
         {
           $etime=$1;
         }
 
 
         if(/_SESSION_ATIME" => "?(\d+)/)
         {
           $atime=$1;
         }
 
         close($fh);
       }
       else
       {
         warn("Unable to open file: " . $!);
       }
 
       # Print the filename:
       print("$filename: ") if($verbose);
 
       if($etime)
       {
         # How many seconds are left?
         my $left=$etime+$atime-time();
 
         # To be sure no interaction with concurrent file access occurs
we only
         # remove files that have expired at least a minute ago.
         if($left<-60)
         {
           print("Expired (at least a minute ago)\n") if($verbose);
         }
         else
         {
           if($left<0)
           {
             print("Expired (less than a minute ago) / keep\n")
if($verbose);
           }
           else
           {
             print("Alive ($left sec remaining)\n");
           }
           next;
         }
       }
       else
       {
         print("Missing expiry time\n") if($verbose);
       }
 
       # Time to get rid of expired files:
       unless($printOnly)
       {
         unlink($file);
         $removed++;
       }
     }
   }
 
   closedir($dir);
 
   print("Removed $removed session files.\n");
 }
 
 
 --
 Sebastian B&#65533;r, Software Developer, OSEK Business Division
 3SOFT GmbH - Member of the Elektrobit Group
 


			

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Cgi-session-user] Are CGI::Session session files removed automatically?

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

On Mon, 29 May 2006 22:01:41 -0400, Mark Stosberg wrote:

Hi Mark

> I'm surprised you didn't recommend your
> CGI::Session::ExpireSessions module, which specializes in this
> session clean-up.

I did in a follow-up msg.

> I haven't used it myself yet, but it does seem well-suited for the
> task.

On another note, I'm still waiting hopefully for patches I submitted to
CGI::Session to be accepted, so I can update CGI::Session::ExpireSessions
to call find with my own options.

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

Re: [Cgi-session-user] Are CGI::Session session files removed automatically?

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

On Mon, May 29, 2006 at 03:52:57AM -0400, Sherzod Ruzmetov wrote:
> Ron,
> 
> I never meant find() to be used as an object method, but as a class method,
> as in CGI::Session->find(). But looking at your code, I think we can
> re-write find() to work for both cases.

As a class method, It's not clear how you'd communicate driver options,
like where the tmp dir is located. 

	Mark

Re: [Cgi-session-user] Are CGI::Session session files removed automatically?

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

On Mon, May 29, 2006 at 04:30:30PM +1000, Ron Savage wrote:
> On Sun, 28 May 2006 21:47:54 -0600, Justin Simoni wrote:
> 
> Hi Justin
> 
> > CGI::Session->find( \&purge );
> 
> To get CGI::Session to look in the correct directory, perhaps replace the above
> line with:

Ron,

I'm surprised you didn't recommend your CGI::Session::ExpireSessions
module, which specializes in this session clean-up.

I haven't used it myself yet, but it does seem well-suited for the task.

	Mark

[Cgi-session-user] Trusted all o indians around the world

[hema j. <jai...@gm...>]

*We Are Pleased to Invite you on Our Matrimonial
Website.<http://www.jain2jain.com/>
*

 www.jain2jain.com

*See More Then 25000 Matrimonial Bio-data Of Jain Community At
http://jain2jain.com <http://www.jain2jain.com/>*

Re: [Cgi-session-user] Are CGI::Session session files removed automatically?

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

Ron,

I never meant find() to be used as an object method, but as a class method,
as in CGI::Session->find(). But looking at your code, I think we can
re-write find() to work for both cases.

If your code works for Justin, I would be surprised (sorry).

Sherzod

> -----Original Message-----
> From: cgi...@li...
> [mailto:cgi...@li...] On
> Behalf Of Ron Savage
> Sent: Monday, May 29, 2006 2:31 AM
> To: List - CGI-Session
> Subject: Re: [Cgi-session-user] Are CGI::Session session
> files removed automatically?
>
>
> On Sun, 28 May 2006 21:47:54 -0600, Justin Simoni wrote:
>
> Hi Justin
>
> > CGI::Session->find( \&purge );
>
> To get CGI::Session to look in the correct directory, perhaps
> replace the above line with:
>
> require CGI::Session;
> my $session = new CGI::Session(undef, undef, {Directory=>'/
> home/myaccount/sessions'}); $session -> find(\&purge);
>
> > Which is CGI::Session trying to remove files that aren't owned by
> > whatever is executing my app. Usually, when I run CGI::Session, I
>
> Perhaps you get permissions errors because:
> o The sessions were created by a CGI app run by the web
> server and hence owned by the owner of the web server process
> o The sessions are being deleted by you, and you're not the
> owner of the web server process
>
> --
> Ron Savage
> ro...@sa...
> http://savage.net.au/index.html
>
>
>
>
> _______________________________________________
> Cgi-session-user mailing list Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>
>

Re: [Cgi-session-user] Are CGI::Session session files removed automatically?

[Justin S. <ju...@sk...>]

Ron,

> To get CGI::Session to look in the correct directory, perhaps  
> replace the above
> line with:
>
> require CGI::Session;
> my $session = new CGI::Session(undef, undef, {Directory=>'/
> home/myaccount/sessions'});
> $session -> find(\&purge);


That worked perfectly. Thanks so much for that tip. I tried the below:

	require CGI::Session;
	my $session = new CGI::Session(undef, undef, {Directory=>'/home/ 
myaccount/sessions'});
	CGI::Session->find(\&purge);

But didn't catch my silly mistake. Thanks for the guidance! For  
completeness, here's my complete method, in my own session-handling  
module:

[snip]

sub remove_old_session_files {

     my $self = shift;

     if($self->{can_use_cgi_session} == 1 && $self-> 
{can_use_data_dumper} ==1){

         require CGI::Session;
         my $session = new CGI::Session(undef, undef, {Directory=> 
$TMP});

         $session->find( \&purge_cgi_sess );

         sub purge_cgi_sess {
             my ($session) = @_;
             $session->Directory($TMP);
             next if $session->empty;    # <-- already expired?!
             if ( ($session->ctime + 3600*48) <= time() ) { # two  
days...
                 $session->delete()
                     or warn "couldn't remove " . $session->id . ":  
" . $session->errstr;
             }
         }
     }
}

[/snip]

The, "next if $session->empty;    # <-- already expired?!" line that  
I reported as causing problems, doesn't seem to be problematic anymore.

Cheers and thanks again for the guidance,

Justin Simoni







On May 29, 2006, at 12:30 AM, Ron Savage wrote:

> On Sun, 28 May 2006 21:47:54 -0600, Justin Simoni wrote:
>
> Hi Justin
>
>> CGI::Session->find( \&purge );
>
> To get CGI::Session to look in the correct directory, perhaps  
> replace the above
> line with:
>
> require CGI::Session;
> my $session = new CGI::Session(undef, undef, {Directory=>'/
> home/myaccount/sessions'});
> $session -> find(\&purge);
>
>> Which is CGI::Session trying to remove files that aren't owned by
>> whatever is executing my app. Usually, when I run CGI::Session, I
>
> Perhaps you get permissions errors because:
> o The sessions were created by a CGI app run by the web server and  
> hence owned
> by the owner of the web server process
> o The sessions are being deleted by you, and you're not the owner  
> of the web
> server process
>
> --
> Ron Savage
> ro...@sa...
> http://savage.net.au/index.html
>
>
>
>
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

Re: [Cgi-session-user] Are CGI::Session session files removed automatically?

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

On Sun, 28 May 2006 21:47:54 -0600, Justin Simoni wrote:

Hi Justin

> CGI::Session->find( \&purge );

To get CGI::Session to look in the correct directory, perhaps replace the above
line with:

require CGI::Session;
my $session = new CGI::Session(undef, undef, {Directory=>'/
home/myaccount/sessions'});
$session -> find(\&purge);

> Which is CGI::Session trying to remove files that aren't owned by
> whatever is executing my app. Usually, when I run CGI::Session, I

Perhaps you get permissions errors because:
o The sessions were created by a CGI app run by the web server and hence owned
by the owner of the web server process
o The sessions are being deleted by you, and you're not the owner of the web
server process

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

Re: [Cgi-session-user] Are CGI::Session session files removed automatically?

[Justin S. <ju...@sk...>]

Hello All,


A few weeks ago, I asked how to delete the cgi session files, saved  
on disk via the CGI::Session::file driver. I was pointed to the,  
"find" method docs, which suggested trying:

	CGI::Session->find( sub {} );

as a way to remove old session files. This doesn't seem to do a  
thing, so I tried a variation of the next example:


CGI::Session->find( \&purge );
     sub purge {
         my ($session) = @_;
         next if $session->empty;    # <-- already expired?!
         if ( ($session->ctime + 3600*240) <= time() ) {
             $session->delete() or warn "couldn't remove " . $session- 
 >id . ": " . $session->errstr;
         }
     }


This, also didn't work - two points. commenting out the,

	next if $session->empty;    # <-- already expired?!

At least allowed my program to run (no errors reported?!) :)

The other point was that CGI::Session by default was looking in the "/ 
tmp" directory for these old session files. I received numerous  
errors like this:

	[Sun May 28 23:20:30 2006] script.cgi: couldn't remove  
c7d30b81e15465627d7b955ab33dacfd: flush(): couldn't remove session  
data: remove(): couldn't unlink '/tmp/ 
cgisess_0d9e96e65ba2691b8016d97920e74c6f': Operation not permitted  
at /This/Here/App.pm line 528.

Which is CGI::Session trying to remove files that aren't owned by  
whatever is executing my app. Usually, when I run CGI::Session, I set  
an explicit directory to save my session files into, ala:

	require CGI::Session;
         my $session = new CGI::Session(undef, undef, {Directory=>'/ 
home/myaccount/sessions'});


How do I pass this directory to CGI::Session, when using the find  
method?

I tried something like:

	CGI::Session->Directory('/home/myaccount/sessions');

But that doesn't seem to work.

Cheers,

Justin



	

On May 16, 2006, at 10:09 PM, Justin Simoni wrote:

> Thanks! I'll give this a shot and report my findings;
>
> Justin Simoni
>
> On May 16, 2006, at 9:38 PM, Sherzod Ruzmetov wrote:
>
>> Look up find() in CGI::Session 4.x. It wasn't thouroughly tested,  
>> but the
>> purpose of find() is to make the cleanup task easier.
>>
>> Give it a shot. We'd appreciate the feedback.
>>
>>
>> Sherzod
>>
>>> -----Original Message-----
>>> From: cgi...@li...
>>> [mailto:cgi...@li...] On
>>> Behalf Of Justin Simoni
>>> Sent: Tuesday, May 16, 2006 10:33 PM
>>> To: Cgi...@li...
>>> Subject: [Cgi-session-user] Are CGI::Session session files
>>> removed automatically?
>>>
>>>
>>> Heya,
>>>
>>> In previous versions of CGI::Session (ver. 3.x?) the default, "file"
>>> driver would not automatically remove session files that were
>>> expired. Is this still true in 4.13? In past versions, I used my own
>>> outside thingy to remove expired session files. If this isn't done
>>> automatically by CGI::Session, is there a similar routine I can use
>>> to remove these session files?
>>>
>>> Cheers,
>>>
>>> Justin Simoni
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web
>>> services, security? Get stuff done quickly with
>>> pre-integrated technology to make your job easier Download
>>> IBM WebSphere Application Server v.1.0.1 based on Apache
>>> Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
>>> dat=121642
>>> _______________________________________________
>>> Cgi-session-user mailing list Cgi...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>>>
>>>
>>
>>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

[Cgi-session-user] life partner, a few steps away

[Malika J. <mat...@gm...>]

*We Are Pleased to Invite you on Our Matrimonial
Website.<http://www.jain2jain.com/>
*

 www.jain2jain.com

*See More Then 25000 Matrimonial Bio-data Of Jain Community At
http://jain2jain.com <http://www.jain2jain.com/>*