Necessary sign-in storage
First-party authentication cookies keep the account features working after you choose to sign in.
Cookie policy
This policy describes the cookies and similar browser storage used by the current Mahara pilot. It does not claim that every external provider’s website uses the same controls.
Last updated / version:
This notice describes the current setup. It is not a claim of full Saudi compliance or an opening of children’s services or payments. Transfer, retention, safeguarding and licensing reviews remain requirements before public launch.
First-party authentication cookies keep the account features working after you choose to sign in.
No advertising, behavioural analytics, social embeds or session-recording tools are included in the application.
Browse without signing in, sign out, or remove site data in your browser. Removing cookies does not delete your account.
A cookie is a small value saved by your browser for a site. Mahara uses authentication cookies to recognise a signed-in session and complete sign-in securely. They are first-party cookies on the Mahara hostname you are using; changing from a Vercel address to a custom domain does not move them automatically.
The application does not implement analytics/advertising cookies, a marketing consent cookie, a persistent browser draft, or a localStorage/sessionStorage marketing profile. Forms can hold unsent text in page memory, and browsers can independently offer autofill or password-manager features. We do not describe those browser features as data saved to Mahara’s database.
| Name/pattern | Purpose | When and how long |
|---|---|---|
| sb-<project-ref>-auth-token; possibly .0, .1, … | Supabase session and refresh information for signed-in account features. This is not an advertising identifier. | Created after authentication, renewed during session maintenance and normally cleared on sign-out. The SDK’s cookie maximum is 400 days from a write; browser limits and actual server-side session expiry/revocation can end access earlier. |
| sb-<project-ref>-auth-token-code-verifier; related *-code-verifier flow/index cookies | PKCE proof and pending-flow information for a sign-in attempt, especially Google sign-in. These values help complete the sign-in you initiated. | Created during a sign-in flow and removed as that flow is completed or cleaned up by the SDK. A remaining cookie can inherit the SDK’s maximum of 400 days; that does not make a sign-in code valid for 400 days. |
Cookie values contain sensitive authentication material. Never paste them into chat, email, screenshots or support tickets. Chunk suffixes and per-flow names can vary with the authentication SDK; the patterns above cover those variants.
Cookies use Path=/ and SameSite=Lax, with Secure enabled in production so they are sent over HTTPS. The current Supabase browser client needs JavaScript-readable session storage: these cookies are not marked HttpOnly. Do not interpret that as an assurance against script-based attacks. Server-side access validation remains separate from possessing a cookie.
The expiry stated here is a cookie-storage limit, not a promise to keep you signed in, nor a database retention period. Supabase controls access-token expiry and refresh/revocation rules. Our application has no separate ‘remember me’ cookie.
There are currently no optional tracker categories to accept or reject. We therefore do not show an ‘Accept all’ button or pretend that a preference switch can disable required authentication while keeping you signed in. You can use the public pages without requesting an account session.
If optional analytics, marketing or other non-essential storage is introduced, it must remain off until any required, specific consent is obtained. The inventory and notice must be updated, choices must be equally accessible, and withdrawal must be available. Agreeing to a privacy notice is not permission for future tracking.
Choosing Google sign-in opens Google and Supabase’s authentication flow, where those services apply their own policies and may use their own cookies. The Mahara cookie inventory is not an inventory of Google’s or your email provider’s websites.
Vercel, Supabase and the authentication-email delivery service also process necessary requests, delivery events and technical logs. Not all personal-data processing uses a cookie; an absence of advertising cookies is not an absence of data processing. See the privacy policy for suppliers and cross-border processing. Fonts are delivered from Mahara itself.
This inventory is based on the application source and installed SDK configuration, with signed-out HTTP checks. A full signed-in browser/vendor-cookie audit remains a launch requirement. Hosting or security-provider changes may alter platform-level cookies; update this notice before relying on a changed setup.
Matthew Hanna operates this pilot. Contact maharaksa26@gmail.com about this inventory or a privacy request. Send a description of the issue, not cookie values or sign-in links.
This version is dated 20 October 2026. Review this page when the service or its storage changes. The privacy policy explains your personal-data rights, retention limitations and the parent-managed tutoring plan.