Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Just Another Question About Sessions And User Management

by muba (Priest)
on Sep 25, 2005 at 21:09 UTC ( [id://494960]=perlquestion: print w/replies, xml ) Need Help??

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

Ok, now I've had it.
I know this is a FAQ, I know people don't like it when FAQ's are asked again, but I'm gonna do it anyway, because I couldn't find information.

I'm about to write my very own CMS which should fit my needs and preferences. So far so good.
I used Super Search and Google to find a simple explanation of how to keep track of logged in users.
Various sources refer to CGI::Session. I had a look at it, and at its tutorial. But it has a bit of an information overkill for me.
I found sources explaining how I should set sessions cookies manually, but those didn't tell me how to read those sessions cookies.

So what I basically need, is a simple way to either
  • set,
  • read,
  • and delete
sessions (update: which are cookies probably) for logged in users.

If you can tell me how to do this, or point me to a simple step-by-step tutorial for CGI::Session (or another session module (but note that I'm on Xitami, no mod_perl, no Apache or whatnot)), please do so.
But remember: the keyword is 'simple' here.
The thing I need to do seems rather simple to me (check whether some user is or isn't logged in), so the path should be simple as well, IMO.

Of course, thanks in avance :)

Update: changed 'sessions' into 'cookies' at some places.

Replies are listed 'Best First'.
Re: Just Another Question About Sessions And User Management
by nedals (Deacon) on Sep 26, 2005 at 01:51 UTC

    In the spirit of KISS

    use strict; use CGI; my $q = new CGI; # Set a SESSION persistant cookie. (deleted when browser is closed) my $cookie = "name=value;path=\"; print $q->header(-cookie => $cookie); # The cookie value should be some sort of code (encrypted or random), +linked # to a database (or file) variable for validation. # Read a cookie. And don't forget to verify that it's what you expect. my $cookie_value = $q->cookie('name'); if ($cookie_value !~ /^\w{23}$/) { print "not a valid cookie\n" } # Clear a cookie. # Here you can re-write the cookie with a 'past' date, or simply null +it out # Also clear out the database (or file) variable. my $cookie = "name=;path=\"; print $q->header(-cookie => $cookie);

    Also take a look a this...
    stonehenge

      Ah, this looks rather simple indeed. The stonehenge article is pretty useful as well. Thank you!
      Just need to find out how I will manage the server-side file storage, but that'll be no problem.
Re: Just Another Question About Sessions And User Management
by friedo (Prior) on Sep 25, 2005 at 21:42 UTC
    I'm not entirely sure why CGI::Session won't work for you (the tutorial makes it very straightforward), but if you want to deal with cookies yourself, use CGI::Cookie.

    If the documentation for either CGI::Cookie or CGI::Session is not enough to get you started, you probably need to work on your Perl skills before attempting such an ambitious project.

Re: Just Another Question About Sessions And User Management
by aufflick (Deacon) on Sep 26, 2005 at 00:16 UTC
    Despite it's name, as far as I know Apache::Session does not have any dependancy on Apache. It simply uses Storable to tie a stored hash to a session id. You then need to stash that session id in a cookie/url variable or whatever takes your fancy.

    Take a look at the HTTP_COOKIES section for CGI.pm for it's handling of cookies, assuming your web browser accepts headers set by cgi's in the usual (CERN/NCSA) fashion.

Re: Just Another Question About Sessions And User Management
by skx (Parson) on Sep 26, 2005 at 11:26 UTC

    Here is a small example:

    #!/usr/bin/perl -w -I. use strict; use CGI; use CGI::Cookie; use CGI::Carp qw/ fatalsToBrowser /; # TODO - Hide errors. use CGI::Session; # # New CGI object; used to get access to the cookie(s). # my $q = new CGI; # # Get a CGI::Session object - either completely new, or one previousl +y # associated with the given cookie. # my $session = CGI::Session->new( 'driver:File', $q->cookie('CGISESSID') || $q->param('CGISESSID') || +undef, { Directory => '/tmp' } ) or die ($CGI::Session::errstr); # # Identifier for this session. # my $sessionid = $session->id(); # # Retrieve "count" from it. # my $count = $session->param("count") || "1"; # # Update the count in the session # $session->param( "count", ($count+1) ); # # Print a sample page showing the visited count: # print "Set-Cookie: " . $q->cookie( -name => 'CGISESSID', -value => $sessionid, -expires => '+1d', -path => '/' ) . "\n"; print "Content-type: text/plain\n\n"; print "You've been here $count times before\n";
    Steve
    --
Re: Just Another Question About Sessions
by BUU (Prior) on Sep 25, 2005 at 21:17 UTC
    Set cookie. Read cookie!
      I personally like/prefer setting a sessionid parameter in every URL (or embedding a hidden sessionid parameter in every form).

      Cookies can be blocked, whereas an embedded sessionid in urls will be portable across every browser known to man (even lynx), and still offers security, particularly if web pages check the sessionid against the incoming IP address..

        an embedded sessionid in urls... still offers security, particularly if web pages check the sessionid against the incoming IP address.

        I believe this to be an oversimplification. Different users can have the same apparent IP address thanks to proxy servers. Additionally, as described in "Writing Apache Modules with Perl and C", URLs with session data can leak out to other sites via the HTTP Referer (sic) header if your site links to external resources or if a visitor leaves your site for another.

        MSDN Magazine has an document on maintaining session state that points out, "[Embedding session IDs in URLs] is discouraged from the security perspective because cookieless IDs lend themselves better to discovery and spoofing, and to injection by link posting or phishing attacks".

        As I see it, there's a balance to be struck between alienating users who don't want to accept cookies and accepting the somewhat heightened risk of using session IDs embedded in URLs in the absence of cookies.

                $perlmonks{seattlejohn} = 'John Clyman';

      Yeah, I understand. But *how*!
        Manually? CGI.pm? Apache::Cookie? A search on cpan.org shows up 701 results for Cookie, surely one of them will let you get/set them.
Re: Just Another Question About Sessions And User Management
by talexb (Chancellor) on Sep 26, 2005 at 12:39 UTC

    My Toronto YAPC buddies Richard Dice and Michael Graham demonstrated CGI::Application::Framework which sounded like it took care of everything you're talking about when it was presented at YAPC 2005 in Toronto. I just checked, and it is available on CPAN, although the warning does state that it's alpha quality software.

    The docs look pretty complete, so have a look anyway.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: Just Another Question About Sessions And User Management
by muba (Priest) on Sep 26, 2005 at 14:13 UTC
    Ok... I just had a try with CGI::Session and I received an error. Flock() not supported :)
    So I guess CGI::Session doesn't work on Windows systems :(
    Anyway, using CGI::Cookie doesn't seem to give any problems.

    Thanks for all help so far!
Re: Just Another Question About Sessions And User Management
by leocharre (Priest) on Sep 20, 2006 at 15:01 UTC

    Why are using this "xitami" to develop a cms on? It seems to me the simplest thing in the world would be to start with tried and true ingredients that are known. If you are trying to make bread, Maybe Xitami is better flour then apache, but maybe not many people will know how to work with Xitami flour, therefore.. can't help you?

    I may be way off. You tell me.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (5)
As of 2024-03-28 20:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found