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.
>>
>
>
>
