in reply to Using 403 as a redirect

I don't see any issues unless
a) you trying to force all your visitors to log in
AND
b) you don't have any other authorization enforcement in place.

You're a Saint and an experienced programmer, so I assume that a) and b) aren't both true. However, I bring it up in case someone less experienced looked at your post and thought this was a complete authentication plan, because it isn't. Anyone who is interested in that should search CPAN for "Auth" - there are a ton of choices out there. I like the ones where you just put directives into the httpd.conf or .htaccess files, but that's a personal preference.

Also, if I weren't trying to force authentication, I might use the apache Redirect directive or mod_rewrite. (Unless I wanted all Forbidden queries going to the login screen, in which case your solution is the best and not a hack at all.) Of course, if I were forcing authentication, the authentication module would do the redirection itself if the user hadn't logged in yet...

Replies are listed 'Best First'.
Re: Re: Using 403 as a redirect
by dragonchild (Archbishop) on Jan 09, 2004 at 02:55 UTC
    Bad assumption, Mr. bean. I'm an experienced programmer, but I have less experience in the setting up of an Apache application. I can write whatever you want in the app, but this is my first app from start to finish.

    As for your assumptions ... I am both trying to force all visitors to log in AND this is the only authentication that occurs. (Well, authentication sets an expiring cookie with a session ID that is checked against both IP and browser type every request, but it is the only point of authentication.)

    What is wrong with it as a complete authentication plan? I'm not sure where the problem lies ... (It's that Apache-newbie issue again ...)

    Also, note that I'm using Apache2. (I am not currently using MP2, but will once it's stable. We currently don't use or need any MP capabilities, nor will for about 3-6 months.)

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

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