-
Notifications
You must be signed in to change notification settings - Fork 13.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't open Settings -> List Users when using OAuth with Google for an Admin user #13243
Comments
We are also struggling with this problem. |
I'm not having this problem with Superset 1.1.0 running on Kubernetes, here is my google auth config for you to compare: extraEnv:
OAUTH_HOME_DOMAIN: 'mydomain.com'
OAUTH_WHITELIST_REGEX: '@mydomain.com$'
extraSecretEnv:
# GCP API Keys: https://console.cloud.google.com/apis/credentials
# GCP ClientID: superset-oauth2
GOOGLE_KEY: xxxxxxx.apps.googleusercontent.com
GOOGLE_SECRET: xxxxxxxxxx
configOverrides:
enable_proxy_fix: |
# This will make sure the redirect_uri is properly computed, even with SSL offloading
ENABLE_PROXY_FIX = True
enable_debug: |
LOG_LEVEL = 'DEBUG'
enable_oauth: |
from flask_appbuilder.security.manager import (AUTH_DB, AUTH_OAUTH)
AUTH_TYPE = AUTH_OAUTH
OAUTH_PROVIDERS = [
{
"name": "google",
"whitelist": [ os.getenv("OAUTH_WHITELIST_REGEX", "") ],
"icon": "fa-google",
"token_key": "access_token",
"remote_app": {
"client_id": os.getenv("GOOGLE_KEY"),
"client_secret": os.getenv("GOOGLE_SECRET"),
"api_base_url": "https://www.googleapis.com/oauth2/v2/",
"client_kwargs": {"scope": "email profile"},
"request_token_url": None,
"access_token_url": "https://accounts.google.com/o/oauth2/token",
"authorize_url": "https://accounts.google.com/o/oauth2/auth",
"authorize_params": {"hd": os.getenv("OAUTH_HOME_DOMAIN", "")}
}
}
]
# Map Authlib roles to superset roles
AUTH_ROLE_ADMIN = 'Admin'
AUTH_ROLE_PUBLIC = 'Public'
# Will allow user self registration, allowing to create Flask users from Authorized User
AUTH_USER_REGISTRATION = True
# The default user self registration role
AUTH_USER_REGISTRATION_ROLE = "Admin" |
Thanks for that, I've tried the above with 1.1.0 but am still getting the same issue -on login I appear to have a profile of Admin and can list roles (and can see the users assigned to the roles), etc but clicking on List Users gives an access denied. Out of interest I implemented LDAP authentication against our production dc and am getting the same issue. Reverting to AUTH_DB allows me to list and edit users. Can I check my understanding that the expected behaviour of an admin user via OAUTH or LDAP is that they should be able to list and edit users within the app? |
Yes. I do not even create a local admin account for my clusters anymore. |
Hi, I can confirm the same issue in my installation with LDAP authentication. EnvironmentUbuntu Server 20.04 |
Even I had run into the same issue with my LDAP setup. Running a |
I was also facing the same issue. But just now I ran |
I have similar problem when initializing superset with I found the problem is about missing permissions like So when switching authentication methods, the user data model name changes: https://github.com/dpgaspar/Flask-AppBuilder/blob/1fb6d985910d306a821a8da072cd3c93e41311ac/flask_appbuilder/security/mongoengine/manager.py#L43-L52 which means after switching authentication methods, it needs re-run |
facing the same issue on my first day of using Superset 🥲 re-run |
for instance I recommend that you pass the credentials via configmap or secrets |
I'm not sure what the critique here is. Could you expand upon your statement? |
Also facing this issue. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue |
Same issue. |
I'm facing the same issue with Oauth2 created users (with Admin role) and Superset 1.5.1 |
Still facing the same issue. Does anyone have a workaround? |
just re-run "superset init" |
Same issue on superset 2.1.0. Re-running |
Faced with the same issue while using Keycloak with Superset, I discovered that the roles in Keycloak for both the client and the users were not assigned correctly. To resolve this, I simply created the 'Admin' role for the Superset client in Keycloak and then assigned the role to the user under the Superset client. |
I tried using |
Shall we call this one resolved, then? |
At least on 3.0.3 this one is still an issue for us. |
Am working on Apache/Superset 3.1.0 using Official Docker image and using OAuth with AWS Cognito.
PS. If you are not using docker, I hope this step can guide you. |
A clear and concise description of what the bug is.
Expected results
User list displays and users can be edited When settings -> List Users is selected
Actual results
Get an access denied popup and return to dashboard
How to reproduce the bug
Enable AUTH_TYPE=AUTH_OAUTH in config.py
Snippet of config.py:
AUTH_TYPE = AUTH_OAUTH
AUTH_USER_REGISTRATION = True
AUTH_USER_REGISTRATION_ROLE = "Admin"
PUBLIC_ROLE_LIKE_GAMMA = True
OAUTH_PROVIDERS = [
{
"name": "google",
"icon": "fa-google",
"token_key": "access_token",
"remote_app": {
"client_id": "xxx",
"client_secret": "xxx",
"api_base_url": "https://www.googleapis.com/oauth2/v2/",
"client_kwargs": {"scope": "email profile"},
"request_token_url": None,
"access_token_url": "https://accounts.google.com/o/oauth2/token",
"authorize_url": "https://accounts.google.com/o/oauth2/auth",
}
}
]
Register a new user using Google as a provider.
Go to settings-> List Users
Also changed auth type back to AUTH_DB and logged in as admin. I then deleted permissions for new google-based admin user and added them back in so they matched the currently authorised admin. Logged out, changed config.py back to use oauth and logged in as google-based admin user. Problem remains (also created a new auth_db based user with same permissions and worked correctly)
Environment
(please complete the following information):
Ubuntu 18.04.3
Superset 1.0.1
Python 3.7.5
Node 8.10.0
The text was updated successfully, but these errors were encountered: