Re: Authentication

[Micah Yoder <LYoder@cyberis.net>]

"Aaron D. Turner" wrote:

> OK, I get it now.  You're sending http content/auth headers via the script
> and bypassing the server.

Right.  I implemented this method in PHP in my other project, and it
seems to work fine.  My only question is how easily it would work with
Perl.

> > > 1)  How do you access them from a Perl/CGI script?
> >
> > You'd need to parse HTTP headers to get them.  Again, I assume there's
> > Perl code for it somewhere.
> 
> Yeah it does, but just because you can doesn't mean you should.

Doesn't mean you shouldn't either.  :-)  In any case, it would be a file
that's included from all the others, so no big deal.

> > > 2)  How to you access them from a plain HTML file?
> >
> > You don't, nor do you need to.  Plain HTML files aren't protected.
> 
> Well why limit ourselves?  What if we want to protect plain html files?
> Maybe these files are updated each min/hour/day via cron rather than a
> CGI/PHP script.

If we did need that (which I doubt) we could put it in a PHP wrapper.

> My understanding is that HTTP auth works like this:
...
correct

> Like I said, we can do it like you say, but it is taking something that is
> supposed to be done by the server and then does by the script.  Not going
> to be fun to debug.

I already did it (with other project).  No problem at all.  :-)

> > There isn't a login page.  Any time they try to load a protected page,
> > and he is not logged in, he'll get an HTTP auth error and will get a
> > Passwd entry dialog box.
> 
> But only if he bookmarks a PHP/Perl page.  Static html pages won't work
> with your proposed method because they can't authenticate users.

[see above]

> > Anyway, I think the method I described is probably marginally better
> > than "standard" server driven HTTP auth.  With this method, we'll be
> > able to check the user's RoleID with the same query that grabs his
> > password.  Using standard HTTP auth, we'd still have to run a query
> > AFTER he logs in to get the RoleID.
> 
> Nope, you can do that too.  Here's how:
> 
> Each authentication zone reflects a RoleID.  Ie there is a:
> 
> "Content Manager" Zone
> "System Admin" Zone
> "Entry Writing" Zone
> 
> Which actually makes a lot of sense IMHO.  Of course this means that the
> person will have to re-login each time they change RoleID's (aka auth
> zones), but that should be considered a feature as it enhances security.

Whoa...  like, they'll need to re-login any time they access a page that
requires a different role ID?  That would stink.  Browsing (no RoleID),
commenting (ID 1), submitting (ID 2)... I don't think we'd want to have
to re-login when switching between those modes.

> Anyways, the Apache::Authen module looks up the given user name/password
> against the Zone (RoleID).  If everything checks out, authorization is
> granted.  The advantage is of course that you don't need to double code a
> Perl and PHP solution and you can properly serve/protect static html
> pages.  Also, it keeps the debuging on the server level and not server and
> script combination which I'm honestly frightened to do.

Hmm...  that might be allright.  So we can specify different minimum
RoleIDs for each page and/or directory?

If that's the case, it might not need any coding at all!  But I do (at
least I think) know what I'm doing with my method, and it would be a
little more flexible...

Either method is probably fine.  I'm not familiar with Apache::Authen. 
Have you used it for anything before?

What does everyone else think?