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 >