github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

didn't emit error when requireEmailVerification: true with changeEmail.enabled: false and call client.changeEmail #1623

New Issue
Closed
opened 2026-03-13 08:52:03 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-03-13 08:52:03 -05:00
Owner
Copy Link

Originally created by @himself65 on GitHub (Aug 1, 2025).

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

describe("Should throw error if email verification is not enabled", async () => {
	it.only("should throw error if email verification is not enabled", async () => {
		const mockSendVerificationEmail = vi.fn()
		const { client, testUser, db, sessionSetter } = await getTestInstance({
// uncomment here
			// emailAndPassword: {
			// 	enabled: true,
			// 	requireEmailVerification: true
			// },
			emailVerification: {
				async sendVerificationEmail ({ user, url }) {
					mockSendVerificationEmail(user.email, url)
				},
			},
			user: {
				changeEmail: {
					enabled: false,
				},
			},
		})

		const headers = new Headers();
		await client.signIn.email({
			email: testUser.email,
			password: testUser.password,
			fetchOptions: {
				onSuccess: sessionSetter(headers),
				onRequest(context) {
					return context;
				},
			},
		});

		await client.changeEmail({
			newEmail: "new-test2@email.com",
			fetchOptions: {
				headers,
			},
		});
	})
})

Current vs. Expected behavior

should emit at least warning to customer

What version of Better Auth are you using?

latest

Provide environment information

N/A

Which area(s) are affected? (Select all that apply)

Types

Auth config (if applicable)

Additional context

No response

Originally created by @himself65 on GitHub (Aug 1, 2025). ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce ```ts describe("Should throw error if email verification is not enabled", async () => { it.only("should throw error if email verification is not enabled", async () => { const mockSendVerificationEmail = vi.fn() const { client, testUser, db, sessionSetter } = await getTestInstance({ // uncomment here // emailAndPassword: { // enabled: true, // requireEmailVerification: true // }, emailVerification: { async sendVerificationEmail ({ user, url }) { mockSendVerificationEmail(user.email, url) }, }, user: { changeEmail: { enabled: false, }, }, }) const headers = new Headers(); await client.signIn.email({ email: testUser.email, password: testUser.password, fetchOptions: { onSuccess: sessionSetter(headers), onRequest(context) { return context; }, }, }); await client.changeEmail({ newEmail: "new-test2@email.com", fetchOptions: { headers, }, }); }) }) ``` ### Current vs. Expected behavior should emit at least warning to customer ### What version of Better Auth are you using? latest ### Provide environment information ```bash N/A ``` ### Which area(s) are affected? (Select all that apply) Types ### Auth config (if applicable) ```typescript ``` ### Additional context _No response_
GiteaMirror added the enhancement label 2026-03-13 08:52:03 -05:00
GiteaMirror commented 2026-03-13 08:52:05 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Aug 1, 2025):

Better Auth does not currently emit warnings at runtime or type-level when a feature like deleteUser is disabled in the config but still present on the API object. The endpoint remains accessible, and only throws an error (and logs a message) if you actually call it while disabled—there’s no warning or type error just for referencing it in code. This is a known gap and has been discussed as a feature request for more granular disabling and visibility controls, but it hasn’t been implemented yet [source].

If you want stricter enforcement, a common workaround is to manually block forbidden API paths in your handler, but this only affects runtime behavior, not the API surface or TypeScript types. There’s currently no built-in or recommended pattern for surfacing such warnings at the type or API level [source]. If you want to implement a warning mechanism, you’d need to add custom logic either in your own wrapper or propose a change upstream.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 1, 2025): <!-- Answer --> Better Auth does not currently emit warnings at runtime or type-level when a feature like `deleteUser` is disabled in the config but still present on the API object. The endpoint remains accessible, and only throws an error (and logs a message) if you actually call it while disabled—there’s no warning or type error just for referencing it in code. This is a known gap and has been discussed as a feature request for more granular disabling and visibility controls, but it hasn’t been implemented yet [[source](https://github.com/better-auth/better-auth/issues/774)]. If you want stricter enforcement, a common workaround is to manually block forbidden API paths in your handler, but this only affects runtime behavior, not the API surface or TypeScript types. There’s currently no built-in or recommended pattern for surfacing such warnings at the type or API level [[source](https://github.com/better-auth/better-auth/blob/a2474faac6eca88f0b28b2db792bb95c92857128/packages/better-auth/src/api/index.ts)]. If you want to implement a warning mechanism, you’d need to add custom logic either in your own wrapper or propose a change upstream. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/0ef1471a-0331-4cf1-baf6-ddcf49fb7a5f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/0ef1471a-0331-4cf1-baf6-ddcf49fb7a5f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/0ef1471a-0331-4cf1-baf6-ddcf49fb7a5f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/0ef1471a-0331-4cf1-baf6-ddcf49fb7a5f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/0ef1471a-0331-4cf1-baf6-ddcf49fb7a5f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/0ef1471a-0331-4cf1-baf6-ddcf49fb7a5f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/0ef1471a-0331-4cf1-baf6-ddcf49fb7a5f?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3744)
GiteaMirror commented 2026-03-13 08:52:06 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Aug 1, 2025):

I think I was wrong. the error is on client side says UNAUTHORIZED

@himself65 commented on GitHub (Aug 1, 2025): I think I was wrong. the error is on client side says UNAUTHORIZED
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#1623
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?