search

apache / superset

Apache Superset is a Data Visualization and Data Exploration Platform
https://superset.apache.org/
Apache License 2.0
61.46k stars 13.4k forks source link

Login page loops indefinitely #24579

Closed julien92git closed 9 months ago

julien92git commented 1 year ago

Hi,

Last week, I installed Superset using the Docker Compose method. I did the following steps exactly:

git clone https://github.com/apache/superset.git

cd superset sudo docker-compose -f docker-compose-non-dev.yml pull sudo docker-compose -f docker-compose-non-dev.yml up

After executing these commands, I accessed Superset using the following URL: http://192.168.1.150:8088/ Username: admin Password: admin

Everything was working fine : I was able to use Superset without any issue, it was working like a charm.

Today, I rolled back the server to a snapshot taken before the installation of Superset. However, after having performed the exact same steps as last week, I'm encountering a problem : I can access the login screen, but when I enter the login (admin) and password (admin), I am stuck on the same page (looping on the same login screen).

I am certain that I am following the same steps as last week.

Do you have any ideas about what might be causing the issue?

Many thanks in advance for your help!

How to reproduce the bug

  1. Install docker & docker compose
  2. Install apache superset with docker compose (see details above)
  3. Go to http://ip_address_of_server:8088
  4. Fill in "admin" in the username field
  5. Fill in "admin" in the password field
  6. Click "Sign in"

Expected results

Entering superset application

Actual results

Looping to the same login page

Environment

Checklist

Make sure to follow these steps before submitting your issue - thank you!

Many thanks for your help. Julien

julien92git commented 1 year ago

The error I'm getting when trying to login is :

The CSRF session token is missing

After googling this error, I've found out that the parameters below must by modified in the .../superset/config.py file :

SESSION_COOKIE_SAMESITE = None SESSION_COOKIE_SECURE = False SESSION_COOKIE_HTTPONLY = False WTF_CSRF_ENABLED = False

I've modified these, and tried again :

sudo docker compose -f docker-compose-non-dev.yml pull sudo docker compose -f docker-compose-non-dev.yml up

