"Marinos J. Yannikos" <[EMAIL PROTECTED]> writes:

> Hi!
> 
> I need to implement user authentication / session management for a
> relatively busy web site and I have observed the following:
> 
> 1) one database query per visited page is out of the question, at this time
> we can't afford the hardware to scale up to our projected 10-15 mil. page
> impressions / month (currently > 2,5 mil.), so we can't simply take the
> user/password data from a cookie or through the Basic Authentication
> mechanism at each request and authenticate. Session management using an SQL
> database or even GDBM/DB is thus also not easily possible.
> 
> 2) caching the database lookups for authentication and sessions / user state
> would require some sort of synchronization between the apache processes for
> the case of password / user data changes, IPC::Cache turned out to be very
> slow on our FreeBSD box (so it's out)
> 
> 3) Ticket-based authentications seems like a high-performance solution (user
> name, password, perhaps some session state are MD5-hashed and stored in a
> cookie, no database queries needed for authentication, no state must be
> shared among apache processes), a "permanent" login can be achieved by
> combining this method with a common login cookie (1 database query per
> session). This seems to be the best solution, although the amount of session
> state that can be kept easily is limited (larger stuff can be stored in a
> database if accessed less frequently).
> 

I recommend you use option 3.  It is the easiest to manage, has the best
performance, and is very scalable.  In the future, you can add additional
security by maintaining an altogether separate authentication server that
runs over SSL.  No more plaintext passwords over the wire, and the performance
hit you suffer is limited to the sign-on process. The only downside it that 
you are requiring your users to enable cookies. They'll get over it :)

> Since a variety of mod_perl, CGI and JSP scripts need to use the
> authentication mechanism, a PerlAuthenHandler seems necessary (it sets
> $ENV{REMOTE_USER}).
> 
> Has anyone of those who have faced a similar problem got any other ideas?
> Suggestions? Success stories?

The eagle book contains an excellent discussion on how to set one up. See

http://www.modperl.org/book/chapters/ch6.html

Then go out and buy it :).

-- 
Joe Schaefer

SunStar Systems, Inc.

Reply via email to