I wonder if you could fake it using EZProxy, which does a good job of
managing cookies for proxied resources. Have the metasearch process start an
EZProxy session and then hand that over to the user. If the metasearch
process and the EZProxy server were at the same domain, they could share
cookies. I'm not sure if EZProxy would complain if a session were accessed
from different IP addresses (should be ok, given AOL proxy farms etc.), or
if a user might end up with multiple conflicting EZProxy sessions ... There
must be something else I'm missing...

Peter

Peter Binkley
Digital Initiatives Technology Librarian
Information Technology Services
4-30 Cameron Library
University of Alberta Libraries
Edmonton, Alberta
Canada T6G 2J8
Phone: (780) 492-3743
Fax: (780) 492-9243
e-mail: [log in to unmask]



> -----Original Message-----
> From: Kevin S. Clarke [mailto:[log in to unmask]]
> Sent: Monday, March 15, 2004 11:36 AM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Remote authentication cookies (was
> Re: [CODE4LIB] index of open access journals)
>
>
> On Wed, 2004-03-10 at 10:13, Walter Lewis wrote:
>
> > At the risk of changing the subject line, I'm curious if anyone has
> > solved the problem of remote authentication cookies in the
> context of
> > this class of parallel federated searching.
>
> Sorry for the delay...
>
> We haven't solved it.  We have a servlet that takes the query
> and spawns a thread for each engine it wants to query.  It
> gathers the results in a results list and then post-processes
> (filters) them (renames resources, sorts, categories, etc).
> What the patron gets is a list of resources arranged by
> category with a hit count for each resource (some engines,
> like SKOLAR.com, provide multiple resources and simplify the
> problem of remote authentication by doing it for us once).
> We are fortunate that many of our resources do do IP
> authentication or are provided in the context of an
> aggregator, like SKOLAR.  We have a few though that, when the
> patron clicks on the link next to a hit count, will require
> that s/he login (MD Consult for instance).  Solving cookies
> would solve that but I think we decided we didn't want to
> solve that problem because MD Consult would not like, and
> perhaps not allow, us to allow patrons to bypass their
> authentication (maybe this is just defining the problem
> away).  Once the patron logs in, though, s/he is taken
> directly to the results of the search.  We are approaching
> early testing so will see if patrons like this or not...
>
> I too am interested in hearing if others have solved the
> cookie problem.
>
> Kevin
>
> --
> Kevin S. Clarke ([log in to unmask])
> Digital Information Systems Developer
> Lane Medical Library, Stanford University
>