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.

• 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.)