Re: Authentication

["Aaron D. Turner" <aturner@pobox.com>]

-----BEGIN PGP SIGNED MESSAGE-----


On Mon, 1 Mar 1999, Micah Yoder wrote:

> "Aaron D. Turner" wrote:
> 
> > Now I'm confused.  Isn't what you're talking about above exactly what
> > we've been talking about for the past few weeks?  Basically having a web
> > page which the user login's and then some means of cookies/variables/URL
> > to keep track that the user is "logged in" or not?
> 
> No...
> 
> With this method, the browser still pops up the window asking for
> user/passwd, but the script handles the authentication.  Much like the
> login form method, only the browser displays the form so we don't need
> to code it in HTML.

OK, I get it now.  You're sending http content/auth headers via the script
and bypassing the server.
 
> > Basically these PHP variables:
> > 
> > 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.

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

> > 3)  How do you keep state?
> 
> The browser sends the info every time you access the site AFTER the
> first time a login is requested...   OK....
> 
> Bozo goes to http://linuxkb.org
> Browses and searches articles, no problem
> Loads the comment page
> Code notices that he needs to be logged in.  Sends an "HTTP
> Authentication Required" message.  Bozo enters his handle and password.
> Code checks his password, and if successful, posts comment.
> >From here on out, every time he accesses ANY page, the info will be
> there.  Browser will not pop up auth window again.

My understanding is that HTTP auth works like this:

1) Client requests http://domain/path/file.something
2) Server checks for a .htaccess file in <httpd_root>/path/ (or global
	config)
3) .htaccess says it needs to verify user
4) Server sends http auth header
5) User logs in
6) Client browser re-requests same file
7) Server checks .htaccess
8) Server sends http auth header
9) Client broswer sends authorization
10) Server processes page and sends contents.

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.

> > 4)  What if someone bookmarks a "protected" page and thereby by-passes
> > the login page?  What happens then?  They *SHOULD* get a query to login
> > and then be presented the page they requested.
> 
> 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.
 
> > Sure, but why bother?  HTTP Authentication is much better.  Why?  Because
> > the only thing we need to worry about is defining the Authorization Zones
> > (via .htaccess files in the directories).  We let the web server do the
> > authentication and authorization.  As Roger showed, in his email, this is
> > done via the httpd.conf file, so NO code is necessary for any PHP/CGI/HTML
> > page.
> > 
> > The only problem we had in the past is that we couldn't interface our
> > MySQL DB with HTTP Authentication.  Now, with mod_perl and the
> > Apache::Authen module we can.
> > 
> > > Are there still objections????  I *could* be wrong, but I *think* it's
> > > the easiest way to do it.
> > 
> > Consider this email an objection.  Plain-jane http auth that we've all
> > come to know and love is the best IMHO.
> 
> Now I'm REALLY confused.  I though you were arguing against doing it
> that way, mainly because of DB issues and whatever else.  Now you're
> saying this is the best way to do it?  I thought you wanted just a
> single HTML login page and then propagate login info with URLs or POST
> variables.

I probably was advocating that.  Then I started thinking, reading,
learning, and changed my mind.  Sorry. :-)

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

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. 

- -- 
Aaron Turner           | Either which way, one half dozen or another. 
aturner@pobox.com      | Check out the Red Hat Linux User's FAQ Online!
www.pobox.com/~aturner | http://www.pobox.com/~aturner/RedHat-FAQ/
All emails from this account are PGP signed.  Lack of a signature is "bad".
PGP Key fingerprint = FB E1 CE ED 57 E4 AB 80  59 6E 60 BF 45 1B 20 E8



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNtunfzM3jpXy1kJtAQH/zgQArthJVPehxWQSXz5kISMsp2O0jJLqfYJO
DLn81AoGnDTZhygy8enx0z4DTLRpYhkU7dGgufeDdCERUCnU4uc8tc9lEpSTaSLd
TWmUmE0tqhuZ6pQjR1JDVmtQG1zdggYls43MCsAtce4ZsToKbRRU9s29bQ7e6X0p
6O8LZDM+hi0=
=WCQ5
-----END PGP SIGNATURE-----