Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Some questions about CGI::Session

by Cody Fendant (Hermit)
on Jun 01, 2011 at 03:35 UTC ( [id://907564]=perlquestion: print w/replies, xml ) Need Help??

Cody Fendant has asked for the wisdom of the Perl Monks concerning the following question:

I've set up a discussion board, using CGI::Session.

I used the suggested setup from CGI::Session::Cookbook, which has me saving session data into text files in a tmp directory.

Now I have a tmp directory with a huge number of small text files in it. I guess there's one for each browser which has ever visited the site, whether its user logged in or not? It's already difficult to interact with this folder via FTP because some clients time out just opening the folder.

So, question one, how sustainable is this? How many small text files can a linux system have in one folder before things start to slow down or otherwise cause problems? Should I move to a tmp/a, tmp/b, tmp/c system? Should I move to a database as the storage rather than files? Could I do this somehow without forcing all users to log in again? Remove files regularly, where the session isn't logged in and the access time is a long time ago?

Question two -- how would I quickly cancel a user's session (force them to be logged out and not let them log in again)? I'm concerned about how to ban people, obviously. There's no easy way I can see to locate user foo and kill their session, and if we've chosen the "remember me" option, the init() at the top of the page as specified by the cookbook just reads them as logged in.

Replies are listed 'Best First'.
Re: Some questions about CGI::Session
by GrandFather (Saint) on Jun 01, 2011 at 04:21 UTC

    For a start the "ban" list could have a quite different solution to your logged in problem. However I'd be inclined to use a small database (DBD::SQLite) which solves both problems. If you haven't used a database before take a look at Databases made easy for a quick introduction which pretty much covers everything you are likely to need for this job.

    True laziness is hard work
Re: Some questions about CGI::Session
by Anonymous Monk on Jun 01, 2011 at 04:54 UTC
    I guess there's one for each browser which has ever visited the site, whether its user logged in or not?

    There should be a file for each session. Sessions are not dependent upon a user being logged in or not. Usually, someone visits the page (calls your cgi program), and session is created. Unless you do cleanup, the session will hang around forever.

    Also, you shouldn't be guessing, or taking my word for it, you should be testing (and making notes) instead :) for example see Re^3: CGI::Session - expiry, Re: CGI::Session Question

    So, question one, how sustainable is this?

    Well, file system limits are very real, too many files, and enumerating files (readdir) slows down noticably, its one of the reasons CPAN uses the id/A/AU/AUTHOR scheme (git uses a similar scheme).

    You can adopt this scheme by subclassing CGI::Session::Driver::file and splitting directories based on sessionid (and while you're at it, you can omit cgisess_ as a filename prefix).

    (OT) should i limit number of files in a directory, Efficient processing of large directory, Perl solution for storage of large number of small files, Comparison of file systems

    Could I do this somehow without forcing all users to log in again?

    You're a programmer aren't you? :D

Re: Some questions about CGI::Session
by sundialsvc4 (Abbot) on Jun 01, 2011 at 12:57 UTC

    When used in this capacity, a filesystem basically is a database, and it actually is one that’s pretty darned well suited to the purpose at hand.   If you subdivide the data into sub-directories according to some rule, you can store millions of records easily.   Issues relating to file-sharing, e.g. as might be the case with SQLite, simply disappear.

    Banning a user is a slightly different issue, o’course.   Usually that is handled during the login process.   If what you are actually concerned with is “session flooding,” in which a malicious site floods yours with bogus session-id tokens in order to fill up your session store, the simplest way to deal with that is by “salting” all valid session-ids with a portion that is computed by an (unknown to the attacker) SHA1 hash-substring.   This makes it more difficult to generate “millions of valid session tokens.”

Re: Some questions about CGI::Session
by jacaril (Beadle) on Jun 01, 2011 at 15:09 UTC

    I have had the same issue with CGI:Session under linux, the file build up over time can be extremely bad. There are no real methods to clean up temp files if the user does not log out, so you may need a system based solution. Check the find command something similar to "find /SessionPath/ -mtime +31 -exec rm {} \;" for clearing files not accessed in a month, if you do not all ready have something in place. Using find in this manner may handle the cases of directory structure and entered into crontab or another scheduler can net you more dev time.

    The alternative DB stored sessions will work and may offer additional tracking at the expense of additional development time. making changes to the text files is simplier then adding/modifying table structures.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://907564]
Approved by davido
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (5)
As of 2024-03-29 01:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found