https://www.growthbook.io/ logo
Join Slack
Powered by
Hi, today we have updated GrowthBook from 1.4.0. t...
# announcements
e
Hi, today we have updated GrowthBook from 1.4.0. to 1.6.0. and since the update we are getting the following error after some time logged (20 min. aprox.): 
An error occurred: Format is Authorization: Bearer [token]
How can we fix it?
f
Does refreshing the page fix it?
It should automatically refresh auth tokens in the background when they expire, but that seems to be broken here. I'll take a look and see if I can reproduce it.
e
When refreshing the page it sends me to the log in screen
f
Oh, so you must have gotten logged out. Does this keep happening where it only keeps you logged in for a short period of time?
e
It does indeed seem to automatically unlog me after about 20 minutes, but this did not happen in version 1.4.0.
f
Yes, we completely changed the way authentication works in 1.6.0. Can you see if you have the cookie 
AUTH_REFRESH_TOKEN
set? This is what we use to keep you logged in
e
It seems that I only have 1 cookie: 
__growthbookid
f
Interesting. Any errors in the browser console when you log in? Do you have GrowthBook behind a reverse proxy like nginx that might be stripping out cookies?
e
No errors in the console during log in... I will check the service architecture to be sure we are not stripping out cookies 👍
Hi @future-teacher-7046, I think I know what the issue could be... We have not only migrated from 1.4.0 to 1.6.0 but also have separated the frontend and backend in two different instances with different domains (because we want the backend to be available from "outside" to serve the features but we want the frontend to be available only inside our network to avoid security risks). So I think that's the problem with the cookie. As explained here, if the cookie has not specified the 
SameSite
attribute will be treated as 
SameSite=Lax
and the browser will not accept the cookie (I think that Chrome does not allow changing that behaviour). So, would it be possible to add the attribute to the cookie? Or is there any suggested way of having frontend and backend in two differents instances/domains?
f
Thanks, I'll look into that, it should be easy to reproduce
👍 1
Looks like we could "fix" it by setting 
SameSite=None
, but that would open up some potential security holes from CSRF attacks. Are you able to use subdomains instead of entirely separate domains? So like 
<http://growthbook.example.com|growthbook.example.com>
and 
<http://growthbook-api.example.com|growthbook-api.example.com>
? That should work with 
SameSite=Lax
while still being secure.
e
Thank you, Jeremy! In the end we solved it by having the backend and frontend in the same domain (different subdomains). In any case, as a suggestion, perhaps a configuration option could be added that would allow to choose that attribute for the cookie (for those cases in which it is needed): 
; SameSite=None; Secure
71 Views
Open in Slack
PreviousNext
Powered by