https://www.growthbook.io/ logo
Powered by
e

elegant-flag-19390

09/27/2022, 1:06 PM
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

future-teacher-7046

09/27/2022, 1:09 PM
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

elegant-flag-19390

09/27/2022, 1:14 PM
When refreshing the page it sends me to the log in screen
f

future-teacher-7046

09/27/2022, 1:15 PM
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

elegant-flag-19390

09/27/2022, 1:17 PM
It does indeed seem to automatically unlog me after about 20 minutes, but this did not happen in version 1.4.0.
f

future-teacher-7046

09/27/2022, 1:20 PM
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

elegant-flag-19390

09/27/2022, 1:25 PM
It seems that I only have 1 cookie: 
__growthbookid
f

future-teacher-7046

09/27/2022, 1:27 PM
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

elegant-flag-19390

09/27/2022, 1:30 PM
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

future-teacher-7046

09/28/2022, 1:46 PM
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

elegant-flag-19390

09/29/2022, 9:27 AM
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
4 Views
Powered by