supertokens / supertokens-website

Frontend SDK for SuperTokens - for session management + automatically refreshing sessions
https://supertokens.com
Other
54 stars 13 forks source link

fix: failiing tests #263

Closed anku255 closed 4 months ago

anku255 commented 4 months ago

Summary of change

This PR has a couple of changes -

1. "test sameSite is none if using iframe" test fix

In #262, we changed getLocalSessionState to be called with tryRefresh: false wherever it wasn't required (such as just after a session was created/refreshed).

This removed unnecessary calls to the refresh API in certain cases. One such is when the FrontToken doesn't get saved (either because of SameSite: None; Secure setting on HTTP non-localhost domain or because of cookie writes being disabled).

The "test sameSite is none if using iframe" test relied on this refresh call. After its removal the test started failing.

The test implementation wasn't correct. It was relying on a side-effect. When isInIframe is set to true, we set the Frontend cookies with SameSite: true; Secure. Since the test domain was http://localhost.org:8080, the browsers simply ignored all the frontend cookies such as anticsrf and frontToken cookie. Prior to #262, we would do a refresh call just after login, this removed all the backend cookies as well (because antiCsrf token was not present). The test was checking that all the cookies would be removed. After #262, the backend cookies were not removed because the /refresh call never happened.

The correct test implementation should have been checking the sameSite and secure attributes of the frontend cookies. However, for this we needed to make sure the domain was localhost and not localhost.org. This PR fixes this and also updates all the tests.

2. Refresh loop while calling the /refresh API is called when front token is not available

While debugging the tests, we found out that if session is not available and a /refresh API is called directly then it would cause a refresh loop (upto 10 times by default).

If there is no session, then preRequestLSS.status would be NOT_EXISTS but postLockLSS.status would be MAY_EXISTS. In onUnauthorisedResponse, the condition preRequestLSS.status !== postLockLSS.status was always true, so it kept looping. This has been fixed.

Related issues

Test Plan

(Write your test plan here. If you changed any code, please provide us with clear instructions on how you verified your changes work. Bonus points for screenshots and videos!)

Documentation changes

(If relevant, please create a PR in our docs repo, or create a checklist here highlighting the necessary changes)

Checklist for important updates

github-actions[bot] commented 4 months ago

size-limit report 📦

Path Size
lib/build/bundleEntry.js 21.31 KB (+0.3% 🔺)