> for the users? Too complicated?
no i don't think it's too hard for users. when they contact us to use OPeNDAP
- we tell them their Project 'username'
- we tell them their Project 'password' and how to change it
(its important that they control access to their data)
- we tell them were to put their data on our system so that
OPeNDAP can distribute it
- we tell them the URL to access it
I could also provide and authenitcation free server for public data
should we ever get any.
> Things that we should think of for the future? Worth it? >
I'd like to see the URL evolve from host/cgi-bin/OpenDAP/MyProject/nph-dods/myfile.nc to host/cgi-bin/OpenDAP/nph-dods/MyProject/myfile.nc that is, instead of one OPeNDAP
server for each project authenticating
in its built in data space, move to one OPeNDAP server for all
projects, authenticating in the user specified data space.
> As project manager, I would be interested not only in your comments re > the security part, but also in how CSIRO plans to use OPeNDAP
and what > we can do to facilitate that use in the future. We would also be
> interested in listing on our "Data set list" any data sets that you
> plan to open for public access.
>
I think the environment in which data provision is ocurring will become less and less open, and more and more people will encounter the locked-down environment in which I am operating. So I think OPeNDAP
might be redesigned so that
operating in the open model (public data, direct visible server)
is just as easy to operate as the more secure environment (private
data, server behind proxy).
It needs to look at the authentication bypassing of the support
programs (curl, www_int etc) which forces you to run
the server in a separate machine if you really want data security
(right now, anybody operating a browser or other client in the host that
is running OPeNDAP could get to anybody's data without authentication
if they knew how). Using the webserver Directory config directives to
bypass authenitcation is not a robust model in my (very limited) opinion.
Also the fact that the support programs get to the data via one of
webserver (e.g. curl), directly to directory or via the OPeNDAP server
is somewhat confusing for the beginner, and makes understanding and
getting the configuration right (when having to modify it) a bit
complicated.
In the context of all this would be looking at the passing
along of the URLs so that they are the right ones from the
inside (internal server) and the outside (proxy)
> Peter >
> p.s. Thanks for your patience in working with us and for the hard work
> that you have put into this. I'm sure that others will appreciate it as
> well.
>
no problem. In the end, the changes were not that great. My learning curve was a bit steep as this is the first time I have had to play with web servers too. However, the solution was a bit fiddly and probably is not very robust to configuration changes that might go on around me. Support from the list and from James was very good; the main hassle with all these things is the time differential from Aus to the USA which often makes for a slow turn around. cheers Neil -- JamesGallagher - 17 May 2005
- DODS_Dispatch.pm.Killeen: MOdifications to DODS_Dispatch.pm
- nph-dods.Killeen: Modifications to nph-dods
- opendap-note.Killeen.pdf: Guide to using the modifications
