[Dachs-support] UWS and user access control
Ivan Zolotukhin
ivan.zolotukhin at gmail.com
Mon May 2 21:20:28 CEST 2016
On Mon, May 2, 2016 at 8:34 PM, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> Hi Ivan,
>
> On Mon, May 02, 2016 at 07:39:28PM +0200, Ivan Zolotukhin wrote:
>> I'm sitting on DaCHS revision 5026. Here's the first bug I came across
>> when trying to fetch XML document of the job through the incorrect URL
>> belonging to another service:
>>
>> $ curl -I http://example.com/res/service1/r/uws.xml/VWmNgD
>> HTTP/1.1 303 OK
>> Date: Mon, 02 May 2016 17:30:23 GMT
>> Content-Type: text/plain
>> Location: http://example.com/res/service1/r/uws.xml/http://example.com/res/service2/r/uws.xml/VWmNgD
>> Server: TwistedWeb/15.2.1
>>
>> Note the incorrectly constructed redirect URL.
>
> Whoops -- this is odd, as it would indicate that DaCHS for some
> reason took the entire URL as jobId -- in which case it shouldn't
> find it in the first place.
>
> To get to the base of this (which at first glance is a "this can't
> happen"), can I ask you to put in something like
>
> print ">>>>>>>>>>>>>>>", jobId
>
> above the line
>
> if res[0]["jobClass"]!=self.service.getFullId():
>
> around line 137 in gavo/protocols/useruws.py
>
> and tell me what this prints (use gavo serve debug) when you do your
> request?
Unfortunately I already changed my client (in particular by
introducing username when creating jobs through python's uws-client)
and deleted old jobs, so I can't exactly reproduce same conditions as
before. What I have now is:
For queries to incorrect job URL:
2016-05-02 21:08:12+0200 [-] >>>>>>>>>>>>>>> _RIJl3
2016-05-02 21:08:12+0200 [-] *X*X* 'Service' object has no attribute
'uws' (see info for traceback)
2016-05-02 21:08:12+0200 [-] "10.10.135.118" - - [02/May/2016:19:08:11
+0000] "HEAD /res/service1/r/uws.xml/_RIJl3 HTTP/1.1" 400 - "-"
"curl/7.29.0"
For queries to correct job URL:
2016-05-02 21:09:52+0200 [-] >>>>>>>>>>>>>>> _RIJl3
2016-05-02 21:09:52+0200 [-] *X*X* This resource cannot respond to the
HTTP 'HEAD' method (see info for traceback)
2016-05-02 21:09:52+0200 [-] "10.120.0.14" - - [02/May/2016:19:09:51
+0000] "HEAD /res/service2/r/uws.xml/_RIJl3 HTTP/1.1" 400 - "-"
"curl/7.29.0"
HTTP response is 400 Bad Request in both cases. I don't know if it is
important, but curl request is done without username in HTTP headers.
More information about the Dachs-support
mailing list