chore: add deprecation notice (#1129) Add deprecation notice and point to new repo.

chore(master): release 2.72.0 (#1090) 🤖 I have created a release *beep* *boop* --- ## [2.72.0](v2.71.1...v2.72.0) (2025-09-11) ### Features * add sign in with ethereum to `signInWithWeb3` ([#1082](#1082)) ([483e24b](483e24b)) ### Bug Fixes * correct typo in GoTrueClient initializePromise comment ([#1093](#1093)) ([3a147b5](3a147b5)) * docs for ethereum ([#1117](#1117)) ([aadf02e](aadf02e)) * update typedoc to 0.23 ([#1113](#1113)) ([91474d6](91474d6)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

feat: mfa with webauthn support (#1118) ## What kind of change does this PR introduce? **Feature** - This PR introduces YubiKey support for Multi-Factor Authentication (MFA) via WebAuthn, enabling users to authenticate with hardware security keys. ## What is the current behavior? Currently, Supabase Auth JS supports two MFA methods: - TOTP (Time-based One-Time Password) authenticators - SMS-based verification ## What is the new behavior? This PR adds full WebAuthn support to the authentication library, the defaults enable yubikey support at the moment, but it allows the user to override some parameters client-side to use other types of passkey methods. The PR adds the 'webauthn' factor type, to `listFactors`, `enroll()`, `challenge()`, and `verify()` (De)serialization of the webauthn reponse/credential object is done behind the scenes via dedicated objects. it also adds a new `experimental` namespace `.mfa.webauthn` which has a `.register()` and `.authenticate()` methods, these methods allows **single click** yubikey 2FA addition with a single function call. additionally, we have `webauthn.{enroll|challenge|verify}()`, which abstract away some of the logic surrounding enrollment, interaction with the verifier, and have defaults for factortype etc. ### Two ways to use the new api: #### Single Step ```typescript const { data, error } = await client.mfa.webauthn.register({	friendlyName: `Security Key ${new Date().toLocaleDateString()}`,	rpId: window.location.hostname,	rpOrigins: [window.location.origin]	}, {	authenticatorSelection: {	authenticatorAttachment: 'platform',	residentKey: 'discouraged',	userVerification: 'discouraged',	requireResidentKey: false	}	});	if (error) throw error;	console.log(data); // <- session ``` #### Multi Step Composition ```typescript const { enroll, challenge, verify } = new WebAuthnApi(client);	return enroll({	friendlyName: params.friendlyName	})	.then(async ({ data, error }) => {	if (!data) {	throw error;	}	console.log(`enrolled factor, id: ${data.id}`, 'success');	return await challenge({	factorId: data?.id,	webauthn: {	rpId: params.rpId,	rpOrigins: params.rpOrigins	},	signal: undefined	});	})	.then(async ({ data, error }) => {	if (!data) {	throw error;	}	console.log(`challenged factor, id: ${data.factorId}`, 'success');	return await verify({	factorId: data.factorId,	challengeId: data.challengeId,	webauthn: {	rpId: params.rpId,	rpOrigins: params.rpOrigins,	type: data.webauthn.type,	credential_response: data.webauthn.credential_response	}	});	})	.then(({ data, error }) => {	if (!data) {	throw error;	}	console.log(`verified factor, id: ${data.access_token}`, 'success');	return data;	}); ``` ## Additional context While this PR focuses on YubiKey support, the architecture is designed to accommodate additional authenticator types in future releases (platform authenticators, passkeys, etc.) without requiring significant refactoring. I've added `webauthn.dom.ts` and `webauthn.errors.ts` which attempt to augment the typescript interfaces for webauthn since they are out of date and there are some new features that its not aware of yet but are publicly available in all major browsers. For all such types, and due to the complexity of the API, I've added comprehensive jsdocs for each parameter with reference to the w3a spec for reference on their usage. in all webauthn related methods, I've added the ability to **override** any of the parameters we pass by default to the `credentials.{get|create}()` method for convenience. This PR is dependent on my previous PR for streamlining types #1116 and this PR for `auth` supabase/auth#2163 --------- Co-authored-by: Stojan Dimitrovski <sdimitrovski@gmail.com>

ci: do not fail on coveralls error (#1121) ## What kind of change does this PR introduce? Add a `fail-on-error: false` to `coveralls` uploads. Change `coverageapp` version used from `master` to `v2`, so that it accepts this input. ## What is the current behavior? Coveralls seems to be failing, and being flaky. ## What is the new behavior? If `coveralls` upload fails, the CI will not fail.

fix: add missing jest-environment-jsdom dependency (#1111) ## What kind of change does this PR introduce? Bug fix ## What is the current behavior? Tests are failing because `jest-environment-jsdom` is not included as a dependency, causing test environment setup issues with DOM-related tests. ## What is the new behavior? Added jest-environment-jsdom v28.1.3 as a devDependency to ensure tests run properly with the jsdom environment configured. ## Additional context The jest-environment-jsdom package was missing from the dependencies, which caused tests that rely on DOM APIs to fail. This fix ensures the proper test environment is available.

fix: docs for ethereum (#1117) Docs mentioned Solana instead of Ethereum.

fix: update typedoc to 0.23 (#1113) ## What kind of change does this PR introduce? Update typedoc to `0.23.28`. This is needed in the monorepo, due to hoisting issues.

chore: secure-proof workflows (#1105) ## What kind of change does this PR introduce? Proactive security hardening - implementing defense-in-depth for our preview release workflow. ## What is the current behavior? The current `preview-release.yml` workflow is **secure in practice** but uses a pattern that could be theoretically vulnerable if our existing safeguards were bypassed. Current workflow security analysis: - ✅ **Protected by maintainer-only label requirement** (`trigger: preview`) - ✅ **No code injection vulnerabilities** (no direct interpolation of user input) - ✅ **Limited permission scope** (only `pull-requests: write`) - ⚠️ **Theoretical risk**: Uses `pull_request_target` while checking out PR head code - ⚠️ **Pattern concern**: Executes `npm ci` and `npm run build` from forks in a context with secrets **Important**: Our workflow was never vulnerable to the attacks seen in the [recent incident](GHSA-cxm3-wv7p-598c) due to our security controls. However, in light of recent supply chain attacks, we're implementing additional layers of security. ## What is the new behavior? Implementing a **zero-trust architecture** that makes exploitation impossible even if all other safeguards fail. ### New Three-Workflow Architecture: 1. **`preview-build.yml`** - Executes untrusted fork code in a completely isolated environment (no secrets, minimal permissions) 2. **`trigger-tests.yml`** - Orchestrates testing using only artifacts (never touches fork code, has access to secrets) 3. **`preview-comment.yml`** - Updates PR status (read-only operations with artifacts) ### Security Improvements: | Security Layer | Previous (Secure) | New (Defense-in-Depth) | |---------------|-------------------|------------------------| | **Maintainer Control** | ✅ Required label | ✅ Required label | | **Code Injection Protection** | ✅ No interpolation | ✅ No interpolation | | **Fork Code Isolation** | ⚠️ Runs with secrets present | ✅ Complete isolation from secrets | | **Workflow Tampering** | ⚠️ Theoretical if branch protection bypassed | ✅ Impossible by design | | **Audit Trail** | ✅ GitHub logs | ✅ Enhanced with explicit PR author logging | | **Community Testing** | ⚠️ Requires trust | ✅ Safe by architecture | ### Key Architectural Benefits: - **Separation of Concerns**: Each workflow has a single, well-defined responsibility - **Artifact-Based Communication**: Data passes through GitHub's artifact system, not workflow contexts - **Fail-Safe Design**: Even if GitHub Actions introduced new vulnerabilities, our architecture would remain secure - **Industry Best Practice**: Aligns with GitHub Security Lab recommendations ## Additional context ### Why make this change now? Following the recent Nx supply chain attack and similar incidents in the ecosystem, we're proactively hardening our security posture. While our existing workflow **was not vulnerable** to the specific attack vectors used against Nx (thanks to our label requirements and lack of code injection points), we recognize that: 1. **Security is not binary** - Defense-in-depth provides resilience against unknown future attacks 2. **Patterns matter** - Even secure implementations of risky patterns can normalize their use 3. **Community confidence** - Demonstrating security leadership builds trust in Supabase's infrastructure ### Risk Assessment: - **Previous risk level**: Low (protected by multiple controls) - **New risk level**: Negligible (architecturally impossible to exploit) - **Implementation risk**: Minimal (preserves all existing functionality) ### Implementation Highlights: - ✅ Maintains full backwards compatibility - ✅ No changes required to existing workflows or processes - ✅ Actually improves functionality (safer community contributions) - ✅ Sets a security standard for other Supabase repositories - ✅ Provides a template for secure CI/CD in the broader ecosystem ### Technical Details: This change replaces a single 167-line workflow with three focused workflows (307 lines total) that: - Eliminate the use of `pull_request_target` with fork code execution - Ensure secrets are never available in the same context as untrusted code - Use GitHub's artifact system for secure inter-workflow communication - Add comprehensive logging for security auditing

fix: correct typo in GoTrueClient initializePromise comment (#1093) ## What kind of change does this PR introduce? Fixes a minor typo in a code comment. ## What is the current behavior? The comment contains a few typos. Please refer to the file changes for details. ## What is the new behavior? The typos in the comment have been corrected. Please refer to the file changes. ## Additional context This is a minor typo fix in a code comment. No functional changes, so I opened a PR directly without an Issue. Please let me know if you'd prefer a separate Issue as well.

chore: added more tests (#1103) ## What kind of change does this PR introduce? Achiving 80% coverage after this PR