UWS joblist implementation issues
Patrick Dowler
patrick.dowler at nrc-cnrc.gc.ca
Wed Mar 2 13:41:20 PST 2011
In implementing the joblist resource, we obviously allow POST and redirect the
client to the job, e.g. /joblist/<jobID>. However, we decided in our trivial
implementation to not allow the client to GET the joblist. We simply return an
HTTP "forbidden" (403) response. This is not in conflict with the UWS spec and
it protects users of our system from others looking at their jobs (TAP
queries, VOSpace transfers, etc), although that protection is "security-by-
obscurity" (jobID is a random 16-character alpha-numeric string). See also PS
below
In our implementation, we generally keep the jobs for a long time, so the
complete job list may be very large (currently ~462,000 jobs). We could keep
it manageable by deleting jobs after some time (as described in the
destructionTime field) but the output of GET /joblist could be a large-ish XML
document.
The odd part:
We recently (finally) implemented support for user deleting a job. The odd
thing about this is that when you do DELETE /joblist/<jobID> the response is
supposed to redirect the caller back to the (modified) /joblist. In our current
implementation, that would result in a forbidden response: *not* forbidden to
delete the job (it will be deleted) but forbidden from seeing the resulting
joblist. That's definitely going to be odd.
For now we will, stick with a private joblist but I am curious what people
think. I am 99% sure that the UWS draft used to say that the response from a
DELETE was a 204 (no content) and I definitely think that better isolates this
operation. Any recollection on this change??
PS - In our web services we support both anonymous (http) and authenticated
(https w/ X509 certificate) access.We have implemented an authorization check
on the job itself: if you authenticate when you create the job, the owner ==
DN (from the cert) and only that owner can access the job afterward. This is a
real security measure that anyone authenticating can take advantage of, but I
suspect that users really expect even their anonymous activity to be private
so it might not be sufficient to only offer privacy as an opt-in feature :-)
--
Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7
Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7
More information about the grid
mailing list