Hi John,
> Are you managing a database of user/password credentials for the various
> remote sites?
Yes, but currently I'm limited to one user/password combination for
each site, which won't work for me in a particular project.
> Another design is that ncWMS has a single logon to each of your remote sites.
Unfortunately I can't do this. The remote site needs to know exactly
who is using ncWMS.
Thanks, Jon
2009/1/19 John Caron <caron@xxxxxxxxxxxxxxxx>:
> Hi Jon:
>
> Are you managing a database of user/password credentials for the various
> remote sites?
>
> Another design is that ncWMS has a single logon to each of your remote sites.
> Give each remote site a role, and manage access to them through standard
> role-based tomcat authentication, ie users are given that role if they have
> authorization.
>
> I have some more thoughts about what to do if that doesnt work.
>
> John
>
>
>
> Jon Blower wrote:
>> Hi,
>>
>> Accessing OPeNDAP or remote NetCDF files in nj4.0 uses the Apache
>> Commons HttpClient library. If my understanding is correct then nj4.0
>> uses the same HttpClient instance for all connections, and this
>> instance is set with static methods:
>>
>> opendap.dap.DConnect2.setHttpClient(client);
>> ucar.unidata.io.http.HTTPRandomAccessFile.setHttpClient(client);
>>
>> In my case, I have a Java web application (running in a single VM)
>> accessing lots of remote servers via HTTP. The entire application
>> uses the same HttpClient instance, and therefore there is no way to
>> distinguish between the users of my application. Say I have two users
>> going via my application to the same secure OPeNDAP server. My
>> application can only associate a *single* username/password
>> combination with the host:port of the OPeNDAP server, following the
>> Credentials framework in HttpClient. There is no way to register two
>> different username/password combinations for the same remote server.
>>
>> One possible way to fix this would be to allow each NetcdfDataset to
>> be associated with its own HttpClient instance. This could be
>> provided as an optional parameter to openDataset(), defaulting back to
>> the VM-wide one if omitted. Then I could store an HttpClient (with
>> associated credentials) in the user's session object in my
>> application. (I am not sure if this is good practice for HttpClient
>> though.)
>>
>> Is this easily remedied or a tough job?
>>
>> Cheers, Jon
>>
>
--
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
