Thank you all for the feedback!
Since I've already handled authentication for browser based logins, I'm
concerned with other (command line or plugin) opendap client login.
Jeff mentioned using Basic Authentication for clients like RAMADDA and
IDV. If I understand correctly, this requires maintaining the user list
in the tomcat-users.xml file. If this is correct, I don't think is not
a viable option to maintain our 9000+ users which we currently maintain
in a mysql database. (I would be very happy to learn that I don't have
a proper understanding of the tomcat basic authentication process, so
please correct me if needed.)
I could envision writing a filter that parses the BA-style url syntax to
obtain the user/pass and then access our mysql users database to
verify. However, when testing our gribcollection best time series with
the IDV (without restriction), the volume of requests to obtain the
subdomain of data was relatively large. My concern is how much overhead
there would be to verify each request via mysql when sent in rapid
succession like that.
If I understand John correctly, clients technically can send a cookie
over the HTTP protocol, but there is no guarantee that a client has this
capability. It would be great if there was something akin to wget's
--load-cookies option for opendap clients. All of this is for the
current (3.7, I believe) version of opendap.
So it sounds to me that my best course of action may be to pursue the
filter option(?) - unless anyone can correct my understanding above or
offer another way to think about this.
-kevin.
On 4/1/13 5:34 PM, John Caron wrote:
Hi kevin:
Cookies are part of standard HTTP, and are passed (both ways) in the
HTTP header. Opendap is built on top of HTTP, and so any opendap
client has a mechanism for passing cookies. Whether they do so or not
depends on the client. I dont think they are required to (?).
Cookies are used to maintain session state on the server. This can
mean that the server only has to authenticate once for a session. That
is mostly just a performance issue, but in the worst case, the client
could pop up a user login window for each request, of which there are
often many for any given dataset access. But the client could also
cache the authentication header and send it each time. So cookies
arent totally necessary, whats really important is that the client
does something reasonable.
There is also a subtle (and usually rare) problem on datasets that can
change while being accessed, when you dont manage state, blogged about
here:
http://www.unidata.ucar.edu/blogs/developer/en/entry/indexed_data_access_and_coordinate
My own opinion is that state is necessary, though perhaps evil. Web
servers like apache and tomcat do all the heavy lifting, so i think
its not a huge burden on server writers. If I was king of opendap i
would specify that clients must return cookies.
I think if you follow standard HTTP practices, and an opendap client
misbehaves, its up to the client to improve or risk becoming obsolete.
There are plenty of robust HTTP libraries in all languages, so there
is really no good excuse for clients not to do something reasonable.
John
On 4/1/2013 11:04 AM, Kevin Manross wrote:
Greetings,
To server our data, we set a cookie once the user successfully logs in
to our website. We check for that cookie upon return to the website. I
have successfully written a filter for our experimental TDS and it seems
to handle web browser interactions by checking for cookies and
redirecting to our login if need be. My next step is how to handle
opendap requests.
I have been reading up on the various ways to authenticate opendap
requests (primarily via THREDDS), many of which refer to the server
setting a session cookie upon successful login. My question is, how is
the session cookie checked upon subsequent requests by opendap clients
like IDL, Matlab, IDV, pydap, etc.?
We have a mechanism to allow users to obtain and store cookie
information for use in non-browser-sessions like scripts. These scripts
usually involve wget which has a way to load cookies. Do opendap
clients have any such way to send a cookie?
This is a major hurdle for our service and any feedback is greatly
appreciated!
Thanks!
-kevin.
--
Kevin Manross
NCAR/CISL/Data Support Section
Phone: (303)-497-1218
Email:manross@xxxxxxxx <mailto:manross@xxxxxxxx>
Web:http://rda.ucar.edu
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
_______________________________________________
thredds mailing list
thredds@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
--
Kevin Manross
NCAR/CISL/Data Support Section
Phone: (303)-497-1218
Email:manross@xxxxxxxx <mailto:manross@xxxxxxxx>
Web:http://rda.ucar.edu
