Channels
bot-training
community
contributing
general
github-activity
info
introductions
new-releases
random
security
support-questions
welcome-0xdelusion
welcome-aj-ya
welcome-aleksandrc
welcome-alpinjs
welcome-amberlamps1
welcome-andrew-rodriguez
welcome-ankit-choudhary
welcome-anthony-stod-custodio
welcome-call-in
welcome-chwalbox
welcome-claybiokiller
welcome-co7e
welcome-cosmoecwsa
welcome-devdag
welcome-dinso
welcome-drebotelho
welcome-elio
welcome-ernest
welcome-foxbarrington
welcome-fromscratch
welcome-galto4ir
welcome-goetzum
welcome-hay-kot
welcome-himanshu-kukreja
welcome-hossambarakat
welcome-ichikawakazuto
welcome-jahir9991
welcome-jamesl
welcome-jerry123424
welcome-john-oliver
welcome-jonas-alexanderson
welcome-jxyz
welcome-kelvinwop
welcome-kraz
welcome-lancekey
welcome-leoo
welcome-lukeacollins
welcome-m-j-mon
welcome-malik-khoja
welcome-marco
welcome-mardadi
welcome-meshguy
welcome-metamorph
welcome-mike-tectu
welcome-mirzok
welcome-mozomig
welcome-naberyou66_
welcome-nacer
welcome-namratha
welcome-naveenkumar
welcome-nightlight
welcome-nischith
welcome-notankit
welcome-olawumi
welcome-pavan-kumar-reddy-n
welcome-pineappaul
welcome-poothebear
welcome-rick
welcome-samuel-qosenergy
welcome-samuelstroschein
welcome-shubhamgoel23
welcome-shubhamkaushal
welcome-sidebar
welcome-surajsli
welcome-suyash_
welcome-syntaxerror
welcome-tauno
welcome-tawnoz
welcome-teclali
welcome-tls
welcome-turbosepp
welcome-vikram_shadow
Title
c
Chunkygoo
10/09/2022, 2:09 AMmy frontend keeps attempting to refresh even though i just logged in
Any idea why?
logs
Seems like the cookies are not sent to the backend
r
rp
10/09/2022, 3:48 AMHmm. I think you need to enable sharing of cookies across your api domain and website domain
There should be a config on the frontend called cookieDomain and backend called cookie_domain (in session.init)
Set its value to “.placeholder.info”
This way cookies will be sent to your next server as well as well as to your api domain
c
Chunkygoo
10/09/2022, 3:55 AMI tried that but I have two front ends using Supertokens for auth
If I do that, it works. Except that when I login/logout on one site, the other gets affected too
r
rp
10/09/2022, 3:56 AMCan you elaborate and provide domain names?
c
Chunkygoo
10/09/2022, 3:57 AMYes
So two front ends:
1. www.placeholder.info
2. admin.placeholder.info
Backend
1. api.placeholder.info
Both front ends use the same api
If I have cookieDomain=“.placeholder.info”, when I login to www.placeholder.info, admin.placeholder.info sees that login too
Same thing for logging out
Reason is because they share the domain .placeholder.info
Both front ends see the same access and refresh tokens
r
rp
10/09/2022, 4:02 AMAh yes.
Well, since they both hit the same api endpoint, this problem do the session being shared will happen even if you do not set that cookieDomain config. Is that not happening?
c
Chunkygoo
10/09/2022, 4:06 AMIf I set the cookieDomain, the aforementioned problem occurs
If I don’t set cookieDomain, infinite refresh occurs
I clearly see the cookies in the browser’s application tab. But for some reason it keeps refreshing
r
rp
10/09/2022, 4:07 AMSo you could, set that cookieDomain config, and also set in the access token payload on the backend the domain it’s meant for
c
Chunkygoo
10/09/2022, 4:07 AMThe cookies have the domain “api.placeholder.info” when I do not set cookiedomain
Not sure what you mean
r
rp
10/09/2022, 4:08 AMAnd then in admin site, do session verification, but then also check that the domain it’s meant for is the admin one
c
Chunkygoo
10/09/2022, 4:08 AMIm just a little confused, why is it doing an infinite refresh?
r
rp
10/09/2022, 4:09 AMI mean override the create_new_session function on the backend and in the access token payload, set a custom key value like “forDomain: admin” or “forDomain: non-admin”
c
Chunkygoo
10/09/2022, 4:09 AMIt’s not supposed to do that I think. The cookies have the domain “api.placeholder.info” so it should be sent to the backend no problem, except it’s not?
r
rp
10/09/2022, 4:09 AMIt’s doing an infinite refresh cause maybe ur trying to do session verification in getServerSideProps?
c
Chunkygoo
10/09/2022, 4:09 AMI see
This is true
r
rp
10/09/2022, 4:10 AMYea. So that’s failing cause the cookies are not being sent.
c
Chunkygoo
10/09/2022, 4:10 AMWhy is it failing?
It works locally, only fails in prod
r
rp
10/09/2022, 4:10 AMCause the cookies are not sent. Cause they are attached to the api domain and not the www sub domain
c
Chunkygoo
10/09/2022, 4:11 AMI’m extracting the cookies from context, then sending them to the server
`export async function getServerSideProps(context) {
let cookieString = '';
for (var key of Object.keys(context.req.cookies)) {
cookieString += key + '=' + context.req.cookies[key] + '; ';
}
try {
let myAxios = await myAxiosPrivate();
var res = await myAxios
.get(
/users/mer
rp
10/09/2022, 4:12 AMYea but for that the cookies need to be sent to it by the browser
c
Chunkygoo
10/09/2022, 4:13 AMSo the problem is this function is unable to send the cookies to api.placeholder.info, right?
r
rp
10/09/2022, 4:14 AMNo. The problem is that the browser is not sending cookies to the next server (which runs the getServerSideProps function) cause the cookies are only attached to the api domain, and not the www domain. Setting cookieDomain=.placeholder.info attaches it to both (and admin unfortunately)
c
Chunkygoo
10/09/2022, 4:15 AMAh I see
Damn
r
rp
10/09/2022, 4:15 AMWell, on the admin site, you should anyway have checks for if the userId from the session is an admin or not
c
Chunkygoo
10/09/2022, 4:15 AMI do
r
rp
10/09/2022, 4:15 AMAnd if you have that, even if cookies from the other site are sent to the admin site, it won’t work
As in it will yield with an error state. Which I think is fine
So I think you should add that setting
Or else you will have to give up on server side rendering session verification.
c
Chunkygoo
10/09/2022, 4:17 AMSo right now I have protection for my API
it checks if the user role is "admin"
r
rp
10/09/2022, 4:17 AMRight
c
Chunkygoo
10/09/2022, 4:17 AMSo no problem there
On the admin site
I use SessionAuth for route protection
useEffect(() => {
const abortControllerRefCurrent = abortControllerRef.current;
const wrapper = async () => {
let res = await getCurrentUser(abortControllerRefCurrent);
if (res?.status !== 200 || res?.data.role !== 'admin') {
await signOut();
window.location.reload();
}
setLoading(false);
};
wrapper();
return () => {
abortControllerRefCurrent.abort();
};
}, []);
if (loading) {
return (
<div className="flex h-screen">
<div className="m-auto">
Loading
<Spinner size={10} />
</div>
</div>
);
}r
rp
10/09/2022, 4:18 AMThat runs on the client side. And you can add checks to that to make sure it’s an admin
c
Chunkygoo
10/09/2022, 4:18 AMSo I am doing that
If the user role is not "admin", they will be logged out
There are two problems here
r
rp
10/09/2022, 4:19 AMDon’t log them out. Display an error saying unauthorised.
c
Chunkygoo
10/09/2022, 4:19 AM1. If I log into the admin site first, and then open www.placeholder.info, I am already logged in
r
rp
10/09/2022, 4:20 AMWell yea, on the other site check that it’s not an admin
c
Chunkygoo
10/09/2022, 4:20 AM2. If I login to www.placeholder.info first, depending if I am "admin" or not, I might be logged out
r
rp
10/09/2022, 4:21 AMOk. Let’s say that you do logout the user
Is there a real issue in that though? Cause actual users won’t be switching around these sites anyway
c
Chunkygoo
10/09/2022, 4:23 AMThat differs for people I guess
r
rp
10/09/2022, 4:24 AMHmmm
c
Chunkygoo
10/09/2022, 4:24 AMI'm just curious what the actual solution is
Another weird issue
r
rp
10/09/2022, 4:24 AMWell, unfortunately there isn’t a perfect solution to this. Cause the browser doesn’t allow you to specifiy exact list of domains for cookieDomain
c
Chunkygoo
10/09/2022, 4:24 AMI am logged in to the admin site, and go to www.placeholder.info, it shows that I am not logged in
Although the access and refresh tokens with the domain "placeholder.info" are there
r
rp
10/09/2022, 4:25 AMYea to solve that, you need to set sessionScope config on the frontend’s session.init to .placeholder.info
c
Chunkygoo
10/09/2022, 4:25 AMBut why doesnt the opposite happen?
If I am logged into www.placeholder.info, and go to the admin site, I am logged in
r
rp
10/09/2022, 4:26 AMDoes it do a refresh when you go to the admin site when u first login to www?
c
Chunkygoo
10/09/2022, 4:27 AMNevermind
r
rp
10/09/2022, 4:27 AMThe good solution to this is to just add proper access control to each site and check for that post session verification. That should be good enough. Or else, disable server side rendering session verification
c
Chunkygoo
10/09/2022, 4:27 AMLet me clarify that
So
If I am logged into www.placeholder.info, and then I log in again on the admin site, the logged in user on www.placeholder.info changes
changes to the admin user
r
rp
10/09/2022, 4:28 AMYea. That’s expected.
Cause u logged into the admin site
c
Chunkygoo
10/09/2022, 4:29 AMok makes sense
r
rp
10/09/2022, 4:29 AMAnd sessions are shared
c
Chunkygoo
10/09/2022, 4:29 AMyeap
How should I do a proper access control
r
rp
10/09/2022, 4:30 AMWell.. in admin site check for admin role everywhere post session verification
In non admin site, check for regular role everywhere post session verification
If the roles don’t match up, display an error message.
That’s all
Or redirect the user to the right site
c
Chunkygoo
10/09/2022, 4:30 AMhmm that would require a check on every page right?
and every action (like clicking a button on the admin site)
r
rp
10/09/2022, 4:31 AMYea. But that you can do by adding the appropriate session claim validator to the global validator claim list on the frontend and backend
So whenever u use verifySession or getSession function, it will check for that automatically
Oh wait. Wrong link
Let me send u a code snippet of it since I don’t think this is documented
c
Chunkygoo
10/09/2022, 4:34 AMOk thanks
r
rp
10/09/2022, 4:37 AMSo this goes on the frontend on the admin site in session.init:
tsx
Session.init({
override: {
functions: (oI) => {
return {
...oI,
getGlobalClaimValidators: function (input) {
return [...input.claimValidatorsAddedByOtherRecipes, UserRoleClaim.validators.includes("admin")]
}
}
}
}
})This goes on the frontend for the www site:
Session.init({
override: {
functions: (oI) => {
return {
...oI,
getGlobalClaimValidators: function (input) {
return [...input.claimValidatorsAddedByOtherRecipes, UserRoleClaim.validators.excludes("admin")]
}
}
}
}
})here we make sure that the roles list doesn't have admin role
c
Chunkygoo
10/09/2022, 4:39 AMOk thanks for your help, I appreciate it
It's a weird problem 🥲
r
rp
10/09/2022, 4:41 AMand in the getServerSideProps functions, i guess you don't need to make any changes? Cause the APIs it queries anyway has the right access control check right?
c
Chunkygoo
10/09/2022, 5:12 AMYeap
Thank you
r
rp
10/09/2022, 5:23 AMHappy to help 🙂
Oh. And I forgot to say. If the above role validators fail, SessionAuth will still show the children content, it’s on you to check the failed validators in the children component and render an appropriate error message
You can do that as shown in the link I had sent previously (see the protecting website route section)
It wraps SessionAuth with a component that renders an error message in case the role validator fails. You need to make something like that
c
Chunkygoo
10/09/2022, 11:53 PMCan you keep this thread open? I will need to come back and read this again some time in the future
r
rp
10/10/2022, 3:23 AMYou can save a link to this thread. It will auto archive, but it won’t delete
c
Chunkygoo
10/10/2022, 5:50 PMI see, thanks!