Closed enlightenedmouse closed 4 years ago
Hello, This is a known issue and we are working on resolving it for a new release. This issue should only happen if your website domain is completely different from your API domain - for example, your website is on localhost (during development) and your API is on api.example.com.
However, if your api domain is a subdomain of your website domain (api domain is api.example.com and website domain is example.com), then you can set the cookie domain config to be ".example.com" and things should still work perfectly fine.
In the meantime, since we do not support "non-subdomain" cross-origin requests, you can disable anti-csrf feature for all your APIs (only in dev mode)
Also refrain from using the sessionPossiblyExists()
function. Instead, you can call a backend API that would return session expired error in case there is no active session.
In the new release, we will send the idRefreshToken as a header and save it in a cookie that is accessible to the website domain (not localstorage since website domains may also have subdomains which need to know if a session exists) so that this issue is resolved.
Great.. thanks : ) Would you be able to give an ETA for the new release?
Around Feb 20th. A note that the new release will be a breaking one. We will provide a migration guide when we release it.
There has been a delay of a few days in launching the new version. New expected date of launch is 1st March. I will keep this thread updated if things change.
Hi @rishabhpoddar, Is there any update on this?
Please disregard the last message.
After I updated both the supertokens-website to 4.0.10 and supertokens-node-mysql-ref-jwt to 5.0.1; I was still getting unauthorized errors.
I was able to debug it and turns out it was related to https://github.com/axios/axios/issues/587. Although the issue is closed, when calling axios.get("url", { withCredentials:true });
, it wasn't sending the cross-site cookies. Perhaps it has to do with the OPTIONS request. Not sure.
In any case, setting axios.defaults.withCredentials = true;
seemed to do the trick.
Thanks for the updates : )
I was about to update the issue today, but you figured it out anyway :)
The fix resulted in a protocol change between the frontend and the backend SDK (as you expect), so if there are more issues, please let us know. Just to reiterate, you should only use version v4+ of supertokens-website
.
There have been a few function name changes. To see a migration guide for the new version of supertokens-website
package, please see this link.
Finally, we recommend that you switch to using the community version of SuperTokens which is what we will be actively working on from now on. We will still be maintaining the old version of SuperTokens for bug fixes, but all new features will be added to the community / pro version of SuperTokens. The documentation of the older backend repositories can be accessed via their GitHub repo.
To see instructions on migrating to SuperTokens community version, please see this link. @enlightenedmouse, since you are an existing user, we will be happy to give you dedicated help for migration.
Cross-site Cookies
After updating the server with cors middleware (options = { origin: true, credentials: true }) and front-end axios requests withCredentials:true, session cookies are properly received/sent from/to the server however the response sIdRefreshToken cookie is not accessible via document.cookies. This causes the anti-csrf token to be removed in the axios response interceptor.
Environment
Related code
https://github.com/supertokens/supertokens-website/blob/697847092bffa24d3d1c77c4fcb9c502c15d72e6/axios.ts#L284
Other information
Even after this issue is resolved, the refresh endpoint would not work after the cookie has expired. I believe the solution may be to pass the sIdRefreshToken in a new response header instead of as a cookie and store it in the browser's localStorage instead.