M-Salti commented on issue #24579: URL: https://github.com/apache/superset/issues/24579#issuecomment-1817783099
> 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](https://owasp.org/www-community/controls/SecureCookieAttribute), 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@superset.apache.org For additional commands, e-mail: notifications-h...@superset.apache.org
