is it possible to prevent ST from adding Authorization: Bearer TOKEN ? 🙂 We're using header-based auth, but we also have basic auth on out test sites, to prevent outsiders from snooping around 😛 We're already adding the token to a custom header

Are you using fetch?

AxiosInstance, so guess it's Axios :p

right. So this may be quite annoying for you, but, you would need to create your own XHR interceptor wrapper that wraps the in build XHR global instance, to remove the authorization bearer token that we add and instead use the the custom header that you use. And you want to add this wrapper before calling supertokens.init on the frontend. If you don't do it this way, refresh flows will encounter problems.

we have a gateway in front of everything that takes the custom header and changes it to a Authorization: Bearer TOKEN before sending the request downstream

hm

so it just shouldn't add it

But calls from the web-js SDK, like

signOut

for example, would add it to the authorization header - would that be OK?

not really no. We want to prevent it always - again, the request is first sent to our gateway which takes our custom header and converts it to an auth header, so ST backend will still receive it in the auth bearer header

so how are you managing sign out calls at the moment?

we add the token to x-olympus-auth-token. That request goes to our gateway, get converted to an authorization: Bearer TOKEN header, then passed on to ST backend. ST backend then responds which goes back to gateway before hitting the frontend frontend --> gateway --> conversion happens --> upstream to ST backend --> gateway --> frontend

right, but then when you call the signOut function from our web-js SDK, then how do you add this custom token to the request? Since the request is made by our sdk. Or do you not use any of the functions from our sdk?

hmm.. Good question.. Maybe we don't currently add it on your requests.. We want to do that though.. So guess we should add an intercepter for this then

yeaaa.. not for this unforeunately. You will also need to add interceptor for fetch in this case (cause our sdk uses fetch)

thanks 🙂

> to prevent outsiders from snooping around Why would adding custom header instead of using standard authorization header help with this issue?

we have basic auth on the ENTIRE website

I see. So someone can use those tokens and add them to the prod website and then they would be identified as the test user, but on the prod site?

no, they are not allowed on prod site - I've come up with as olution for the issue :p