in reply to Re: Re: Using 403 as a redirect
in thread Using 403 as a redirect

Checking the users' cookies every page and redirecting them if they aren't logged in is sufficient - that's the missing part of the authentication plan your original post didn't mention. It isn't the most elegant way of going about it, however; Apache has authentication built in that mod_perl can tap into. If you do that, a user attempting to go into a secure area should get a 401 (Authorization Required) error. Since the entire site is supposed to be secure, a request for a non-existent index (for a user not logged in) should redirect to your login page. (Once a user is logged in that request would receive a 403 (Forbidden) response, since you have indexing turned off).

I couldn't find anything that does exactly what I like an authentication module to do in CPAN, but Apache::Authen::Generic looks like it is close. Apache::AuthDigest and Apache::AuthenSecurID also hook into Apache's authentication stuff and might be good starting places. Apache changed it's authentication model in 2.1, so if that's the version you're using, Apache::AuthenHook is specifically for 2.1.

Anyways, the way you are doing it is fine (you are authenticating every page by checking the cookie and redirecting as necessary). Apache2 is a moving target, so I'd stick with your strategy for now.

Replies are listed 'Best First'.
Re: Re: Re: Re: Using 403 as a redirect
by dragonchild (Archbishop) on Jan 09, 2004 at 18:33 UTC
    Yes, the first thing I do on every page is check for the cookie and redirect as necessary. Eventually, I will be moving that check to a handler which will run before the request is even passed to the application.

    In case you're wondering, I cannot (currently) use Apache/mod_perl's standard authentication using .htpasswd or some digest because I'm in the processing of porting an application and some older sections of the app use a rather insecure method of authentication. Once the whole mess is ported, I'll be able to move the authentication process out of the application database and into some sort of MD5digest (or the like). (I'll also be able to do sessions, but that's another story.)

    ------
    We are the carpenters and bricklayers of the Information Age.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.