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