Documentation incorrect: SESSION_COOKIE_SECURE is true by default

[ewan-escience]

On https://superset.apache.org/docs/security/, it say that the value of SESSION_COOKIE_SECURE is by default False. However, trying it out through Docker, in the response header you can see that the cookie is set to be Secure (and indeed, I cannot login).

Additionally, it would be nice if this could be configured through an --env flag when using docker run.

[sfirke]

I wonder where that value of Secure is getting set. I am looking at the config.py which is the default values if they're not overridden elsewhere and it looks like that variable defaults to False: https://github.com/apache/superset/blob/master/superset/config.py#L1475

So somewhere in the process, your Docker deployment is overwriting that, I think.

[ewan-escience]

I'm following the instructions from Docker Hub to run Apache Superset and don't overwrite the vaue of SESSION_COOKIE_SECURE myself. Is the value in config.py actually being used, both when and when not using Docker?

[sfirke]

Hm I wonder if the default value in the Talisman config is overwriting the default value of SESSION_COOKIE_SECURE. See #24579 (the latest relevant post in a long thread about a large barrier for new users).

It sounds like at the very least we need to update the docs as you suggest, so I appreciate you working this out. If you set SESSION_COOKIE_SECURE = False in your config, leaving the default Talisman CSP in place, does it work? Basically I'm thinking about which "wins" in a conflict. In this conversation we're finding (I think) that the Talisman CSP default value of True is winning over the Superset default value of False. But what if the user specifies SESSION_COOKIE_SECURE = False ? If that doesn't win then that variable is useless I think?