State mismatch when using flask-session with identity.web

[phsyn]

Background:

• Using Flask with Redis Flask-session to persist server-side user sessions
• Flask is running on Gunicorn with multiple workers
• Using identity.web instead of identity.flask so I don't need to use the decorator (the Flask app wraps a Plotly Dash page, so I don't want to use the decorator and instead just redirect any unauthorized users to the login page)

With the setup described above, I'm getting intermittent state mismatch errors when calling complete_log_in. I believe this is caused when the auth response is handled by a different worker than the one that initiated the auth flow. I can see that the Flask session.sid is the same, so I believe that the Flask-session setup that I have is working correctly. However, the state in the auth code changes between the requests. If I reduce the number of Gunicorn workers to 1, the problem goes away.

My code is very similar to this sample (the 0.4.0 one) which is the example code that my Azure instance provides for connecting Python auth to Azure.

[rayluo]

• Using identity.web instead of identity.flask so I don't need to use the decorator (the Flask app wraps a Plotly Dash page, so I don't want to use the decorator and instead just redirect any unauthorized users to the login page)

For the sake of investigation, what if you temporarily remove the Plotly Dash, and then use identity.flask and its decorator. Will it still run into same issue when Gunicorn has multiple workers?

[phsyn]

Good idea. Looks like that works, even with multiple workers. I simplified the code to test this and basically implemented the 0.9.0 version of the sample I linked above.

[phsyn]

Okay, I think I have a reasonable option using identity.flask.

I modified my old code to call the decorator as a function in the before_request for any routes that require authentication. That allows me to add authentication to a large number of endpoints in my Dash application without needing to add the decorator to each.

This does require that I manually check whether the user is already logged in before calling the decorator. Otherwise, the rest of the routes will get the context param which they're not expecting.

This seems to be working well now with multiple workers.

[rayluo]

This does require that I manually check whether the user is already logged in before calling the decorator. Otherwise, the rest of the routes will get the context param which they're not expecting.

I probably miss some details here. If you need to manually check whether the user is logged in before and you are not using the context, why would you need to call the login_required() decorator in the first place?

I'm open to the idea of adding more APIs to check whether a user has logged in, without returning a context, but I would like to see some code snippet to help me understand the situation.

[phsyn]

You're right that there's not really a good reason to use the login_required() decorator in this case. I just hadn't bothered to read through enough to see that it's just calling login. So in that case, the correct way for me to handle this with the way your code is currently implemented is to just manually check if the user is logged in (auth._auth.get_user()), then if not, call auth.login with the next_link set. I was just using the decorator as an easy way of passing through the login process.

In the long term, having an API to ensure the user is logged in without returning the context would probably be the most convenient, but this works fine for me.

A snippet of what I'm doing is below.

@app.before_request
def requires_auth():
    allowed_routes = ["/login", "/logout-success", app_config.REDIRECT_PATH]  # This list has other app-specific endpoints as well
    if not auth._auth.get_user() and request.path not in allowed_routes:
        if request.endpoint and request.endpoint != 'static':
            return auth.login(next_link = request.url)

[rayluo]

I'm open to the idea of adding more APIs to check whether a user has logged in, without returning a context, but I would like to see some code snippet to help me understand the situation.

In the long term, having an API to ensure the user is logged in without returning the context would probably be the most convenient, but this works fine for me.

What I meant was "(open to the idea of adding more APIs ...) if there would be a need to justify it". But after seeing your code snippet, I am not convinced that an official auth.is_logged_in() (replacing auth._auth.get_user()) is the right direction. Here is the thing. Auth is hard, and a library's job is to do the hard work for the app developers so that they don't have to. Adding a declarative decorator to the needed views is conceptually much easier than fiddling with the underlying nuances. (I believe you experienced the hard thing first-handed already, in your trial-and-error of this github issue.)

So, @login_required() is or should be your friend. The real reason you do not want to use the @login_required() is probably twofold:

1. It currently requires the views being decorated to have a new context parameter. The design decision was that if a view does not need any data from context, then the view perhaps needs no login at all. Alternatively, you could have a decorated view that accepts and ignores the context, and then do your Plotly Dash thing.

2. Another perhaps more reasonable idea is the desire to somehow allow decorating multiple views in one shot. I believe there is a pattern in Flask (or other web frameworks) to do that, and someone tried that before, but I can't find that conversation right now. I would love to rediscover that pattern and document it.

[phsyn]

Okay, that's fair. I agree that in general using the login_required is conceptually easy, and when using that decorator just ignoring the context is simple. Since my Flask app is really just a wrapper around the real code in Dash, using login_required is much more difficult because Dash is hiding the views, so trying to go in and add the decorator to all of them and change the function signature to accept context is not really feasible.

In this case, the pattern I'm really interested in is asserting that login is required on all views except a small set which is where your reason 2 comes in. The snippet I have above is basically doing just that. I'm not confident this is the "right way" to do so in Flask, but matches other examples I've seen online.

I see what you mean regarding the concept that any view not needing the context may not need login. However, in my case nearly all of the views only require that a user is authorized, but don't care about the user's details. The dashboard that is contained in the Dash app doesn't care which user this is, just that the user is one of an authorized set.

[rayluo]

Thanks for your input. For now, let's reclassify this topic NOT as "needing an auth.is_logged_in()", but "how to specify a batch of Flask views that needs login but needs no context", and the answer on Flask is your earlier code snippet. I'll also need to give this more thoughts on what I can do here.