How to test team access after removing a member

To test whether removing a team member takes effect, leave that person signed in, remove their membership from a separate owner session, and repeat a protected request with the member's original session. The expected result is that the next request is denied because your server checks current membership, even if the session itself is still valid. If it succeeds, investigate the authorization path.

This is a test of your application's authorization boundary. A JWT can remain valid and retain old claims until it is refreshed; signing a user in does not by itself prove they still belong to a team. If your policy relies on a role stored in a token, check its refresh and revocation behavior separately. Do not assume that a Supabase Row Level Security policy automatically performs a fresh membership check: inspect and test your own policy and request path.

Run the test with two sessions

Use a disposable team and resource, an owner account, and a separate member account. Keep each account in its own browser profile or client so their cookies do not overlap.

1. As the member, open the team resource and perform an action that the member's role permits. Record the result so a later denial cannot be mistaken for a broken endpoint.
2. Keep that session open. As the owner, remove the member and confirm the removal succeeded in the team's persisted membership state.
3. Without signing out or refreshing the member's token, repeat the same protected API request. Expect the application's access-denied response and no resource data or successful mutation. Check the stored resource through the owner session to confirm a denied write did not change it.
4. Confirm the owner still has access. Then test another team or resource as appropriate to verify that the check uses the requested team's membership, not merely the existence of any membership.

Test the endpoint itself, not only whether a button disappears or a page redirects. For CoreMVP's included Organizations and Projects, the organization detail request checks current membership, and the Projects service reloads the persisted role for its access checks; see Members and Permissions and Test Organizations. Your own team-owned tables and endpoints need their own scoped checks and tests.

If the removed member still has access

Trace the exact request from the route to the authorization decision. Check whether it reloads the membership for the requested team or trusts a role cached in the session or JWT. Check the database policy as well if the client can access data directly. A cached page can also display previously loaded data without making a new request, so inspect the actual network response. If a request already in flight completes during removal, test a new request after removal succeeds; decide separately how your application handles that race.