... but still the same issue :(

sfirke commented 1 year ago

If you aren't specifying a certain image in your docker-compose.yml file, it's probably defaulting to latest which almost certainly changed between your two installations. Try replacing the reference to latest with 2.1.0 and see if that helps?

sfirke commented 1 year ago

Could also be related to https://github.com/apache/superset/discussions/24435#discussioncomment-6282883

julien92git commented 1 year ago

Thank you for your feedback @sfirke, but I'm afraid, it still doesn't work.... :( :(

Here is what I've done to try version 2.1.0 (maybe there is something that I did not not apply correctly) : First of all, rollback to fresh install of the server And then, applied these commands :

git clone https://github.com/apache/superset.git cd superset git checkout 2.1.0 TAG=2.1.0 sudo docker compose -f docker-compose-non-dev.yml pull TAG=2.1.0 sudo docker compose -f docker-compose-non-dev.yml up

But the issue remains the same : I'm able to display the login screen, but when I enter admin/admin, I loop to the same screen.

What I've also noticed (if that could give a clue), is that the settings / version menu states : 0.0.0-dev These displays only with Chrome (not with Firefox).

Strange....

ww7 commented 1 year ago

It works with edit of docker-compose-non-dev.yml to specify image version at line

x-superset-image: &superset-image apache/superset:2.1.0

Then do not forgot to rm containers and pull the image specified

@julien92git you messed things, you need to use not a Github tags and releases because you don't build images himself, but using images from Docker Hub repository.

Also, previously you updated files in container, that lost after images pull and containers recreation.

julien92git commented 1 year ago

Many thanks @ww7 !! :)

It's now working perfectly again with version 2.1.0 !!

So it now seems obvious that it's a bug with the latest version.

Just to learn from that experience : how could I get a list of the history of the different versions that are released? On docker hub, there are some "strange" number versions, like "eb42fa7a2e21d5d4d69a6e8a9787dc8ea1dd6348-py310" I'm just wondering how I could see the version history like 2.0.0, 2.1.0, etc...

ww7 commented 1 year ago

@julien92git just scroll down or search/filter versions, there also 2.10 and 3.0.0rc1 etc

"Strange" numbers it's a "randomized" tag (kind of hash of image) because images built frequently from source code, probably after every Github commit.

Docker initially is a tool for developers, for quick deploy and testing with various environments.

julien92git commented 1 year ago

many thanks again @ww7 , much clearer for me now!

I assume version 3.0.0 will include the fix for that bug

ww7 commented 1 year ago

@julien92git probably dev's would post addition information about CSRF protection for non-dev setup.

xddpool commented 1 year ago

I encountered the same issue. I deployed Superset on a server using Docker Compose. Accessing localhost on the server interface works fine, but when I try to access it via the IP address, it keeps showing the login page and the browser continuously redirects.

xddpool commented 1 year ago

However, the issue I'm experiencing is slightly different from the description above.

For example, my Mac's IP address is 192.168.10.117. I have deployed Superset on Docker on my Mac. When I access it using localhost:8088, everything works fine. However, when I try to access it using 192.168.10.117:8088, it gets stuck in a login page loop with continuous 302 redirects.

@ww7 cloud you please advise on how to fix this situation?

ww7 commented 1 year ago

@xddpool I think reverse-proxy with SSL (Nginx/Apache/Caddy/HAproxy etc) can solve this

Are you sure deployed apache/superset:2.1.0 ?

liujiwen-up commented 1 year ago

When will this issue be fixed

eschutho commented 1 year ago

Hi, can you try changing your TALISMAN_ENABLED config to False? If you are running of the latest docker image, you are using code from github master. It's advised to use only approved releases rather than the latest. Regardless, though, take a look at the UPDATING.md file for any breaking changes that may have occurred since the 2.1 release. The current master is moving towards 3.0 which has several breaking changes in it, and the UPDATING.md file will explain how you might need to update your system to work with the latest version.

Jedore commented 1 year ago

If you aren't specifying a certain image in your docker-compose.yml file, it's probably defaulting to latest which almost certainly changed between your two installations. Try replacing the reference to latest with 2.1.0 and see if that helps?

Solved my problem perfectly ! 💯

lekhanhtoan37 commented 1 year ago

If you use 0.0.0.0:8088 => change to localhost:8088

avnav0 commented 1 year ago

i used 2.1.0 and i get the same issue:

2023-08-02 18:56:48,036:INFO:flask_wtf.csrf:The CSRF session token is missing.
Refresh CSRF token error
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 261, in protect
    validate_csrf(self._get_csrf_token())
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 103, in validate_csrf
    raise ValidationError("The CSRF session token is missing.")
wtforms.validators.ValidationError: The CSRF session token is missing.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1515, in full_dispatch_request
    rv = self.preprocess_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1857, in preprocess_request
    rv = self.ensure_sync(before_func)()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 229, in csrf_protect
    self.protect()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 264, in protect
    self._error_response(e.args[0])
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 307, in _error_response
    raise CSRFError(reason)
flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is missing.
2023-08-02 18:56:48,037:WARNING:superset.views.base:Refresh CSRF token error
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 261, in protect
    validate_csrf(self._get_csrf_token())
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 103, in validate_csrf
    raise ValidationError("The CSRF session token is missing.")
wtforms.validators.ValidationError: The CSRF session token is missing.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1515, in full_dispatch_request
    rv = self.preprocess_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1857, in preprocess_request
    rv = self.ensure_sync(before_func)()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 229, in csrf_protect
    self.protect()
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 264, in protect
    self._error_response(e.args[0])
  File "/usr/local/lib/python3.8/site-packages/flask_wtf/csrf.py", line 307, in _error_response
    raise CSRFError(reason)
flask_wtf.csrf.CSRFError: 400 Bad Request: The CSRF session token is missing.
VitalyKapustin-git commented 1 year ago

Hi, can you try changing your TALISMAN_ENABLED config to False? If you are running of the latest docker image, you are using code from github master. It's advised to use only approved releases rather than the latest. Regardless, though, take a look at the UPDATING.md file for any breaking changes that may have occurred since the 2.1 release. The current master is moving towards 3.0 which has several breaking changes in it, and the UPDATING.md file will explain how you might need to update your system to work with the latest version.

Worked for me to switch TALISMAN_ENABLED to False

gbmichael28 commented 1 year ago

I have the same issue. I have TALISMAN_ENABLE as False in config.py.

Do you want Talisman enabled?

TALISMAN_ENABLED = utils.cast_to_boolean(os.environ.get("TALISMAN_ENABLED", True))

TALISMAN_ENABLED = utils.cast_to_boolean(os.environ.get("TALISMAN_ENABLED", False))

(I comment out the original line, and then copy and paste into a new line and change True to False).

Type in the username and password as specified, and voila, it goes right back to the same login page.

I am running the docker-compose-non-dev.yml (but I get the same result with the regular docker-compose). I do a have a SECRET_KEY defined in the superset_config.py file. I have defined it two ways. The first time, I defined it AFTER I'd already brought Superset up. The second time, I defined it before I brought it up. It does not matter either way, it still goes right back to the login page.

I know the init script is running based on the information below, so the admin user is created and available.

###################################################################### superset_init | superset_init | superset_init | Init Step 1/4 [Complete] -- Applying DB migrations superset_init | superset_init | superset_init | ###################################################################### superset_init | superset_init | superset_init | ###################################################################### superset_init | superset_init | superset_init | Init Step 2/4 [Starting] -- Setting up admin user ( admin / admin ) superset_init | superset_init | superset_init | ###################################################################### superset_init | superset_worker | [2023-08-06 14:07:04,434: INFO/MainProcess] Connected to redis://redis:6379/0 superset_worker | [2023-08-06 14:07:04,435: INFO/MainProcess] mingle: searching for neighbors superset_init | logging was configured successfully superset_init | 2023-08-06 14:07:05,241:INFO:superset.utils.logging_configurator:logging was configured successfully superset_init | 2023-08-06 14:07:05,243:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'> superset_worker | [2023-08-06 14:07:05,439: INFO/MainProcess] mingle: all alone superset_worker | [2023-08-06 14:07:05,445: INFO/MainProcess] celery@66f27eab0157 ready. superset_init | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py] superset_init | Recognized Database Authentications. superset_init | Admin User admin created. superset_init | superset_init | ###################################################################### superset_init | superset_init | superset_init | Init Step 2/4 [Complete] -- Setting up admin user superset_init | superset_init | superset_init | ###################################################################### superset_init | superset_init | superset_init | ###################################################################### superset_init | superset_init | superset_init | Init Step 3/4 [Starting] -- Setting up roles and perms superset_init | superset_init | superset_init | ######################################################################

Step 4 was also successful, I just excluded it here to save on my novella.

When I changed the secret key AFTER deployment, I did follow the instructions in the Superset documentation to Rotate in a new SECRET_KEY. (including viewing the existing from the superset shell inside of the superset container.

Am I setting the TALISMAN_ENABLED incorrect?

qmgeng commented 1 year ago

WTF_CSRF_ENABLED = False TALISMAN_ENABLED=False Worked for me!

AidanHarveyNelson commented 1 year ago

WTF_CSRF_ENABLED = False TALISMAN_ENABLED=False Worked for me!

I found this in the superset repo https://github.com/apache/superset/blob/master/.github/workflows/ecs-task-definition.json

Seems like even there own code suggest setting TALISMAN_ENABLED = False

sevaroy commented 1 year ago

It works with edit of docker-compose-non-dev.yml to specify image version at line

x-superset-image: &superset-image apache/superset:2.1.0

Then do not forgot to rm containers and pull the image specified

@julien92git you messed things, you need to use not a Github tags and releases because you don't build images himself, but using images from Docker Hub repository.

Also, previously you updated files in container, that lost after images pull and containers recreation.

it work for me

spartan-it commented 1 year ago

WTF_CSRF_ENABLED = False TALISMAN_ENABLED=False Worked for me!

What if you need this setting to be true?

Selenium39 commented 11 months ago

TALISMAN_ENABLED=False Worked for me

sfirke commented 11 months ago

However, when I try to access it using 192.168.10.117:8088, it gets stuck in a login page loop with continuous 302 redirects.

I just booted up a new instance of Superset, using stable version 2.1.0 that I have running elsewhere in production. I was without my normal working Application Gateway that goes in front of my production instance and I got stuck in this loop of redirects, even with WTF_CSRF_ENABLED = False and TALISMAN_ENABLED=False.

I set SESSION_COOKIE_SAMESITE = 'Lax' and SESSION_COOKIE_SECURE = False and that got me able to log in. In my normal production setup these are 'None' for SAMESITE and True for Secure. I also have WTF_CSRF_ENABLED and TALISMAN_ENABLED as True there.

I think this advice from @ww7 above is on track:

I think reverse-proxy with SSL (Nginx/Apache/Caddy/HAproxy etc) can solve this

I configured an Azure Application Gateway in front of this to provide HTTPS and then was able to restore all of the settings as described above to be more secure, while the instance continued to work.

But I wonder if we could avoid this initial stumbling block for new users by setting defaults for SESSION_COOKIE_SAMESITE, SESSION_COOKIE_SECURE, TALISMAN_ENABLED and WTF_CSRF_ENABLED to a combination that works out of the box. Or if that's undesirable then we should document this better.

theGodlessLakra commented 11 months ago

Hi, I am facing this same error on superset 3.0.0 (non-dev) which is NOT running behind any proxy and is on http, (not https). I have tried various combinations of these parameters SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SECURE, SESSION_COOKIE_SAMESITE, WTF_CSRF_ENABLED, and TALISMAN_ENABLED. I am still facing the same error and stuck in a login loop. Which combination is supposed to be right for my use case ?

sfirke commented 11 months ago

Could someone experiencing this issue please try adding "session_cookie_secure": False to their TALISMAN_CONFIG and seeing if that helps? From https://github.com/apache/superset/issues/25374#issuecomment-1735702931.

HDLP9 commented 11 months ago

Hi, I am facing this same error on superset 3.0.0 (non-dev) which is NOT running behind any proxy and is on http, (not https). I have tried various combinations of these parameters SESSION_COOKIE_HTTPONLY, SESSION_COOKIE_SECURE, SESSION_COOKIE_SAMESITE, WTF_CSRF_ENABLED, and TALISMAN_ENABLED. I am still facing the same error and stuck in a login loop. Which combination is supposed to be right for my use case ?

Same here. The only think that works is setting in docker-compose-non-dev.yml version 2.1.0

yugneuron commented 10 months ago

Hi all, I have installed superset using official docker-compose installation on my local machine(Installed version 3.0.0). And since the official installation doesn't backup the superset metadata, it is recommended either to change the SQLALCHEMY_DATABASE_URI to a managed database or backup the data regularly yourself. The former didn't work for me (problem was the same i.e. I can access the superset login page but after entering the username and password (admin, admin) it results in invalid login). So, I have used bind mounting method so as to manage the data ourselves. Therefore, I have made the following changes in the non-dev yml file:

x-superset-image: &superset-image apachesuperset.docker.scarf.sh/apache/superset:3.0.0
x-superset-depends-on: &superset-depends-on
  - db
  - redis
x-superset-volumes:
  &superset-volumes # /app/pythonpath_docker will be appended to the PYTHONPATH in the final container
  - ./docker:/app/docker
  # - superset_home:/app/superset_home
  # Changes made by me for bind mount
  - type: bind
    source: ./data
    target: /app/superset_home

After these changes superset was running smoothly. Now, I have to deploy it on a ubuntu vm , so I have transferred the superset directory to the vm and upon running the container the superset_init is not initializing (Error is below). Can someone please help what I am doing wrong? FYI: I have updated the SECRET_KEY in superset_config.py file.


WARN[0000] The "CYPRESS_CONFIG" variable is not set. Defaulting to a blank string. 
WARN[0000] The "CYPRESS_CONFIG" variable is not set. Defaulting to a blank string. 
superset_app          | Skipping local overrides
superset_app          | Starting web app...
superset_app          | [2023-10-06 10:21:41 +0000] [7] [INFO] Starting gunicorn 20.1.0
superset_app          | [2023-10-06 10:21:41 +0000] [7] [INFO] Listening at: http://0.0.0.0:8088 (7)
superset_app          | [2023-10-06 10:21:41 +0000] [7] [INFO] Using worker: gthread
superset_app          | [2023-10-06 10:21:41 +0000] [8] [INFO] Booting worker with pid: 8
superset_app          | logging was configured successfully
superset_app          | 2023-10-06 10:21:48,705:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_app          | 2023-10-06 10:21:48,713:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_app          | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_app          |   warnings.warn(
superset_worker_beat  | Skipping local overrides
superset_worker_beat  | Starting Celery beat...
superset_worker_beat  | logging was configured successfully
superset_worker_beat  | 2023-10-06 10:21:48,502:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_worker_beat  | 2023-10-06 10:21:48,506:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_worker_beat  | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_worker_beat  |   warnings.warn(
superset_worker       | Skipping local overrides
superset_worker       | Starting Celery worker...
superset_worker       | logging was configured successfully
superset_worker       | 2023-10-06 10:21:48,243:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_worker       | 2023-10-06 10:21:48,252:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_worker       | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_worker       |   warnings.warn(
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 * Redis version=7.2.1, bits=64, commit=00000000, modified=0, pid=1, just started
superset_cache        | 1:C 06 Oct 2023 10:21:38.278 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
superset_cache        | 1:M 06 Oct 2023 10:21:38.279 * Increased maximum number of open files to 10032 (it was originally set to 1024).
superset_cache        | 1:M 06 Oct 2023 10:21:38.279 * monotonic clock: POSIX clock_gettime
superset_cache        | 1:M 06 Oct 2023 10:21:38.279 * Running mode=standalone, port=6379.
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Server initialized
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Loading RDB produced by version 7.2.1
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * RDB age 214 seconds
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * RDB memory usage when created 0.83 Mb
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Done loading RDB, keys loaded: 0, keys expired: 0.
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * DB loaded from disk: 0.000 seconds
superset_cache        | 1:M 06 Oct 2023 10:21:38.280 * Ready to accept connections tcp
superset_init         | Skipping local overrides
superset_init         | Unknown Operation!!!
superset_init         | 
superset_init         | ######################################################################
superset_init         | 
superset_init         | 
superset_init         | Init Step 1/4 [Starting] -- Applying DB migrations
superset_init         | 
superset_init         | 
superset_init         | ######################################################################
superset_init         | 
superset_db           | 
superset_db           | PostgreSQL Database directory appears to contain a database; Skipping initialization
superset_db           | 
superset_db           | 2023-10-06 10:21:38.432 UTC [1] LOG:  starting PostgreSQL 15.4 (Debian 15.4-2.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
superset_db           | 2023-10-06 10:21:38.432 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
superset_db           | 2023-10-06 10:21:38.432 UTC [1] LOG:  listening on IPv6 address "::", port 5432
superset_db           | 2023-10-06 10:21:38.442 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
superset_db           | 2023-10-06 10:21:38.453 UTC [28] LOG:  database system was shut down at 2023-10-06 10:18:04 UTC
superset_db           | 2023-10-06 10:21:38.468 UTC [1] LOG:  database system is ready to accept connections
superset_init         | logging was configured successfully
superset_init         | 2023-10-06 10:21:53,193:INFO:superset.utils.logging_configurator:logging was configured successfully
superset_init         | 2023-10-06 10:21:53,239:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
superset_init         | /usr/local/lib/python3.9/site-packages/flask_limiter/extension.py:293: UserWarning: Using the in-memory storage for tracking rate limits as no storage was explicitly specified. This is not recommended for production use. See: https://flask-limiter.readthedocs.io#configuring-a-storage-backend for documentation about configuring the storage backend.
superset_init         |   warnings.warn(
superset_worker       | /usr/local/lib/python3.9/site-packages/celery/platforms.py:840: SecurityWarning: You're running the worker with superuser privileges: this is
superset_worker       | absolutely not recommended!
superset_worker       | 
superset_worker       | Please specify a different user using the --uid option.
superset_worker       | 
superset_worker       | User information: uid=0 euid=0 gid=0 egid=0
superset_worker       | 
superset_worker       |   warnings.warn(SecurityWarning(ROOT_DISCOURAGED.format(
superset_worker       | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py]
superset_worker       |  
superset_worker       |  -------------- celery@49c1ddada9e2 v5.2.2 (dawn-chorus)
superset_worker       | --- ***** ----- 
superset_worker       | -- ******* ---- Linux-5.15.0-1047-azure-x86_64-with-glibc2.36 2023-10-06 10:21:56
superset_worker       | - *** --- * --- 
superset_worker       | - ** ---------- [config]
superset_worker       | - ** ---------- .> app:         __main__:0x7f6a250f7f70
superset_worker       | - ** ---------- .> transport:   redis://redis:6379/0
superset_worker       | - ** ---------- .> results:     redis://redis:6379/1
superset_worker       | - *** --- * --- .> concurrency: 2 (prefork)
superset_worker       | -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
superset_worker       | --- ***** ----- 
superset_worker       |  -------------- [queues]
superset_worker       |                 .> celery           exchange=celery(direct) key=celery
superset_worker       |                 
superset_worker       | 
superset_worker       | [tasks]
superset_worker       |   . cache-warmup
superset_worker       |   . cache_chart_thumbnail
superset_worker       |   . cache_dashboard_thumbnail
superset_worker       |   . fetch_url
superset_worker       |   . load_chart_data_into_cache
superset_worker       |   . load_explore_json_into_cache
superset_worker       |   . reports.execute
superset_worker       |   . reports.prune_log
superset_worker       |   . reports.scheduler
superset_worker       |   . sql_lab.get_sql_results
superset_worker       | 
superset_worker_beat  | [2023-10-06 10:21:56,231: INFO/MainProcess] beat: Starting...
superset_init         | WARNI [alembic.env] SQLite Database support for metadata databases will         be removed in a future version of Superset.
superset_init         | INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
superset_init         | INFO  [alembic.runtime.migration] Will assume transactional DDL.
superset_init         | ERROR [flask_migrate] Error: Can't locate revision identified by '4b85906e5b91'
superset_init         | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py]
superset_init exited with code 1
superset_app          | Loaded your LOCAL configuration at [/app/docker/pythonpath_dev/superset_config.py]
superset_app          | 127.0.0.1 - - [06/Oct/2023:10:22:10 +0000] "GET /health HTTP/1.1" 200 2 "-" "curl/7.88.1"

P.S.- If anyone can help on why I am not able to run the superset on updating SQLALCHEMY_DATABASE_URI link, response would be very much appreciated.

M-Salti commented 10 months ago

I'm currently using the Superset 3.0 docker image and having this same problem. Interestingly, this problem only happens when I run the image on my Linux server, but there is no problem when I run it on my Windows laptop. Any ideas what could be the reason?

I have set TALISMAN_ENABLED and WTF_CSRF_ENABLED to False and that solved the issue for me for now, but this strikes me as a bad workaround that sacrifices security.

rplescia commented 10 months ago

Running 3.0.1 on docker on Linux and having the same issue. I have set TALISMAN_ENABLED and WTF_CSRF_ENABLED to False and that hasn't solved the issue for me.

JhooGs commented 10 months ago

It works with edit of docker-compose-non-dev.yml to specify image version at line

x-superset-image: &superset-image apache/superset:2.1.0

Then do not forgot to rm containers and pull the image specified

@julien92git you messed things, you need to use not a Github tags and releases because you don't build images himself, but using images from Docker Hub repository.

Also, previously you updated files in container, that lost after images pull and containers recreation.

This is working for me, but the version is very old. Actually the version is 3.0.1

stguitar commented 9 months ago

Could someone experiencing this issue please try adding "session_cookie_secure": False to their TALISMAN_CONFIG and seeing if that helps? From #25374 (comment).

Yea, So I ran into this issue and finally got things working with this it seems as well. My version seems to be 3.0.1. My config.py file is basically the defaults, with these specific additions:


WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = True

TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ["'self'"],
        "img-src": ["'self'", "data:"],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": ["'self'", "'unsafe-inline'"],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False
}```
M-Salti commented 9 months ago

Could someone experiencing this issue please try adding "session_cookie_secure": False to their TALISMAN_CONFIG and seeing if that helps? From #25374 (comment).

Yea, So I ran into this issue and finally got things working with this it seems as well. My version seems to be 3.0.1. My config.py file is basically the defaults, with these specific additions:

WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = True

TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ["'self'"],
        "img-src": ["'self'", "data:"],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": ["'self'", "'unsafe-inline'"],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False
}```

I just tried this but with WTF_CSRF_ENABLED = True as well and it worked for me. (using Superset 3.0.0)

Can anyone explain the security risks (if any) associated with "session_cookie_secure": False?

sfirke commented 9 months ago

Thanks @M-Salti for reporting back and the good question. I'm far from an expert and hope someone else will answer. But reading this guidance, it seems like it makes it so that the cookie will only function over HTTPS. Which I believe is why it's causing this problem: as someone is setting up Superset, they don't yet have HTTPS configured.

I feel good that it's safe to set to False until you get HTTPS configured, and appropriate for the project. As discussed in #25854 , the default of this value has always been False ... until we introduced the TALISMAN_CONFIG that implicitly has it as True by default, which caused this big headache. Setting this to False will only be restoring the value to its long-time default.

M-Salti commented 9 months ago

Thanks @M-Salti for reporting back and the good question. I'm far from an expert and hope someone else will answer. But reading this guidance, it seems like it makes it so that the cookie will only function over HTTPS. Which I believe is why it's causing this problem: as someone is setting up Superset, they don't yet have HTTPS configured.

I feel good that it's safe to set to False until you get HTTPS configured, and appropriate for the project. As discussed in #25854 , the default of this value has always been False ... until we introduced the TALISMAN_CONFIG that implicitly has it as True by default, which caused this big headache. Setting this to False will only be restoring the value to its long-time default.

Thanks for your reply. Indeed, after I read more about it, it seems that setting this to False will allow the cookie to be sent only under HTTPS. I'm also not an expert, but this may make the app vulnerable to XSS attacks. Nonetheless, this combination of settings is definitely much better than turning off both Talisman and CSRF.

sebaxtian commented 8 months ago

Hi, can you try changing your TALISMAN_ENABLED config to False? If you are running of the latest docker image, you are using code from github master. It's advised to use only approved releases rather than the latest. Regardless, though, take a look at the UPDATING.md file for any breaking changes that may have occurred since the 2.1 release. The current master is moving towards 3.0 which has several breaking changes in it, and the UPDATING.md file will explain how you might need to update your system to work with the latest version.

Worked for me to switch TALISMAN_ENABLED to False

Thank you @VitalyKapustin-git this works for me,

I installed Superset in a Raspberry Pi, and I'm using my local network for access to the Superset running in a Raspberry Pi. I set up the TALISMAN_ENABLED = False in the Superset superset_config.py file and it works for me.

LittleDan9 commented 7 months ago

I’ve got a similar setup. Running the non-dev docker compose. I have OAuth configured with Okta. Nginix Proxy running in font of the HTTP container to perform SSL, which is functioning. Without OAuth, it works fine, with OAuth it perpetuates the 302 redirect issue. Authentication is good, user info is properly built upon return from Okta and I’m redirect to /superset/welcome/ which 302’s me back to login as seen from output.

superset_app          | 10.0.1.1 - - [20/Jan/2024:04:55:18 +0000] "GET / HTTP/1.0" 302 223 "-" "Mozilla/5.0 (iPad; CPU OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) EdgiOS/120.0.2210.126 Version/17.0 Mobile/15E148 Safari/604.1"

superset_app          | 2024-01-20 04:55:18,585:WARNING:root:Class 'werkzeug.local.LocalProxy' is not mapped

superset_app          | 10.0.1.1 - - [20/Jan/2024:04:55:18 +0000] "GET /superset/welcome/ HTTP/1.0" 302 201 "-" "Mozilla/5.0 (iPad; CPU OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) EdgiOS/120.0.2210.126 Version/17.0 Mobile/15E148 Safari/604.1"

superset_app          | 10.0.1.1 - - [20/Jan/2024:04:55:18 +0000] "GET /login/ HTTP/1.0" 200 48226 "-" "Mozilla/5.0 (iPad; CPU OS 17_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) EdgiOS/120.0.2210.126 Version/17.0 Mobile/15E148 Safari/604.1"

Super Docker Config:

…
from custom_sso_security_manager import CustomSsoSecurityManager

logger = logging.getLogger()

CUSTOM_SECURITY_MANAGER = CustomSsoSecurityManager # For managing User data after fetching from SSO app

# Set the authentication type to OAuth
AUTH_TYPE = AUTH_OAUTH
ENABLE_PROXY_FIX = True

# SESSION_COOKIE_SAMESITE = None
# SESSION_COOKIE_SECURE = False
# SESSION_COOKIE_HTTPONLY = False

WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = True

TALISMAN_CONFIG = {
    "content_security_policy": {
        "default-src": ["'self'"],
        "img-src": ["'self'", "data:"],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": ["'self'", "'unsafe-inline'"],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False
}
…

Nginix Config:

server {
    listen 443 ssl;
    server_name superset.<domain_name>.com;

    ssl_certificate /etc/letsencrypt/live/superset.<doamin_name>.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/superset.<domain_name>.com/privkey.pem;

    proxy_buffer_size 128k;
    proxy_buffers 4 256k;
    proxy_busy_buffers_size 256k;

    location / {
        proxy_pass http://localhost:8088;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

I’ve tried every combination of recommend “fixes” in this thread. I’m sure it has to do with the cookies, but I’m not sure where to go from here. Any thoughts are greatly appreciated.

quocviet3110 commented 7 months ago

image I set up the TALISMAN_ENABLED = False page login loop ,if i set up the TALISMAN_ENABLED = True ,i can't embedded dashboard in App. How to fix it? Thanks!

davincikart commented 5 months ago

It will resolve the issue in login page loop and also it'll allow the embedded dashboard to anywhere

TALISMAN_ENABLED = True # Enable CSP
# Configure the CSP using talisman
TALISMAN_CONFIG = {
    "content_security_policy": {
        "base-uri": ["'self'"],
        "frame-ancestors": ["'self'", "*"],
        "default-src": ["'self'"],
        "img-src": [
            "'self'",
            "blob:",
            "data:",
            "https://apachesuperset.gateway.scarf.sh",
            "https://static.scarf.sh/",
        ],
        "worker-src": ["'self'", "blob:"],
        "connect-src": [
            "'self'",
            "https://api.mapbox.com",
            "https://events.mapbox.com",
        ],
        "object-src": "'none'",
        "style-src": [
            "'self'",
            "'unsafe-inline'",
        ],
        "script-src": ["'self'", "'strict-dynamic'"],
    },
    "content_security_policy_nonce_in": ["script-src"],
    "force_https": False,
    "session_cookie_secure": False,
}
huqd commented 5 months ago

I'm running HTTP and this works for me:

ENABLE_PROXY_FIX = False
WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = False
k-e-das commented 4 weeks ago

We haven't found any Content Security Policy (CSP) defined in the configurations. Please make sure to configure CSP using the TALISMAN_ENABLED and TALISMAN_CONFIG keys or any other external software. Failing to configure CSP have serious security implications. Check https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more information. You can disable this warning using the CONTENT_SECURITY_POLICY_WARNING key. 2024-08-02 13:12:39,025:WARNING:superset.initialization:We haven't found any Content Security Policy (CSP) defined in the configurations. Please make sure to configure CSP using the TALISMAN_ENABLED and TALISMAN_CONFIG keys or any other external software. Failing to configure CSP have serious security implications. Check https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP for more information. You can disable this warning using the CONTENT_SECURITY_POLICY_WARNING key.