AIP-38 Fix safari login loop for non ssl - #47859
Conversation
|
Does this mean that deployments must be using https as well? |
| response.set_cookie(COOKIE_NAME_JWT_TOKEN, token, secure=True) | ||
|
|
||
| secure = os.environ.get("DEV_MODE", True) | ||
| response.set_cookie(COOKIE_NAME_JWT_TOKEN, token, secure=secure) |
Check warning
Code scanning / CodeQL
Failure to use secure cookies
|
If deployment do not use https safari will block such secure cookies and indeed this will not work. Is that a popular use case ? Do we need to support safari for that ? |
|
Maybe only enable the |
f80a6dc to
ec208e6
Compare
That alone isn't enough -- it is much more common to use some kind of proxy in front to handle the TLS termination (ALB, Nginx, Kubernetes Ingress etc.) so we'll have to look at something else (at least as well) Well, this "fails working" which is the right thing we want for now, so lets go ahead and merge this for now, but probably create an issue to come back and revisit this with reverse proxies in mind. |
|
It's possible we can look at the Which in turn is available as |
ec208e6 to
fcfb934
Compare
fcfb934 to
ee28852
Compare
|
Issue here #47878, I marked it for 3.0 bugfix for now, we can take a look after the feature freeze |
Safari has a stricter policy when it comes to secure cookies. I will not allow
localhostto use such cookies (https is always required), which is not the case for other browser.This will at least fix the case for the development mode. i.e safari will work in
--dev-modein breeze or by specifying the env variable and running the api_server.There is no issue for real development mode as long as people are using https to connect to their instance.