That pathname should be www.modperl.com not www.modperl.org!
Paul E Wilt
Principal Software Engineer
____________________________________________________
XanEdu, Inc. ( a division of Bell+Howell Information&Learning)
http://www.XanEdu.com
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
300 North Zeeb Rd Phone: (734) 975-6021 (800)
521-0600 x6021
Ann Arbor, MI 48106 Fax: (734) 973-0737
____________________________________________________
-----Original Message-----
From: Joe Schaefer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 26,2000 1:18 PM
To: [EMAIL PROTECTED]
Subject: Re: Authenticated Sessions, Performance
"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..
