https://supertokens.com/ logo
Join Discord
Powered by
Some feedback -- if a user hits the /auth/signout ...
# support-questions-legacy
z
Some feedback -- if a user hits the /auth/signout route WITHOUT the right cookies (i.e. missing a refresh token cookie, or no cookies at all) the backend will 200 OK. If you enable debug logs it'll show something is amiss, but the 200 OK is very misleading. Similar on the frontend -- it'd be nice to get verbose output upon misconfigured 
SameSite
and cookies not being stored properly. Cost 2-3 hours of dev time spinning wheels yesterday in local environment trying to figure that one out. Signout was simply doing nothing and it wasn't obvious what was broken.
p
thanks for the feedback 🙂 What do you think would be appropriate response for the signout route in this case? I think responding with unauthorized to a signout request is strange. I'll check if we can detect such misconfiguration, but the difficulty with this is that the frontend can't directly detect that anything went wrong - they are httponly cookies, while the backend just doesn't get them which is the same as someone without a session calling these endpoints.
z
I'd think 400 Bad Request maybe?
I was pretty surprised the frontend didn't throw any errors when it failed to store a refresh token as well
p
Hmm, I'm not sure if that fits 100%, but we'll discuss this internally. It may be a good solution to distinguish this case.
z
Thanks for taking the feedback and for all your hard work on a great product!
p
The frontend doesn't really store the refresh token. If the samesite is misconfigured the browser just refuses to handle that part of the response headers. We can't really check.
Happy you like it and feedback is always great - it's one of the great problems when developing an SDK like this, since we can't really check how many people use each feature, and what people like/dislike.
z
My one other feedback - on the backend, in NodeJS -- it's not obvious what the recipe lifecycle is, especilaly in what order which api/function overrides occur. I had to figure it out via trial and error. It'd also be nice if supertokens gave a convenient way to share state between override functions, I managed to do it via the Express.Request object, but an out of the box recommendation would've saved time.
(e.g. I wanted to put the email as a claim on a JWT token, had to get the email from the emailpassword recipe into the createNewSession override)
p
Maybe the advanced customizations section could use a bit more documentation. Do you think it'd be worth it to add some kind of flowchart of function calls for each API endpoint (in each recipe)?
although most APIs are only calling a single function
z
Ah, I totally didn't see that article. Is it available on all the recipe guides? And re: flowchart - I think that's a great idea!
I also imagine the usecase of wanting the user's username/email to be available in subsequent overrides to be very common. Maybe some recipes adding relavent data to 
userContext
by default would be a nice developer quality of life improvement.
p
it is 🙂
PreviousNext
Powered by