superset: SECRET_KEY encrypts database secrets without warning, possibly breaking web interface if changed

Make sure these boxes are checked before submitting your issue - thank you!

I have checked the superset logs for python stacktraces and included it here as text if any
I have reproduced the issue with at least the latest released version of superset
I have checked the issue tracker for the same issue and I haven’t found one similar

Superset version

0.20.4

Expected results

Usually, on web apps, app secrets are just used for generating cookies (see secrets.secret_key_base in Rails, SECRET_KEY in Django, or Wordpress security keys and salts), so you can happily use different ones for dev and production environments, or change them if you see fit or any of your configuration files has leaked. The only problem you’ll have is logged users will lose their session, but they can login again.

As Superset configuration doesn’t specify any other use for this secret, the expected result for changing this value would be losing connected sessions.

Actual results

When accessing to any menu that connects so databases (e.g. a dashboard or a slice), we get a unicode exception, as in issues #2600 or #2966 .
Then, if you figure out that’s not an Unicode error, but an encryption one, and you want to overwrite/change stored passwords on the Database Sources configuration, you’ll get a similar Unicode error, so, not being able to edit MySQL connections.
Unless you manually edit the database, removing password blobs from connections, you won’t be able to do it.

Steps to reproduce

Add a database source and or dashboard
Change your SECRET_KEY in your config file
Restart Superset
Open a slice or dashboard
EXCEPTION

Recommended fix behaviour

Docs should WARN about backing up secret key (I can do that if docs are in source)
Exception should be captured with a more obvious error
Database Sources configuration menu should be accessible, also capturing the error and showing a message that passwords are not accessible, and allow overwriting that password with a new one that will be encoded with the new secret_key

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 6
Comments: 25 (13 by maintainers)

Most upvoted comments

Just got this error. Upgrading superset, got a warning that no SECRET_KEY was set, did set one, now everything broke. Great!

EDIT: the warning should point to the documentation instead of suggesting setting a value without warning about database corruption.

yanickrochon on Oct 31, 2022

It seems like there should at least be a warning if the secret key changes. I’d recommend this issue be re-opened so a warning can be added.

In the meantime, here is how I was able to fix this: https://github.com/apache/superset/issues/8538#issuecomment-922061313

jhult on Sep 18, 2021

Unfortunately, this bug is a time bomb 💣

ghost on Mar 4, 2021

So mine worked out. After changing the SECRET_KEY, I went into superset and re-entered the database passwords sources>databases . database_engine://database_user:[database_password]@ip_address/database

but when i change the secret_key, i can not go to sources>databases , i also got this error, Can you tell me in more detail

i got an solution, add a config DB_SECRET_KEY in config.py it’s value is origin SECRET_KEY, then use config[“DB_SECRET_KEY”] replace config[“SECRET_KEY”] in superset/models/core.py Database model

reesezxf on Aug 18, 2020

So mine worked out. After changing the SECRET_KEY, I went into superset and re-entered the database passwords sources>databases .

database_engine://database_user:[database_password]@ip_address/database

NicholasTurner23 on Jun 28, 2018

@mistercrunch when I add the -d flag it does not pick up my local config, but when I remove it it does. see the output below (note the “loaded your LOCAL config” lines are missing in the debug output). Have also verified that the values are not present in the config, so it’s not just a logging thing:

(superset) $ superset runserver -d
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Starting Superset server in DEBUG mode
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2018-06-28 08:30:48,210:INFO:werkzeug: * Running on http://0.0.0.0:8088/ (Press CTRL+C to quit)
2018-06-28 08:30:48,211:INFO:werkzeug: * Restarting with stat
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Starting Superset server in DEBUG mode
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2018-06-28 08:30:49,964:WARNING:werkzeug: * Debugger is active!
2018-06-28 08:30:49,964:INFO:werkzeug: * Debugger PIN: 172-601-678

(superset) $ superset runserver 
2018-06-28 08:30:59,269:INFO:root:The Gunicorn 'superset runserver' command is deprecated. Please use the 'gunicorn' command instead.
Starting server with command: 
gunicorn -w 2 --timeout 60 -b  0.0.0.0:8088 --limit-request-line 0 --limit-request-field_size 0 superset:app

[2018-06-28 08:30:59 +0200] [14133] [INFO] Starting gunicorn 19.8.1
[2018-06-28 08:30:59 +0200] [14133] [INFO] Listening at: http://0.0.0.0:8088 (14133)
[2018-06-28 08:30:59 +0200] [14133] [INFO] Using worker: sync
[2018-06-28 08:30:59 +0200] [14136] [INFO] Booting worker with pid: 14136
[2018-06-28 08:30:59 +0200] [14138] [INFO] Booting worker with pid: 14138
Loaded your LOCAL configuration at [/home/czue/superset/superset_config.py]
Loaded your LOCAL configuration at [/home/czue/superset/superset_config.py]

czue on Jun 28, 2018

this is also an issue if you switch between debug mode and non-debug mode. debug mode seems to not load your superset_config.py which means that if you start your server in one mode and then switch to the other you also get this error.

is there a supported way to change your secret key if this happens?

czue on Jun 26, 2018