Here's my proposal for authentication. I hope this will help with the anti-cookie people in the crowd. Note, after writing all this out, I found a module called mod_auth_tkt which apparently does most of the cookie part of this. Might be better to implement it ourselves, as it makes one less apache configuration problem on installation. 1. Every script calls a checkauth($query) routine before doing anything else. 2. checkauth() checks for a $ENV{'REMOTE_USERNAME'} environment variable. a. If one is set, assume that basic authentication of some sort is being used b. check that this user is allowed to be running this script. If not, print a warning page and exit (possibly redirect to library home page or somesuch?). c. return a zero value and the userid logged in and the script carries on. 3. checkauth() looks for the value of a sessionID cookie in the $query hash. a. If it doesn't find one: * present a log in screen where the user can enter a username and password. * The name of the original script and any query parameters are stored as hidden query params. * authentication script checks the entered username and password against a configurable authentication source (eg local mysql table, passwd file, ldap, pop server, you name it) and stores the sessionID, userid, remote ip address and lastcontact (current time) in the sessions database table. b. If it finds one: * look up the userid, ip address and lastcontact values from a database table (sessions) for this sessionID. If ip address is the same, and lastcontact is recent enough for this category of user (eg librarians might time out after 30 minutes, patrons after 5 minutes) then return a zero value, the userid logged in, and a cookie to be added to the HTML header and the script carries on. * If ip address is different, display a warning page and exit. (Note that this doesn't prevent the same user from logging in from two different ips simultaneously, as they would normally have different sessionIDs. It just protects (somewhat) against somebody hijacking the cookie and the session. * If lastcontact time has expired, remove the session from the sessions table and display a login screen (as in 3a above). Modifications to existing scripts consist of calling: my ($userid,$cookie)=checkauth() at the top of every script and changing: print $input->header; to if ($config->{'usecookieauth'}) { print $input->header(-cookie->$cookie); } else { print $input->header; } Steve.
Hi - to be honest I've no idea wether this addresses my concerns about cookies - the best I can do is restate what I think the bottom lines are... All my concerns are to do with the OPAC - I'm not at all bothered about the intranet. 1/. A member of the public must be able to search/use the catalogue without having cookies turned on. For one reason or another there will be people who don't/can't/won't use cookies, they shouldn't be barred from the OPAC because of it. 2/. For it to be useful for a public library I would think that the public should be able to use *all* parts of the OPAC without having cookies turned on - even the bits where they need to authenticate.
On Mon, 8 Jul 2002, Rachel Hamilton-Williams wrote:
All my concerns are to do with the OPAC - I'm not at all bothered about the intranet.
1/. A member of the public must be able to search/use the catalogue without having cookies turned on. For one reason or another there will be people who don't/can't/won't use cookies, they shouldn't be barred from the OPAC because of it.
Absolutely. The checkauth() routine will accept an option stating whether authentication is mandatory or not. If it _is_ mandatory, checkauth will display a login screen if the user is not authenticated. If it is _not_ mandatory, checkauth will return a NULL userid to the calling script signifying that the user is not authenticated. Most OPAC functions will work just fine without authentication, but will probably provide personalized functions if authenticated. Things like saved item lists, where you can check a box beside search results and they will be added to a list of items you are interested in.
2/. For it to be useful for a public library I would think that the public should be able to use *all* parts of the OPAC without having cookies turned on - even the bits where they need to authenticate.
First of all, Auth.pm will support either cookies or basic authentication, so a library can opt to use no cookies whatsoever. It will also be possible to use both by creating an alternative VirtualHost for the OPAC which uses basic authentication. At the cookie-based login screen, the user can be offered the choice of logging in without cookies by linking to the basic authentication virtual host for the opac. In this way, library search stations could be configured to use cookie-based authentication, enabling the timed logout feature, while patrons from home can log in without cookies. I think we've got all the bases covered here. Now as to whether we go with my home rolled session code, or use mod_auth_tkt (which is a third party apache module not included with the apache distribution), that discussion will have to join the checkvalidisn() discussion. :) Steve.
participants (2)
-
Rachel Hamilton-Williams -
Tonnesen Steve