NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi John, It's not a caching problem - it's an API problem. Currently there is exactly one HttpClient that is shared between all OPeNDAP connections (it's a static field in the libraries). There is also exactly one CredentialsProvider. The CredProv API allows me to return exactly one username/password combination for each host:port, but I want it to return a different combination depending on who is logged in. In a client environment like ToolsUI you can pop up a dialog asking for credentials, but in a server environment you can't do this because one VM (and hence one HttpClient object) is shared between all users. I would really like NetcdfDataset.open() to be able to accept Credentials that it will use for any http connections it makes. Then I have close control over the credentials are passed to the server. Cheers, Jon On Sun, Feb 8, 2009 at 11:56 PM, John Caron <caron@xxxxxxxxxxxxxxxx> wrote: > In thinking about this issue again, I realize that Ive forgotten exactly how > the CredentialsProvider > works, for example, here we popup a dialog when challenged: > > CredentialsProvider provider = new > thredds.ui.UrlAuthenticatorDialog(frame); > HttpClient client = HttpClientManager.init(provider, "ToolsUI"); > > Im guessing that the problem is that org.apache.commons.httpclient caches > credentials, so it doesnt > call your CredentialsProvider after it accesses the site once. > > Perhaps theres a setting in httpclient that controls caching? In any case, I > suspect theres an > answer in there for us. > > If you get a chance to investigate before I do, let me know. > > http://hc.apache.org/ > > Jon Blower wrote: >>> so we need some hooks into HttpClient. If you have any concrete API ideas, >>> send them over. >> >> I was thinking that there could be an optional argument to >> NetcdfDataset.acquire() and its friends, allowing the client to >> specify the HttpClient object to use. Or maybe the Credentials >> object. Or maybe even a username/password, although this wouldn't >> help for client-authenticated SSL. >> >> Jon >> >> 2009/1/20 John Caron <caron@xxxxxxxxxxxxxxxx>: >>> >>> Jon Blower wrote: >>>>> so the remote site issues a challenge. do you just pass it on to your >>>>> user at her web page, or have you cached her credentials? >>>> Currently I imagine that the credentials (which may be a Grid proxy >>>> certificate, boo hiss) will be cached on the server. I was thinking >>>> that the user would log on to my web app, thereby creating a session >>>> object in which we can cache credentials. >>> >>> so we need some hooks into HttpClient. If you have any concrete API ideas, >>> send them over. >>> >> >> >> > -- Dr Jon Blower Technical Director, Reading e-Science Centre Environmental Systems Science Centre University of Reading Harry Pitt Building, 3 Earley Gate Reading RG6 6AL. UK Tel: +44 (0)118 378 5213 Fax: +44 (0)118 378 6413 j.d.blower@xxxxxxxxxxxxx http://www.nerc-essc.ac.uk/People/Staff/Blower_J.htm
netcdf-java archives: