No subject


Wed May 26 14:59:14 CEST 2010


countries are run by local or central Government)

It is acceptable to use cookies only where absolutely necessary for the function 
performed (e.g. personalisation or e-commerce). Cookies should not be required for 
random searching or browsing. Agencies should understand (and document in detail) 
the purpose of any cookies used on their site. Agencies should not require the use of 
cookies for access to the base functionality of the site.
Many users tend to have cookies turned off to avoid privacy invasion by commercial 
sites. If agencies are relying on cookies to provide visitor statistics, these users will not 
show and the statistics will be inaccurate. 
The site should contain a clear statement of policy on the use of cookies including why 
they are being used and what information is being recorded or relayed. Sites should 
not collect user information unless it is required for the business of government that the 
user wishes to undertake. Agencies should also undertake to advise users explicitly if 
information collected is to be shared with other agencies.




 
> 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.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/koha-devel
> 


_____________________________________________________________

Rachel Hamilton-Williams             Katipo Communications            
WEBMISTRESS                          ph  021 389 128 or +64 04 934 1285 
mailto:rachel at katipo.co.nz           PO Box 12487, Wellington
http://www.katipo.co.nz              New Zealand
Koha Open Source Library System
http://www.koha.org






More information about the Koha-devel mailing list