UWS joblist implementation issues

[Paul Harrison]

On 2011-03 -02, at 23:03, Norman Gray wrote:

> 
> Pat, hello.
> 
> On 2011 Mar 2, at 21:41, Patrick Dowler wrote:
> 
>> 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
> 
> I see that the UWS spec says, in reference to the job list, that
> 
>> The job list may be read to find the extant jobs.
> 
> I don't know if that's an RFC2119 MAY, but I would find a 403 response at least unexpected, given that text.  Since the user is presumably identified at this point (and would be identified and authorized if they're looking at this after a DELETE operation), couldn't you just show the list of extant jobs that the user has access to?
> 
> In any case, GETting the resource /joblist is supposed to return 'a representation of the resource'.  You could try returning an HTML page that said simply "yes, there are jobs".  That's not a terrifically _useful_ representation, and is rather stretching the spec text, but it's a little more useful than simply 'forbidden'.
> 
> All the best,
> 
> Norman
> 

My thoughts on this (though probably not expressed clearly enough in the spec) were that the intersection of security and UWS was intended to result in the user seeing the list of jobs that they were permitted to see - this might result in a null list, so I think that I am with Norman on this, that a 403 is a little unexpected in this case (though a client should be able to deal with it).  In Pat's service where the user has authenticated themselves, then it would be easy to list only the jobs that belong to the user.

On 2011-03 -02, at 21:41, Patrick Dowler wrote:
> 
> 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??
> 

There was a general change to a pattern where the redirects went to the joblist as it was felt that this made for a nicer implementation/user experience when driving via a web browser.

> 
> 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 :-)
> 

According to the IVOA standards we are only allowing rather strong authentication via X509 certificate as you say - it might be time to review again whether we allow some of the less strong authentication mechanisms that exist for SSO. Perhaps a topic for the May interop? Along with ideas for features to add to make a UWS 1++..

Cheers,
	Paul.