On 4/2/2013 2:43 PM, Nathan Potter wrote:
On Apr 2, 2013, at 1:27 PM, Kevin Manross wrote:
Thank you very much, Nathan (as well as Dennis and Bob). This is terrific
information.
The JDBC Realm info is something I'm digging into. I'll need to discuss with
our working group whether certificates are an option or not.
Nathan, you mention "once you have your credentials (session cookies) then the client should
be able to return the cookie to Tomcat with subsequent requests". Is this all done
"under the hood" with clients that can handle cookies?
I think the answer is yes, with the caveat that to get the client to behave
this way there may be some extant configuration issues...
Can you provide an example of an opendap client that handles/uses cookies?
I may have mentioned previously that we have a utility to allow users to obtain
a cookie file and then they can send that cookie with wget or curl. Is there
any such mechanism for any opendap client that you are aware of, or should I
let go of this concept?
I may be way off base here but I thought that all the clients that are based on the java
netCDF "client" library (Panoply, ToolsUI, etc) did this by default. Maybe
someone from UNIDATA that actually knows about this can jump in here?
Correct, we use the HTTPClient library that handles all this under the
hood for anyone using opendap from the java netCDF library in their client.
Similarly, using opendap from the netcdf C library also handles
authentication and cookies.
If anyone would like to send in user experiences around authorization /
authentication from both client and server POV, it would be appreciated.
Do we know of opendap clients that dont handle these well?
Again - I don't see this as a DAP issue insofar as it's an issue between the client and
the server that happens out-of-band from the DAP transaction. It is a DAP issue in that
the clients may or may not provide reasonable facilities for performing and
"persisting" authentication states which may result in some clients being
locked out of some resources.
The info is in the HTTP headers of the DAP requests; so its not part of
DAP itself, its part of the HTTP layer.
John
