Option to init without full redirect_uri

[lucasdurand]

In some cases, specifying the full redirect URI limits the ease of generalising Flask deployments, especially when the server port and/or host isn't known until after the application is running. One example would be if the Flask app is launched through gunicorn.

Being explicit about the redirect_uri does seem to be a good general practice, but having the option to fallback to "{this_app}/{OIDC_REDIRECT_ENDPOINT}" would help in this scenario.

Currently something in the spirit of this can be accomplished by patching the PyOIDC clients on app launch using the flask base_url:

auth = OIDCAuthentication({"name": config})
app.config.update(OIDC_REDIRECT_URI="http://some-dummy-value/redirect_uri")

@app.before_first_request
def patch_redirect_uri(): # this will be patched in time for the first auth flow
    auth.clients.get("name")._redirect_uri = request.base_url+"redirect_uri" 

This could be smarter, pulling the endpoint name from app.config["OIDC_REDIRECT_ENDPOINT"], or from the dummy value above, as long as we match the Flask routes that are created during init_app

[lucasdurand]

Thinking more, this workaround might be total garbage, but would be good to get insight on falling back to the url_root

[zamzterz]

I'm not entirely familiar with running a Flask app via gunicorn, so why would you not know the full address for your application beforehand? Is it for local testing?

The most common use case for this lib is with statically registered clients, meaning they have already registered the redirect URI with the provider. So it's known beforehand and can easily be configured in the app as well. Also, most internet-facing apps has a registered domain name that should be used for the redirect_uri. Hence I'm a bit wary of including behaviour of computing the redirect_uri dynamically.

If your suggested workaround (patching the redirect_uri in before_first_request) works, then I think that's best option for now (just note that it's using internal implementation details with which are not guaranteed across versions). 🙂

[lucasdurand]

Partially useful for local testing, but moreso if you were deploying multiple applications behind a single domain with some dynamic proxy naming happening. You have a good point that in general for any meaningful deployment you know the port / domain / full address of where it will be!