search

conwetlab / ckanext-oauth2

OAuth2 support for CKAN
GNU Affero General Public License v3.0
25 stars 56 forks source link

Call is being made to naked domain, not www. #27

Closed jeverling closed 5 years ago

jeverling commented 6 years ago

Hi, first of all thanks for this great extension! I was trying to set up oauth2 authentication with a provider that is running under a www. subdomain. It has a valid wildcard certificate, but no Subject Alternative Name for the naked domain without any subdomain.

The extension was displaying (insecure_transport) OAuth 2 MUST utilize https., but all configuration values were using the www. prefix and after setting OAUTHLIB_INSECURE_TRANSPORT=True it worked fine. Does anybody have an idea why the extension might end up doing a call to the naked domain without the www. prefix (or at least trying to verify the certificate for that domain), despite it being present in all config values?

aitormagan commented 6 years ago

Can you, please, tell us which IdM are you using so we can test with it?! The case you mention is very strange as we do not convert (as far as I remember) the URL you provide in any way. Maybe it's a problem with the library we are using to do the calls :(

jeverling commented 6 years ago

Hi Aitor, I was using https://github.com/jazzband/django-oauth-toolkit as provider. I think the call (or at least verification against the naked domain) happens in

        try:
            token = oauth.fetch_token(self.token_endpoint,
                                      headers=headers,
                                      client_secret=self.client_secret,
                                      authorization_response=toolkit.request.url,
                                      verify=self.verify_https)
        except requests.exceptions.SSLError as e:
            # TODO search a better way to detect invalid certificates
            if "verify failed" in six.text_type(e):
                raise InsecureTransportError()
            else:
                raise

which uses requests-oauthlib so it may very well be an upstream problem.

We fixed the certificate, so it includes the naked domain, but I'm still seeing the same error without OAUTHLIB_INSECURE_TRANSPORT, so either it's some caching effect or it's a different cause.

Unfortunately I currently don't have a way to reproduce it properly and no time to debug it, but I'm planning to do that once time permits. I just thought maybe someone had encountered the same problem before.

jeverling commented 5 years ago

I'm going to close this for now, as I can't rule out it was some fluke specific to our setup. If I manage to reproduce this properly one day I will re-open.