openURL not respecting Authentication object's verify property

[tpedelose]

When an Authorization object is passed to openURL(...) through the creation of a "service" object (WebFeatureService, WebMapService, etc.), the default value of verify overrides the value of auth.verify. It is also notable that the Authorization object is mutable; Thus, auth.verfiy can be overwritten to True for subsequent use.

See the offending logic here: https://github.com/geopython/OWSLib/blob/03a0083e73690a43cd9a9c86fcf9107bc126f406/owslib/util.py#L174-L175

verify	auth.verify	verify & !auth.verify	...result
T	T	F	auth.verify stays True
T	F	T	auth.verify gets overwritten to True
F	T	F	auth.verify stays True
F	F	F	auth.verify stays False

Solutions:

1. Only take Authorization objects in openURL(...) Since you already have this object that contains all authorization values, let's use it! Remove username, password, verify, and cert from the function. Every calling function would either need to create it's own Auth or pass one that was given to it. Since creating an Auth sets verify to True this defaults to being secure unless a function overwrites it.

2. Remove auth from openURL(...) Seems like a step backwards, but you could just make every calling function split out the contents of an Authorization object.

3. Change logic to respect any turning off of SSL verification. Logic: if not verify or not auth.verify: verify = False . Also, removes the issue of overwriting auth.verify to False when it's initially True (other properties will need similar treatment).

[tpedelose]

In my case, I'm working in an environment where I need to turn off SSL verification in order to access several different geoservers through a (reverse) proxy service.

I'll attempt to tackle this on my end when I get the chance, but any one else who wants to try solving it should feel free to do so.

[justb4]

At some point the whole Auth/Headers/Username/Password parameter-handling needs to be revised. e.g. for #587 I needed to pass HTTP Headers for most APIs, as the 'Auth-method' did not support Bearer Token Auth, and even if it did there are specific cases where e.g. ESRI requires an esri-auth HTTP header. Passing all these loose parameters around looks messy, a single extensible Context/Auth class object as parameter would be cleaner. E.g. with the possibility to add Auth HTTP headers to this Auth object.

[tpedelose]

Would it be a worthwhile idea to allow the user to pass a requests Session object? Authentication, SSL verification, cookies, and any headers could all be handled by this. I wrote a basic WFS module that is using this method. It's been working fairly well for my use case.

[justb4]

@tiranno on using requests Session: sounds like a good direction with what I denoted as Context. Though Session would expose internal implementation, it would be overkill to replicate all Sessions functions in an OWSLib-specific Context. All the loose parameters for Auth, User, Passwd, Headers, etc would be nicely bundled (in Session) and re-applied on subsequent requests on a single OWSLib Service object.

[cehbrecht]

@tiranno @justb4 @tomkralidis Sounds like using requests Session could be an approach we could try. Maybe open a new issue for this? First I would like to get the current issues solved in the current state and make a patch release ... otherwise I can not use the current owslib with HTTPS.

[cehbrecht]

PR #611 is just a fix for wps module.

[justb4]

@tiranno @justb4 @tomkralidis Sounds like using requests Session could be an approach we could try. Maybe open a new issue for this? First I would like to get the current issues solved in the current state and make a patch release ... otherwise I can not use the current owslib with HTTPS.

I support requests Session approach, after cleaning up current Auth/Headers issues.

[gilav]

Hello

I just crash into this issue, and lost quite some time. First I was thinking my certificates were wrong, so I try the auth.verufy = False, and the lib was doing just the same. And after some searching I modify the util line 174 as TylerPedelose did. So I support that this issue is ennoying.

I have a question: did someone had an example of working https request to a WFS server? I created my certificate using win-acme, I got xxx-cert.pem + xxx-key.pem + xxx-chain.pem files. When put inside a apache server, online verification of the certificates find them all ok.

I call the WebFeatureService like this:

auth = Authentication(verify=False, username='guest', password='guest', cert=['a-cert.pem', 'a-key.pem']) url='https://awfs-service'

wfs11 = WebFeatureService(url=url, version='1.1.0', auth=auth) print(" wfs11.identification.title: %s" % wfs11.identification.title) print(" operation.name: %s" % [operation.name for operation in wfs11.operations]) print(" wfs11.contents: %s" % wfs11.contents)

I try various way of using the sertificates files in the auth dreation, but everithing fail. Any help apreciated...

thanks

Best regards

Gilles