https://supertokens.com/ logo
Join Discord
Powered by
Hey <@498057949541826571> Need your help with some...
# support-questions-legacy
s
Hey @rp_st Need your help with something. So we use AWS apmplify to deploy and preview our frontend build and it has different URL's for different PR's of the type(https://pr-number.xyz.amplifyapp.com), so with supertokens we are unable to get the PR previews to work.(Since i guess we need to provide the website url to the backend SDK at the time of initialization) Any thoughts on this?
r
Hey!
On the frontend, you can set the websiteDomain to be 
window.location.origin
for example.
s
yeah on the frontend we did that
r
Is the backend a separate service on a different domain? Or is it on the same same URL?
s
domain is same for the backend.
r
Is there some env var which is exposed by aws to get the URL?
For example, with vercel, they have 
process.env.VERCEL_URL
is there something similar?
(for the backend)
h
Hey @rp_st Jumping in here. (I work with @showtim33 )
r
Hey!
h
So the scenario is that aws amplify does a deployment for each PR which we raise since a deployment is done for each PR, the urls are different. something like 
pr-${xyz}.abc.amplifyweb.com
Earlier, when we were using cognito, we were just using the origin header and doing regex matching (to ensure the domain was a trusted one) and then handling redirect url as per that.
Not sure if st allows, but a viable solution could be to provide interceptors, so that we can override / tweak the final url users are redirected to.
r
You just need to be able to set the correct values for websiteDomain on the frontend and backend, and it should all work fine
on the forntend, you can use 
window.location.origin
for websiteDomain and apiDomain
h
So the backend remains the same.
as in the backend part (where st is used) isn't deployed separately for each pr.
r
right.. so that may be an issue for now. We are working on something to make it more dynamic, but until then, you can set the websiteDomain to just be the prod one. This will only affect the links for passwordless login / reset password and email verification
if you want those to work as well, you can override the emailDelivery config to change those links based on the request's origin (which should point to the dynamically generated URLs)
And you may want to set cookieSameSite to 
none
in session.init.
Then it should all work.
h
alright cokieSameSite seems like the way to go. Any idea on security implications of this?
r
It would work just fine - since we do automatic anti-csrf protection in this case.
and as long as your allowed-origin list is not "*" it should be fine
h
Great. Thanks.
2 Views
PreviousNext
Powered by