[Inteproxy-devel] Inteproxy query... (fwd)

[Bernhard Herzog]

Hi,

On 28.11.2008, Stephan Holl wrote:
> > In my own investigations I notice that when I enter the WMS into my
> > browser I am prompted for a username and password first by a inteproxy
> > popup window... Then again by a regular browser popup as if I had
> > directly typed the full https
> > (https://secure.wms.defra.gov.uk/SPIRE_WMS/WMS?SERVICE=WMS&REQUEST=GetCap
> >ab ilities) without using inteproxy.
> >So it appears inteproxy is requesting a
> > username password but not passing it on to the remote wms server perhaps?
>
> Lets see in the logs below.
[snipped analysis of the request generated by InteProxy]

The request does indeed look OK.

> >DEBUG: request sent
> > localhost - - [27/Nov/2008 09:11:00] DEBUG: HTTPResponseMessage:
> > HTTP/1.1 302 Moved Temporarily
>
> I am not 100% sure, but I think that this 302 is the problem. I cannot
> clearly describe the problem and leave that to someone more knowledgeable.
> I could guess, that this redirect also throws the basic-auth headers away
> and therefor the browser needs to aquire them again, which leads to the
> problem you have.

InteProxy passes this 302 response from the server through to its client, 
which then has to react to it.  302 means that the client should access the 
resource it wants to get via another URL, which is given in the Location 
header of the response:

> > localhost - - [27/Nov/2008 09:11:00] DEBUG: header: content-length:'5240'
> > localhost - - [27/Nov/2008 09:11:00] DEBUG: header: via:'1.1
> > secure.wms.defra.gov.uk (Alteon iSD-SSL/4.2.1.11)'
> > localhost - - [27/Nov/2008 09:11:00] DEBUG: header:
> > set-cookie:'AlteonP=f4e8b939f4e8b937baefbbd3; path=/,
> > PD-H-SESSION-ID=4_z+hWx2lO1HA5RVGwmbmddEHXhA9uzb8U3HF3FS3ZJJMl9WFI;
> > Path=/' localhost - - [27/Nov/2008 09:11:00]

> > DEBUG: header: 
> > location:'https://secure.wms.defra.gov.uk/caraeai/CARAEAInterface?TAM_OP=
> >lo gin&ERROR_CODE=0x00000000'

This is the URL the server wants the client to access.  Since it's a https URL 
the client will try to access it directly, bypassing InteProxy.  If it gets 
back a 401 (Unauthorized) response, it will ask for a username and password.

Even if the client could access this new URL via InteProxy, InteProxy could 
not access or modify the communication between client and server because it 
would be encrypted.  What InteProxy could do, though, is rewrite the URL in 
the Location header of the 302 response in the same way as it would rewrite 
URLs in the body if it's started with the --rewrite-urls option.  That way, 
the new request from the client would go through Inteproxy again, if the new 
URL is one that InteProxy knows about.

Another potential cause for the problems is that server tries to set cookies 
(see the set-cookie headers in the response).  InteProxy doesn't do any 
cookie handling itself.  If the server requires those cookies to be sent in 
the WMS requests, it's the reponsibility of the client to do so, right now.

> >localhost - - [27/Nov/2008 09:11:00] DEBUG: 
> > header: pragma:'no-cache' localhost - - [27/Nov/2008 09:11:00] DEBUG:
> > header: cache-control:'no-cache' localhost - - [27/Nov/2008 09:11:00]
> > DEBUG: header: date:'Thu, 27 Nov 2008 09:10:59 GMT'
> > localhost - - [27/Nov/2008 09:11:00] DEBUG: header: p3p:'CP="NON CUR
> > OTPi OUR NOR UNI"'
> > localhost - - [27/Nov/2008 09:11:00] DEBUG: header:
> > content-type:'text/html' localhost - - [27/Nov/2008 09:11:00] DEBUG: body
> > may be present but has not been read yet
>
> there is no header: authorization:'Basic...' in there.

That's normal in a server response.

> I might think that you need to investigate the WMS-Server and its
> redirect-techniques to get a solution?!

I think we should try to figure out why the server sends a 302 response.
What happens if you access 
https://secure.wms.defra.gov.uk/SPIRE_WMS/WMS?SERVICE=WMS&REQUEST=GetCapabilities
directly through a web-browser?  You said that the browser asks for a 
password, which would mean that the server did not send a 302 response, but a 
401 (Unauthorized) response with a WWW-Authenticate header field.  This is a 
bit strange, but it might depend on the values of some header that the 
browser sends but is not sent by QGIS, or that has a different value in the 
request sent by QGIS.  Web-servers often use the User-Agent header for this 
kind of thing.

Regards,

  Bernhard

-- 
Bernhard Herzog  |  ++49-541-335 08 30  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.wald.intevation.org/pipermail/inteproxy-devel/attachments/20081128/b48491ac/attachment.pgp