Open tpedelose opened 4 years ago
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.
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.
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.
@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 Session
s 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.
@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.
PR #611 is just a fix for wps module.
@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.
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
When an Authorization object is passed to
openURL(...)
through the creation of a "service" object (WebFeatureService, WebMapService, etc.), the default value ofverify
overrides the value ofauth.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
auth.verify
stays Trueauth.verify
gets overwritten to Trueauth.verify
stays Trueauth.verify
stays FalseSolutions:
Only take Authorization objects in
openURL(...)
Since you already have this object that contains all authorization values, let's use it! Removeusername
,password
,verify
, andcert
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 setsverify
to True this defaults to being secure unless a function overwrites it.Remove
auth
fromopenURL(...)
Seems like a step backwards, but you could just make every calling function split out the contents of an Authorization object.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 overwritingauth.verify
to False when it's initially True (other properties will need similar treatment).