github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-24 16:11:53 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #6059] Clarify field renaming #19043

New Issue
Closed
opened 2026-04-15 17:49:27 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-15 17:49:27 -05:00
Owner
Copy Link

Originally created by @maelp on GitHub (Nov 18, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/6059

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

The BetterAuth lib allows to rename user, session, or plugin fields (for instance in my case, I want fields in my database and in my User objects to be snake_case instead of the default BetterAuth camelCase)

so I've added renaming like eg:

  user: {
    modelName: "usersTable",
    fields: {
      emailVerified: "email_verified",
      createdAt: "created_at",
      updatedAt: "updated_at",
    },

but when I get a user in a BetterAuth middleware, the fields are not yet renamed:

contextUser={
  "name": "Gouach Admin",
  "email": "admin@gouach.com",
  "emailVerified": true,
  "image": null,
  "createdAt": "2025-11-18T10:23:12.377Z",
  "updatedAt": "2025-11-18T10:23:12.377Z",
  "role": "admin",
  "banned": null,
  "banReason": null,
  "banExpires": null,
  "description": "System administrator",
  "status": "active",
  "last_login_at": null,
  "partner_id": null,
  "user_role": "internal:admin",
  "id": "internal-user-0"
}

is that expected?

  1. Perhaps it should be clearly documented somewhere (how / when fields are renamed)
  2. This also means (I guess?) that we can't "swap" fields, eg if I want that the BetterAuth admin plugin "role" be called "better_auth_role", and that I define my own (user) "role" field, it's going to conflict?``

Describe the solution you'd like

I'd like that once I decide to rename fields, everytime I get a "User" object from BetterAuth, or everytime I'm sending a User object to some BetterAuth method or API, it is in the "renamed field" format, not the "default format"

Describe alternatives you've considered

Create some helper methods to do the conversion, and add "logs" to know what format a data is given in at each method, but this is not clear. At the very least, it should be documented in the BetterAuth docs

Additional context

No response

Originally created by @maelp on GitHub (Nov 18, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/6059 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. The BetterAuth lib allows to rename user, session, or plugin fields (for instance in my case, I want fields in my database and in my User objects to be snake_case instead of the default BetterAuth camelCase) so I've added renaming like eg: ```ts user: { modelName: "usersTable", fields: { emailVerified: "email_verified", createdAt: "created_at", updatedAt: "updated_at", }, ``` but when I get a user in a BetterAuth middleware, the fields are not yet renamed: ```json contextUser={ "name": "Gouach Admin", "email": "admin@gouach.com", "emailVerified": true, "image": null, "createdAt": "2025-11-18T10:23:12.377Z", "updatedAt": "2025-11-18T10:23:12.377Z", "role": "admin", "banned": null, "banReason": null, "banExpires": null, "description": "System administrator", "status": "active", "last_login_at": null, "partner_id": null, "user_role": "internal:admin", "id": "internal-user-0" } ``` is that expected? 1. Perhaps it should be clearly documented somewhere (how / when fields are renamed) 2. This also means (I guess?) that we can't "swap" fields, eg if I want that the BetterAuth admin plugin "role" be called "better_auth_role", and that I define my own (user) "role" field, it's going to conflict?`` ### Describe the solution you'd like I'd like that once I decide to rename fields, everytime I get a "User" object from BetterAuth, or everytime I'm sending a User object to some BetterAuth method or API, it is in the "renamed field" format, not the "default format" ### Describe alternatives you've considered Create some helper methods to do the conversion, and add "logs" to know what format a data is given in at each method, but this is not clear. At the very least, it should be documented in the BetterAuth docs ### Additional context _No response_
GiteaMirror added the lockedenhancement labels 2026-04-15 17:49:27 -05:00
GiteaMirror commented 2026-04-15 17:49:28 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Nov 18, 2025):

(tag @better-auth-agent if you would like an answer from the Agent)

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3546788641 --> @better-auth-agent[bot] commented on GitHub (Nov 18, 2025): (tag @better-auth-agent if you would like an answer from the Agent) <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-15 17:49:29 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Nov 18, 2025):

Yes, this is expected. In BetterAuth, field renaming only changes the database column names, not the field names in user objects returned by middleware or APIs. The logical field names (like emailVerified, createdAt) are always used in your application code and API, regardless of how you map them to the database. This matches how most ORMs work—the mapping is invisible to the client and middleware, and only affects storage in the database. If you want a field to appear with a different name in the API or middleware, you need to define it as an additional field, not just rename it in the config.

Swapping or redefining fields (like renaming role to better_auth_role and adding your own role) can cause conflicts, since BetterAuth expects exact field name matches and does not support aliasing or swapping internally. There’s no built-in support for automatic renaming of fields in middleware user objects; you’d need to handle this manually if you want a different format everywhere.

This behavior is intentional and has been confirmed by the maintainers, but it’s not well documented and can be confusing—especially for plugin fields like role, where the admin plugin does not fully respect renaming and may require workarounds. More details and examples are in these discussions: 1, 2.

To reply, just mention @dosu.

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

<!-- gh-comment-id:3546854982 --> @dosubot[bot] commented on GitHub (Nov 18, 2025): <!-- Answer --> Yes, this is expected. In BetterAuth, field renaming only changes the database column names, not the field names in user objects returned by middleware or APIs. The logical field names (like `emailVerified`, `createdAt`) are always used in your application code and API, regardless of how you map them to the database. This matches how most ORMs work—the mapping is invisible to the client and middleware, and only affects storage in the database. If you want a field to appear with a different name in the API or middleware, you need to define it as an additional field, not just rename it in the config. Swapping or redefining fields (like renaming `role` to `better_auth_role` and adding your own `role`) can cause conflicts, since BetterAuth expects exact field name matches and does not support aliasing or swapping internally. There’s no built-in support for automatic renaming of fields in middleware user objects; you’d need to handle this manually if you want a different format everywhere. This behavior is intentional and has been confirmed by the maintainers, but it’s not well documented and can be confusing—especially for plugin fields like `role`, where the admin plugin does not fully respect renaming and may require workarounds. More details and examples are in these discussions: [1](https://github.com/better-auth/better-auth/issues/3847), [2](https://github.com/better-auth/better-auth/issues/4408). <!-- 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/298faa32-0802-4f00-bc33-ad4b486c6cba?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/298faa32-0802-4f00-bc33-ad4b486c6cba?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/298faa32-0802-4f00-bc33-ad4b486c6cba?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/298faa32-0802-4f00-bc33-ad4b486c6cba?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/298faa32-0802-4f00-bc33-ad4b486c6cba?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/298faa32-0802-4f00-bc33-ad4b486c6cba?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/298faa32-0802-4f00-bc33-ad4b486c6cba?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/6059)
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 locked
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#19043
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?