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

Feedback and Questions About Better-Auth Features and Use Cases #515

New Issue
Closed
opened 2026-03-13 07:50:34 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-03-13 07:50:34 -05:00
Owner
Copy Link

Originally created by @lu-perfect on GitHub (Jan 3, 2025).

First of all, I’d like to express how much I love Better-Auth — it’s an amazing library! Thank you for the great work. If I missed answers to any of the following questions in the documentation, I sincerely apologize. I’d greatly appreciate your help clarifying these points:

  1. unlinkAccount and providerId:
    Why does the unlinkAccount function require only the providerId and not the accountId?

    • Is there a current restriction that prevents linking multiple accounts for the same provider to a single user?
    • If such a restriction exists, the issue is resolved. If not, how should unlinking be handled in cases where there are multiple accounts per provider?

  2. Disabling Password Authorization:

    • Is there a way to disable password-based login for specific users, e.g., if they prefer to authenticate only via OAuth or other methods?
    • Additionally, how should cases be handled where a user registers via OAuth and doesn’t have a password? The changePassword function currently requires a currentPassword, which is not applicable in such scenarios.

  3. Audit Trails:

    • Is there an existing mechanism for logging audit-trail-like events (e.g., login, logout, password changes)?
    • Would you recommend using databaseHooks for this, or is there a unified solution (or one in the works)?

  4. Admin Plugin User Data:

    • The admin plugin currently lacks a way to fetch data about a single user. Would it be possible to add this functionality?

  5. Server-Side User Context:

    • Are there plans to implement a server-side context to store the user data, so it can be retrieved directly with a hook (without needing a api request from client)?
    • Or are there specific reasons why this approach is discouraged?

  6. Custom Avatar Handling:

    • Our user avatars are stored in S3, and if a user doesn’t have an avatar, we use a simple service to dynamically generate one (e.g., /api/avatars?name=john+doe).
    • Instead of an image field in the database, we use a storageObjectId field that links to a StorageObject table where all uploaded files are stored. Depending on the scenario, we either fetch the key from S3 to generate a signed URL for the avatar or call the dynamic generation service.
    • Since the avatar URL is always dynamically generated and not directly stored in the database, how would you recommend handling this use case in Better-Auth?

  7. impersonateUser:

    • The impersonateUser feature is fantastic! Could you help with an example of how to allow the impersonator to end the session and return to their original account?
    • Would this require implementing multi-session support?

  8. Restricting Registration and Login:

    • How can we restrict user registration based on certain parameters (e.g., IP address, location, etc.) or disable registration altogether?
    • Similarly, how can login be restricted based on these criteria?

  9. API Customization:

    • Is there a way to disable specific routes or change their pathname?
    • Ideally, this should automatically reflect in Swagger documentation.

Thank you in advance for your time and insights. The Better-Auth library truly simplifies authentication processes on a grand scale, and I’m excited to see how it continues to evolve!

Originally created by @lu-perfect on GitHub (Jan 3, 2025). First of all, I’d like to express how much I love **Better-Auth** — it’s an amazing library! Thank you for the great work. If I missed answers to any of the following questions in the documentation, I sincerely apologize. I’d greatly appreciate your help clarifying these points: 1. **`unlinkAccount` and `providerId`:** Why does the `unlinkAccount` function require only the `providerId` and not the `accountId`? - Is there a current restriction that prevents linking multiple accounts for the same provider to a single user? - If such a restriction exists, the issue is resolved. If not, how should unlinking be handled in cases where there are multiple accounts per provider? 2. **Disabling Password Authorization:** - Is there a way to disable password-based login for specific users, e.g., if they prefer to authenticate only via OAuth or other methods? - Additionally, how should cases be handled where a user registers via OAuth and doesn’t have a password? The `changePassword` function currently requires a `currentPassword`, which is not applicable in such scenarios. 3. **Audit Trails:** - Is there an existing mechanism for logging audit-trail-like events (e.g., login, logout, password changes)? - Would you recommend using `databaseHooks` for this, or is there a unified solution (or one in the works)? 4. **Admin Plugin User Data:** - The admin plugin currently lacks a way to fetch data about a single user. Would it be possible to add this functionality? 5. **Server-Side User Context:** - Are there plans to implement a server-side context to store the user data, so it can be retrieved directly with a hook (without needing a api request from client)? - Or are there specific reasons why this approach is discouraged? 6. **Custom Avatar Handling:** - Our user avatars are stored in S3, and if a user doesn’t have an avatar, we use a simple service to dynamically generate one (e.g., `/api/avatars?name=john+doe`). - Instead of an `image` field in the database, we use a `storageObjectId` field that links to a `StorageObject` table where all uploaded files are stored. Depending on the scenario, we either fetch the `key` from S3 to generate a signed URL for the avatar or call the dynamic generation service. - Since the avatar URL is always dynamically generated and not directly stored in the database, how would you recommend handling this use case in **Better-Auth**? 7. **`impersonateUser`:** - The `impersonateUser` feature is fantastic! Could you help with an example of how to allow the impersonator to end the session and return to their original account? - Would this require implementing multi-session support? 8. **Restricting Registration and Login:** - How can we restrict user registration based on certain parameters (e.g., IP address, location, etc.) or disable registration altogether? - Similarly, how can login be restricted based on these criteria? 9. **API Customization:** - Is there a way to disable specific routes or change their `pathname`? - Ideally, this should automatically reflect in **Swagger** documentation. Thank you in advance for your time and insights. The Better-Auth library truly simplifies authentication processes on a grand scale, and I’m excited to see how it continues to evolve!
GiteaMirror commented 2026-03-13 07:50:35 -05:00
Author
Owner
Copy Link

@Bekacru commented on GitHub (Jan 3, 2025):

  1. Currently, one user can only link one account from a provider. We assume a provider will have different emails for different account IDs.

  2. To disable passwords for specific users, you can use hooks and store their preferences somewhere. For setting a password for an OAuth user, you can either use the "forgot password" workflow or call auth.api.setPassword through a custom endpoint.

  3. Hooks are better suited for this than database hooks.

  4. Feel free to open a feature request.

  5. Better Auth is framework-agnostic, so we try to avoid this level of abstraction. But, you can always implement this yourself by building a small abstraction layer.

  6. I'm not sure how you should handle this. You can ignore the image field or update it to reference s3 url on database hooks.

  7. stopImpersonating is implemented, but I just realized it's not documented yet. It will be soon.

  8. You can use hooks for this.

  9. Hooks can be used here again, but for the Swagger documentation, if there’s no similar issue opened feel free to open one. That should be implemented.

And thanks for the kind words!

@Bekacru commented on GitHub (Jan 3, 2025): 1. Currently, one user can only link one account from a provider. We assume a provider will have different emails for different account IDs. 2. To disable passwords for specific users, you can use hooks and store their preferences somewhere. For setting a password for an OAuth user, you can either use the "forgot password" workflow or call `auth.api.setPassword` through a custom endpoint. 3. Hooks are better suited for this than database hooks. 4. Feel free to open a feature request. 5. Better Auth is framework-agnostic, so we try to avoid this level of abstraction. But, you can always implement this yourself by building a small abstraction layer. 6. I'm not sure how you should handle this. You can ignore the `image` field or update it to reference s3 url on database hooks. 7. `stopImpersonating` is implemented, but I just realized it's not documented yet. It will be soon. 8. You can use hooks for this. 9. Hooks can be used here again, but for the Swagger documentation, if there’s no similar issue opened feel free to open one. That should be implemented. And thanks for the kind words!
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
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#515
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?