Login page loops indefinitely #24579
Comments
|
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 I've modified these, and tried again : sudo docker compose -f docker-compose-non-dev.yml pull ... but still the same issue :( |
|
If you aren't specifying a certain image in your docker-compose.yml file, it's probably defaulting to |
|
Could also be related to #24435 (comment) |
|
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) : git clone https://github.com/apache/superset.git 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 Strange.... |
|
It works with edit of Then do not forgot to @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. |
|
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? |
|
@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. |
|
many thanks again @ww7 , much clearer for me now! I assume version 3.0.0 will include the fix for that bug |
|
@julien92git probably dev's would post addition information about CSRF protection for |
|
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. |
|
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. @ww7 cloud you please advise on how to fix this situation? |
|
@xddpool I think reverse-proxy with SSL (Nginx/Apache/Caddy/HAproxy etc) can solve this Are you sure deployed apache/superset:2.1.0 ? |
|
When will this issue be fixed |
|
Hi, can you try changing your |
Solved my problem perfectly ! 💯 |
|
If you use 0.0.0.0:8088 => change to localhost:8088 |
|
i used |
Worked for me to switch TALISMAN_ENABLED to False |
|
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)) (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. ###################################################################### 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? |
|
WTF_CSRF_ENABLED = False |
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 |
|
Could someone experiencing this issue please try adding |
Same here. The only think that works is setting in docker-compose-non-dev.yml version 2.1.0 |
|
Hi all, After these changes superset was running smoothly. 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. |
|
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. I have set |
|
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. |
This is working for me, but the version is very old. Actually the version is 3.0.1 |
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 |
I just tried this but with Can anyone explain the security risks (if any) associated with |
|
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. |
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’ve got a similar setup. 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. |
|
|
|
It will resolve the issue in login page loop and also it'll allow the embedded dashboard to anywhere |
|
I'm running HTTP and this works for me: |
|
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. |
|
Has anybody integrated superset within java spring boot application? |
I'd encourage you to join slack and/or GitHub Discussions to find some folks that have. |
and others
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
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
The text was updated successfully, but these errors were encountered: