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 <[email protected]>

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