Authentication

[davidcaron]

Description

Regarding authentication, right now owslib passes username and password directly to the requests library, which uses basic auth.

What would be nice is if owslib could accept an authorization object that was passed directly to requests (see: http://docs.python-requests.org/en/master/user/advanced/#custom-authentication)

I'm opening this issue because I wanted to get your opinion on adding authorization helpers for some providers (that wouldn't mean modifying owslib).

Right now, I would only be interested in Magpie:

def magpie_auth(url, user_name, password):
    response = requests.post(
        url,
        data={
            "user_name": user_name,
            "password": password,
            "provider_name": "ziggurat",
        },
    )
    response.raise_for_status()
    return {"Cookie": "auth_tkt={}".format(response.cookies["auth_tkt"])}

And we could use it like this:

headers = birdy.auth.magpie_auth("your_url", "your_username", "your_password")
import_wps("wps_url", headers=headers)

[huard]

Sounds good. How hard would it be to have this work with OAuth2 ? This is what is used by ESGF WPS services ? See https://aims2.llnl.gov/wps/home and https://github.com/ESGF/esgf-compute-api for examples of another user interface to WPS processes.

Note that for scientists, the word "headers" does not carry the same meaning as for a programmer. I would suggest using "auth" instead or something along these lines.

[cehbrecht]

You can pass headers to OWSLib which are send by requests. See the birdy command line how it is used for tokens and client certificates:

birdy/birdy/templates/cmd.py.j2

Line 27 in 53cb0ba

headers = {'Access-Token': ctx.obj['token']}

[davidcaron]

You can pass headers to OWSLib which are send by requests. See the birdy command line how it is used for tokens and client certificates:

birdy/birdy/templates/cmd.py.j2

Line 27 in 53cb0ba

headers = {'Access-Token': ctx.obj['token']}

Maybe we could replace these 3 parameters username password and headers with a single one named auth and implement some provider specific classes. So the user would do something like:

auth = birdy.auth.magpie_auth("your_url", "your_username", "your_password")
import_wps("wps_url", auth=auth)

and internally we would set the correct headers and cookies depending on the auth implementation. It's not very far from what requests does: http://docs.python-requests.org/en/master/user/advanced/#custom-authentication

Regarding Oauth2, I've found this: https://github.com/jupyterhub/oauthenticator
I'll try to test it next week.

But basically the user would do something like:

auth = birdy.auth.OAuth2Implementation()  # trigger a login in the default browser?
import_wps("wps_url", auth=auth)

and before each request we would set the Authorization bearer token.

[huard]

For ESGF servers: https://pydap.readthedocs.io/en/latest/client.html#earth-system-grid-federation-esgf

[huard]

Note that at the moment, if I try to access PAVICS services behind twitcher, I can hit GetCapabilities and DescribeProcess, but for Execute I get an uninformative error message (ie it's not picked up by our try statement in _execute). Once I open a session on the PAVICS frontend and rerun WPSClient, then I can execute requests.