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

[GH-ISSUE #2669] Handle soft delete for user #9293

New Issue
Closed
opened 2026-04-13 04:43:14 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-13 04:43:14 -05:00
Owner
Copy Link

Originally created by @MarkLee425 on GitHub (May 16, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2669

Is this suited for github?

  • Yes, this is suited for github

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

Currently there is only hard delete in the solution.

Describe the solution you'd like

Add a soft delete option, which will have a function for updating the fields (e.g. revoked_at: current_timestamp / isRevoked: true)

Describe alternatives you've considered

Currently the alternatives is to turn off hard delete option, and manually update it through updateUser / updateAccount etc.

Additional context

No response

Originally created by @MarkLee425 on GitHub (May 16, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2669 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Currently there is only hard delete in the solution. ### Describe the solution you'd like Add a soft delete option, which will have a function for updating the fields (e.g. revoked_at: current_timestamp / isRevoked: true) ### Describe alternatives you've considered Currently the alternatives is to turn off hard delete option, and manually update it through updateUser / updateAccount etc. ### Additional context _No response_
GiteaMirror added the locked label 2026-04-13 04:43:14 -05:00
GiteaMirror commented 2026-04-13 04:43:18 -05:00
Author
Owner
Copy Link

@MarkLee425 commented on GitHub (May 31, 2025):

Just found it impossible to add the sign in and sign up logic to check the revoked_at is null or not...

<!-- gh-comment-id:2925047892 --> @MarkLee425 commented on GitHub (May 31, 2025): Just found it impossible to add the sign in and sign up logic to check the revoked_at is null or not...
GiteaMirror commented 2026-04-13 04:43:20 -05:00
Author
Owner
Copy Link

@MarkLee425 commented on GitHub (May 31, 2025):

My recommended solution is to change the current deleteUser property logic.

Add a "mode" option to decide the mode is "hard delete" or "soft delete". Keep all the existing logic into hard delete mode.

SOFT DELETE:
User should have added their additional fields already and deleteUser can have 3 options, signUpCriteria, signInCriteria and onDeleteData.

signUpCriteria: add criteria to sign up (i.e. check for user that revoked_at IS NULL)

signInCriteria: same logic as signUpCriteria

onDeleteData: this should be updated for the specific user. i.e. { revoked_at: }

The logic will be update the onDeleteData to the user. Then destroy the session and cookies, and then redirect to the sign in page or redirectUrl.

Let me know if there are better solutions...

<!-- gh-comment-id:2925076463 --> @MarkLee425 commented on GitHub (May 31, 2025): My recommended solution is to change the current deleteUser property logic. Add a "mode" option to decide the mode is "hard delete" or "soft delete". Keep all the existing logic into hard delete mode. SOFT DELETE: User should have added their additional fields already and deleteUser can have 3 options, signUpCriteria, signInCriteria and onDeleteData. signUpCriteria: add criteria to sign up (i.e. check for user that revoked_at IS NULL) signInCriteria: same logic as signUpCriteria onDeleteData: this should be updated for the specific user. i.e. { revoked_at: <currentTimestamp> } The logic will be update the onDeleteData to the user. Then destroy the session and cookies, and then redirect to the sign in page or redirectUrl. Let me know if there are better solutions...
GiteaMirror commented 2026-04-13 04:43:21 -05:00
Author
Owner
Copy Link

@maelp commented on GitHub (Sep 5, 2025):

Would be interested in this too, @Kinfe123 why don't you think this should be added? In general all my resources have linked to userId (eg comments, created items, etc), so if I delete a user, all those will be invalid (because I'm using user_id: id.references(users.id)) so I'd need a soft-delete for this

<!-- gh-comment-id:3257563378 --> @maelp commented on GitHub (Sep 5, 2025): Would be interested in this too, @Kinfe123 why don't you think this should be added? In general all my resources have linked to userId (eg comments, created items, etc), so if I delete a user, all those will be invalid (because I'm using `user_id: id.references(users.id)`) so I'd need a soft-delete for this
GiteaMirror commented 2026-04-13 04:43:22 -05:00
Author
Owner
Copy Link

@mortenson commented on GitHub (Mar 11, 2026):

I ended up allow-listing better auth routes to not allow access to deletion, then added these hooks for "peace of mind":

  databaseHooks: {
    account: {
      delete: {
        before: () => {
          throw new Error("Unreachable case: account.delete");
        },
      },
    },
    session: {
      delete: {
        before: () => {
          throw new Error("Unreachable case: session.delete");
        },
      },
    },
    user: {
      delete: {
        before: () => {
          throw new Error("Unreachable case: user.delete");
        },
      },
    },
  },

You can also return false from the before hook(s) and implement soft delete yourself. For instance, I did this with sessions to expire the session immediately instead of deleting it.

<!-- gh-comment-id:4039789382 --> @mortenson commented on GitHub (Mar 11, 2026): I ended up allow-listing better auth routes to not allow access to deletion, then added these hooks for "peace of mind": ``` databaseHooks: { account: { delete: { before: () => { throw new Error("Unreachable case: account.delete"); }, }, }, session: { delete: { before: () => { throw new Error("Unreachable case: session.delete"); }, }, }, user: { delete: { before: () => { throw new Error("Unreachable case: user.delete"); }, }, }, }, ``` You can also return false from the before hook(s) and implement soft delete yourself. For instance, I did this with sessions to expire the session immediately instead of deleting it.
GiteaMirror commented 2026-04-13 04:43:24 -05:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 1, 2026):

This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.

<!-- gh-comment-id:4166555386 --> @github-actions[bot] commented on GitHub (Apr 1, 2026): This issue has been locked as it was closed more than 7 days ago. If you're experiencing a similar problem or you have additional context, please open a new issue and reference this one.
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 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#9293
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?