4.0.0 Okta log-in results in 500 for new users: AttributeError: 'NoneType' object has no attribute 'is_active'

[LyleScott]

Bug description

We have Okta auth code that worked fine in Superset 2.x and 3.x, but 4.0.0 seems to exhibit an issue I've not yet been able to trace down where an Okta log in results in a 500 for new users that would normally get created as a result of the log in.

• In 2.x or 3.x, this set up creates a new User no problem if the User does not exist.
• if I upgrade a 2.x or 3.x install to 4.0.0 with these users pre-existing, Okta auth works fine.
• Problem is limited to 4.0.0 and a User being created via Okta handler (sso).

2024-04-24 00:01:23,602:ERROR:superset.views.base:'NoneType' object has no attribute 'is_active'
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 1823, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.10/site-packages/flask/app.py", line 1799, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
  File "/usr/local/lib/python3.10/site-packages/flask_appbuilder/security/views.py", line 628, in login
    if g.user is not None and g.user.is_authenticated:
  File "/usr/local/lib/python3.10/site-packages/werkzeug/local.py", line 311, in __get__
    obj = instance._get_current_object()
  File "/usr/local/lib/python3.10/site-packages/werkzeug/local.py", line 515, in _get_current_object
    return get_name(local())
  File "/usr/local/lib/python3.10/site-packages/flask_login/utils.py", line 25, in <lambda>
    current_user = LocalProxy(lambda: _get_user())
  File "/usr/local/lib/python3.10/site-packages/flask_login/utils.py", line 370, in _get_user
    current_app.login_manager._load_user()
  File "/usr/local/lib/python3.10/site-packages/flask_login/login_manager.py", line 364, in _load_user
    user = self._user_callback(user_id)
  File "/usr/local/lib/python3.10/site-packages/flask_appbuilder/security/manager.py", line 2158, in load_user
    if user.is_active:
AttributeError: 'NoneType' object has no attribute 'is_active'

How to reproduce the bug

• Install 0.12.9 helm chart
• Have Okta authentication code set up in helm template:

configOverrides:

  okta: |
    from flask_appbuilder.security.manager import AUTH_OAUTH
    from superset.security import SupersetSecurityManager
    import logging

    class CustomSsoSecurityManager(SupersetSecurityManager):

        def oauth_user_info(self, provider, response=None):
            logging.info(f"OAUTH Provider: {provider}")

            if provider == 'okta':
                user_info = self.appbuilder.sm.oauth_remotes[provider].get('oauth2/v1/userinfo').json()
                logging.info(user_info)

                return {
                    'name': user_info['name'],
                    'email': user_info['email'],
                    'id': user_info['email'],
                    'username': user_info['email'],
                    'first_name': user_info['given_name'],
                    'last_name': user_info['family_name']
                }

    def get_env_variable(var_name, default=None):
        """Get the environment variable or raise exception."""
        try:
            return os.environ[var_name]
        except KeyError:
            if default is not None:
                return default
            else:
                error_msg = 'The environment variable {} was missing, abort...'\
                            .format(var_name)
                raise EnvironmentError(error_msg)

    AUTH_TYPE = AUTH_OAUTH
    AUTH_USER_REGISTRATION = True  # allow self-registration (login creates a user)
    AUTH_USER_REGISTRATION_ROLE = "${okta_auth_user_registration_role}"
    OKTA_BASE_URL = get_env_variable('OKTA_BASE_URL')
    OAUTH_PROVIDERS = [
        {
            'name': 'okta',
            'token_key': 'access_token',
            'icon': 'fa-circle-o',
            'remote_app': {
                'client_id': get_env_variable('OKTA_CLIENT_ID'),
                'client_secret': get_env_variable('OKTA_CLIENT_SECRET'),
                'client_kwargs': {
                    'scope': 'openid profile email groups'
                },
                'access_token_method': 'POST',
                'api_base_url': f'{OKTA_BASE_URL}',
                'access_token_url': f'{OKTA_BASE_URL}/oauth2/v1/token',
                'authorize_url': f'{OKTA_BASE_URL}/oauth2/v1/authorize',
                'server_metadata_url': f'{OKTA_BASE_URL}/.well-known/openid-configuration',
            },
        }
    ]

    CUSTOM_SECURITY_MANAGER = CustomSsoSecurityManager

• log in via the main superset URL

Screenshots/recordings

No response

Superset version

4.0.0

Python version

3.10

Node version

Not applicable

Browser

Not applicable

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[LyleScott]

I am going to close this for now. I think this might have been a process issue with the upgrade steps we were taking. Let me close this while I spend some time on this today/tomorrow.

[LyleScott]

Yeah, I was able to track this down. User session works fine from incognito mode. I guess it has more to do with a left over session of some sort from a previous install. I was also able to repeat this issue in 3.0.x and 3.1.0.

So, no real issue other than a dirty session from a previous install.

[kraftaa]

thank you, I had the same issue, your comment made me to login via incognito mode and realize it was wrong something with previous session.

[Yuval-Moshe]

Hi @LyleScott, facing the same issue here when trying to access superset in the same browser (and session) after a helm upgrade.
Using also custom security manager but for OIDC via KeyCloak.
Can you please share how did you resolve this issue eventually?
Thanks!

[Habeeb556]

Yeah, I was able to track this down. User session works fine from incognito mode. I guess it has more to do with a left over session of some sort from a previous install. I was also able to repeat this issue in 3.0.x and 3.1.0.

So, no real issue other than a dirty session from a previous install.

++ Solved

[MohamedRhimii]

Yeah, I was able to track this down. User session works fine from incognito mode. I guess it has more to do with a left over session of some sort from a previous install. I was also able to repeat this issue in 3.0.x and 3.1.0.

So, no real issue other than a dirty session from a previous install.

++ Solved for my case too.

[yaronshanisima]

Hi @LyleScott, facing the same issue here when trying to access superset in the same browser (and session) after a helm upgrade. Using also custom security manager but for OIDC via KeyCloak. Can you please share how did you resolve this issue eventually? Thanks!

Hi @Yuval-Moshe I am having the same issue doing a rolling update - do you have any idea how to solve it?

[yaronshanisima]

I think I found the issue.
The issue seems to be related to https://stackoverflow.com/questions/66489779/implementing-openid-with-apache-superset-attributeerror-bool-object-has-no-a

So user logged in - a superset user was created in the DB (ab_user).
Then the instance is being used with another database - which don't have the ab_user created. A JWT refresh token is being requested, and then fails because we don't have the user created. Why just not creating the user? Or login out the user? Anything is better than getting the 500 error for the user, isn't ?

[fmannhardt]

Encountering this as well. I think this should not be closed but reported to FAB since it seems to be an issue with FAB and Flask Login here:
https://github.com/maxcountryman/flask-login/blob/019dbe3ae0fb95966682e769280722afb0a6b904/src/flask_login/login_manager.py#L375
and
https://github.com/dpgaspar/Flask-AppBuilder/blob/418ab8a93907669be4ccbb99d7aefa5283f3e013/flask_appbuilder/security/manager.py#L2165

FAB seems to just assume that whatever user is provided can be loaded but if the user is read by Flask Login from a cookie, then user will be None -> NPE. So, FAB should really check for the user to exist before trying to access anything on it.

[rusackas]

CC @dpgaspar

[fmannhardt]

Thanks. I opened an issue here:
dpgaspar/Flask-AppBuilder#2296
I hope it is sufficiently clear since it seems very easy to fix (without knowing more about FAB/Flask login logic) and obvious from the code that there is a risk for a NPE.