Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

site access: Apache Basic auth vs. CGI::Session and cookies

by j3 (Friar)
on Apr 10, 2007 at 03:57 UTC ( #609070=perlquestion: print w/ replies, xml ) Need Help??
j3 has asked for the wisdom of the Perl Monks concerning the following question:

When creating a site that requires a user to login to gain access, so far it seems to me that there's 2 common ways to set it up:

  1. Use Apache's Basic authentication (using htpasswd, and .htaccess and .htpasswd files -- and even Apache::Htpasswd).
  2. Use something like CGI::Session along with cookies (CGI::Cookie).

If your site doesn't require anything persistent beyond just remembering that the user is logged in, what are the reasons for choosing one of the above methods over the other?

I understand that, as soon as you start needing some persistent state (like, keeping track of a user's shopping cart), then you need to go with something like option 2... But, are there circumstances where you'd use both of the above options together?

Comment on site access: Apache Basic auth vs. CGI::Session and cookies
Re: site access: Apache Basic auth vs. CGI::Session and cookies
by varian (Chaplain) on Apr 10, 2007 at 05:41 UTC
    Apart from session persistence the most important reason for using cookies or some other method beyond Apache's Basic Authentication is the need for a site logout.

    Normally browsers will keep issuing authorization headers to the server and maintain their authorized state because while the HTTP protocol defines authorization schemes unfortunately there is no common un-authorization scheme defined.

    Here's where cookies and the likes can help. The server side can influence the validity and content of a cookie. Just set a cookie to a 'logout' status when the user requests to logout and the next roundtrip the browser issues an authorization header then decline the validity of that header.

    There are many modules on CPAN that combine basic authentication with cookies (or even sessions) to get this result.

      So, using HTTP authorization, getting the user's browser to stop sending auth headers constitutes how you get that user "logged out"?

      If that's the case, I think what you're suggesting is having my webapp set a cookie to logout (maybe to expire the cookie?), such that the cookie somehow tells the user's web browser to stop sending authorization headers -- is that correct?

      and the next roundtrip the browser issues an authorization header then decline the validity of that header.

      But it would seem to me that the browser is carrying on a rather personal discussion with the web server, without my webapp even knowing about it. How do I "decline the validity" of that header? Does my webapp code even see it?

      Hm... It would seem somewhat simpler to not even bother with HTTP authorization and just use cookies and my own webapp code to decide whether users are logged in or out. I think that's what you're getting at in your last sentence.

        It would seem somewhat simpler to not even bother with HTTP authorization and just use cookies and my own webapp code to decide whether users are logged in or out
        No, don't go there, it does not make sense to have each and every web application manage session or authorization cookies.

        The common solution is to setup an 1) Authentication and an 2) Authorization Handler, as Perl modules that are called by the (Apache) webserver upon each url request.

        These modules have been written already, an example that you may want to have a look at is AuthCookieDBI.pm

        The only thing left with your web application is that you might want to implement a logout button that simply makes a call to the Perl module to have the cookie invalidated. And you will want to create a login page somewhere. That's all.

Re: site access: Apache Basic auth vs. CGI::Session and cookies
by rodion (Chaplain) on Apr 10, 2007 at 07:27 UTC
    Where I work, we use cookies; each Perl CGI program in the suite checks the cookie as its first responsibility, using code from a common in-house module. We do this because:
    • We need logout (as varian described).
    • We need auto-logout. The cookie contains a time-stamp, and each new screen (in the group of Perl CGI that has access to restricted information) checks that the time-stamp is within the last 5 minutes, then refreshes the timestamp.
    • Parts of our system are on multiple servers, and we need login to work across them.
    • Different users have permission to change different things. Some can just see the page, others can enter information, still others are allowed to sign and finalize a report. The cookie contains the permissions that indicated who can do what. (We only do this for browsers on trusted machines, inside our firewall and at specific IP addresses.)

    Log In?
    Username:
    Password:

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

    How do I use this? | Other CB clients
    Other Users?
    Others lurking in the Monastery: (5)
    As of 2014-07-26 11:15 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      My favorite superfluous repetitious redundant duplicative phrase is:









      Results (175 votes), past polls