There are at least 2 places where the idea can be improved to be even better:
1) for browsers that do not support cookie, embed the ticket/credential in the URL so the system works for all browsers 2) the part for ticket verification can be written in C so in case of dual-server setup (light plus proxy), which is kind of popular now, one can set it up in the light server to protect static content. Peter ----- Original Message ----- From: "Michael L. Artz" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, June 10, 2003 6:47 PM Subject: Re: Authentication design > > Well, sorta. I am actually using a custom module very similar to the > one found in the cookbook (and AuthCookie, I think), i.e. create a > PerlAuthenHandler that sets the custom error message to the login page > and redirects you to it if you pass it an incorrect user/password > request. If it the user/pass checks out, I set a session cookie (md5 > sum of stuff), store the session_key in the database (Postgres), and set > $r->user. If no user/password or cookie is presented, I just return OK > for most of the site. A couple of scripts are "login-only", and those > are protected by an authz handler that makes sure $r->user is set. > Everything is handled with my custom login forms, none of the crappy > pop-ups for basic or digest authentication. So I guess that I am > usurping the normal HTTP-authentication phase for my own nefarious purposes. > > I thought that this was a good way to go since I could protect my entire > application with a single module and a couple lines in the config file, > as opposed to bundling that authentication code into the beginning of > *every* registry script that I write. And, from lurking on the board > for a long time, I got the feeling that this is how everyone is doing it > .... is that a correct assumption? > > -Mike > > >
