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

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.

  • Comment on Re: site access: Apache Basic auth vs. CGI::Session and cookies

Replies are listed 'Best First'.
Re^2: site access: Apache Basic auth vs. CGI::Session and cookies
by j3 (Friar) on Apr 10, 2007 at 07:12 UTC

    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.

[reply]
      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.

[reply]

        Thanks for the tip about the common solution varian. I'll keep reading. I still don't see the connection between using Apache and using cookies. I thought cookies were only for setting simple values that I'd be explicitly looking at later in my cgi scripts... but it sounds like there's a connection with the Apache/HTTP auth stuff that I'm unaware of so far.

[reply]

In Section Seekers of Perl Wisdom