superset can not login on browser

[zengyijian916]

How to reproduce the bug

1. Install the latest superset as below:

# pip install apache-superset Pillow
# export SUPERSET_SECRET_KEY=`openssl rand -base64 42`
# export FLASK_APP=superset
# superset fab create-admin --username admin --firstname Superset --lastname Admin --email admin@superset.com --password admin
# superset db upgrade
# superset superset init
# superset run -h 172.17.0.7 -p 8080 --with-threads --reload --debugger

the output as below:

logging was configured successfully
2023-09-30 20:55:12,234:INFO:superset.utils.logging_configurator:logging was configured successfully
2023-09-30 20:55:12,328:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
/usr/local/lib/python3.11/site-packages/flask_limiter/extension.py:336: 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.
  warnings.warn(
 * Serving Flask app 'superset'
 * Debug mode: off
2023-09-30 20:55:13,280:INFO:werkzeug:WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://172.17.0.7:8080
2023-09-30 20:55:13,280:INFO:werkzeug:Press CTRL+C to quit
2023-09-30 20:55:13,281:INFO:werkzeug: * Restarting with stat
logging was configured successfully
2023-09-30 20:55:14,680:INFO:superset.utils.logging_configurator:logging was configured successfully
2023-09-30 20:55:14,786:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
/usr/local/lib/python3.11/site-packages/flask_limiter/extension.py:336: 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.
  warnings.warn(
2023-09-30 20:55:15,777:WARNING:werkzeug: * Debugger is active!
2023-09-30 20:55:15,778:INFO:werkzeug: * Debugger PIN: 787-983-920
logging was configured successfully
2023-09-30 20:55:12,234:INFO:superset.utils.logging_configurator:logging was configured successfully
2023-09-30 20:55:12,328:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
/usr/local/lib/python3.11/site-packages/flask_limiter/extension.py:336: 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.
  warnings.warn(
 * Serving Flask app 'superset'
 * Debug mode: off
2023-09-30 20:55:13,280:INFO:werkzeug:WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://172.17.0.7:8080
2023-09-30 20:55:13,280:INFO:werkzeug:Press CTRL+C to quit
2023-09-30 20:55:13,281:INFO:werkzeug: * Restarting with stat
logging was configured successfully
2023-09-30 20:55:14,680:INFO:superset.utils.logging_configurator:logging was configured successfully
2023-09-30 20:55:14,786:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
/usr/local/lib/python3.11/site-packages/flask_limiter/extension.py:336: 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.
  warnings.warn(
2023-09-30 20:55:15,777:WARNING:werkzeug: * Debugger is active!
2023-09-30 20:55:15,778:INFO:werkzeug: * Debugger PIN: 787-983-920

2. Open browser and input http://172.17.0.7:8080 will see the superset portal but while try to login with admin/admin,
   will not login and the errorr message as bleow:

2023-09-30 20:55:30,020:INFO:werkzeug:172.17.0.1 - - [30/Sep/2023 20:55:30] "GET /login/ HTTP/1.1" 200 -
2023-09-30 20:55:31,436:INFO:flask_wtf.csrf:The CSRF session token is missing.
Refresh CSRF token error
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/flask_wtf/csrf.py", line 261, in protect
    validate_csrf(self._get_csrf_token())
  File "/usr/local/lib/python3.11/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.11/site-packages/flask/app.py", line 1821, in full_dispatch_request
    rv = self.preprocess_request()
         ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/flask/app.py", line 2313, in preprocess_request
    rv = self.ensure_sync(before_func)()
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/flask_wtf/csrf.py", line 229, in csrf_protect
    self.protect()
  File "/usr/local/lib/python3.11/site-packages/flask_wtf/csrf.py", line 264, in protect
    self._error_response(e.args[0])
  File "/usr/local/lib/python3.11/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-09-30 20:55:31,436:WARNING:superset.views.base:Refresh CSRF token error
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/flask_wtf/csrf.py", line 261, in protect
    validate_csrf(self._get_csrf_token())
  File "/usr/local/lib/python3.11/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.11/site-packages/flask/app.py", line 1821, in full_dispatch_request
    rv = self.preprocess_request()
         ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/flask/app.py", line 2313, in preprocess_request
    rv = self.ensure_sync(before_func)()
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/flask_wtf/csrf.py", line 229, in csrf_protect
    self.protect()
  File "/usr/local/lib/python3.11/site-packages/flask_wtf/csrf.py", line 264, in protect
    self._error_response(e.args[0])
  File "/usr/local/lib/python3.11/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-09-30 20:55:31,438:INFO:werkzeug:172.17.0.1 - - [30/Sep/2023 20:55:31] "POST /login/ HTTP/1.1" 302 -
2023-09-30 20:55:31,480:INFO:werkzeug:172.17.0.1 - - [30/Sep/2023 20:55:31] "GET /login/ HTTP/1.1" 200 -
^C[root@superset ~]# 

Expected results

login as expected.

Actual results

will not login and show the login screen all the time.

Screenshots

Environment

(please complete the following information):

- browser type and version:
Firefox 102.15.1esr(64-bit)
- superset version: `superset version`

[root@superset ~]# superset version
logging was configured successfully
2023-09-30 21:08:25,369:INFO:superset.utils.logging_configurator:logging was configured successfully
2023-09-30 21:08:25,477:INFO:root:Configured event logger of type <class 'superset.utils.log.DBEventLogger'>
/usr/local/lib/python3.11/site-packages/flask_limiter/extension.py:336: 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.
  warnings.warn(
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Superset 3.0.0
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[root@superset ~]# 
[root@superset ~]# python -V
Python 3.11.2
[root@superset ~]# pip -V
pip 23.2.1 from /usr/local/lib/python3.11/site-packages/pip (python 3.11)

Checklist

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

• [ Y] I have checked the superset logs for python stacktraces and included it here as text if there are any.
• [ Y] I have reproduced the issue with at least the latest released version of superset.
• [Y ] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

[sfirke]

Likely duplicate of #24579. The current state of Superset's default security settings may not work without a load balancer / reverse proxy in front of it that provides https. Could you read that thread and try the fixes, noting what works for you? Ideally a combination that lets you use Superset without completely disabling those security components.

In particular I'm curious to hear back on whether adding "session_cookie_secure": False to TALISMAN_CONFIG helps.

[zengyijian916]

Superset has too many bugs and too many strange behavior which not work as expected.
login loops on login pages and use redis following bellow offical document.
https://superset.apache.org/docs/installation/cache/
but it will throw this error

Oct 02 10:50:04 superset bash[875727]:   File "/usr/local/lib/python3.11/site-packages/flask_caching/__init__.p>
Oct 02 10:50:04 superset bash[875727]:     app.extensions["cache"][self] = cache_factory(
Oct 02 10:50:04 superset bash[875727]:                                     ^^^^^^^^^^^^^^
Oct 02 10:50:04 superset bash[875727]:   File "/usr/local/lib/python3.11/site-packages/flask_caching/backends/r>
Oct 02 10:50:04 superset bash[875727]:     new_class = cls(*args, **kwargs)
Oct 02 10:50:04 superset bash[875727]:                 ^^^^^^^^^^^^^^^^^^^^
Oct 02 10:50:04 superset bash[875727]:   File "/usr/local/lib/python3.11/site-packages/flask_caching/backends/r>
Oct 02 10:50:04 superset bash[875727]:     self._write_client = self._read_clients = self._client
Oct 02 10:50:04 superset bash[875727]:                                               ^^^^^^^^^^^^
Oct 02 10:50:04 superset bash[875727]: AttributeError: 'RedisCache' object has no attribute '_client'
lines 1-21/21 (END)

I'm cofused about before version release, there is nothing test from install to running es expected? if has, why the document not accurate at all. and not available at all. Seems this project has release so many version untill now, but not mature and stable at all. each version can not meet basic requirements easy. at the same time, airflow did mature and stable.

[lutinglt]

I have the same problem

WTF_CSRF_ENABLED = False
TALISMAN_ENABLED = False
add to superset_config.py, it can work.
If running on Docker, it's /app/pythonpath/superset_config.py

[zengyijian916]

@lutinglt Thank you so much. it work.

[mdeshmu]

@zengyijian916 how did you resolve caching related issue?

AttributeError: 'RedisCache' object has no attribute '_client'

[zengyijian916]

@mdeshmu I have not resolve this issue, just resolve the login loop issue. now I have not change any caching setting. not use redis will not happen this issue. I just highlight superset is so hard to use.

[bukem]

While adding the parameters mentioned by @lutinglt solves the issue, it seems to me that there is also another problem, caused is a missing migration file.

select * from alembic_version;
 version_num
--------------
 4b85906e5b91

which corresponds to 2023-09-15_12-58_4b85906e5b91_add_on_delete_cascade_for_dashboard_roles.py but in superset_app containter there is no such migration:

root@515f0f33ea47:/app# ls superset/migrations/versions/ | tail -n 5
2023-08-09_15-39_4448fa6deeb1__dd_on_delete_cascade_for_embedded_dashboards.py.py
2023-08-14_09-38_9f4a086c2676_add_normalize_columns_to_sqla_model.py
2023-08-22_11-09_ec54aca4c8a2_increase_ab_user_email_field_size.py
__init__.py
__pycache__

The file 2023-08-22_11-09_ec54aca4c8a2_increase_ab_user_email_field_size.py corresponds to one of the previous migrations.

Since the first step completes with an error, the remaining steps from the docker-init.sh are skipped, namely:

• Step 2. Create an admin user
• Step 3. Create default roles and permissions
• Step 4. Load some data to play with

I haven't figured out how the list of files in the container is generated yet, but it's clearly a bug.
Workaround Dirty hack:

update alembic_version set version_num = 'ec54aca4c8a2' where version_num = '4b85906e5b91';

[sfirke]

@bukem that sounds like something that deserves its own GitHub issue for proper visibility, could you please move that content into a new issue?

[mdeshmu]

@zengyijian916 please create a separate GitHub issue for the Redis cache-related problem you are facing and attach the output of pip freeze from the system where you are facing this issue. I suspect it's a dependency version issue described here.

[bukem]

@sfirke
sure, created #25505

[mdeshmu]

@zengyijian916 can you try following to see if it resolves your issue.

pip install cachelib==0.8.0

[MihaMihavich]

@mdeshmu

it work, thank you

[sfirke]

Can we close this issue? There's the login loop which is a duplicate of #24579, the AttributeError: 'RedisCache' object has no attribute '_client' which should probably be its own issue and appears to be fixed by @mdeshmu , and another problem that got spun off into its own issue.

@mdeshmu do you think your suggestion above to install cachelib 0.8.0 needs to be added to the main project config or docs?

[mdeshmu]

@sfirke someone already took care of it in #25947 last week. We are good to close this one.