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.
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. >> > > >
netcdf-java
archives: