Better Auth•4mo ago

How to delete a user creates with oauth?

Is there a way to use the deleteUser api for a user that, for example, signed up via google? As soone as the session isn't fresh the api required a password, but oauth users don't have a password. Do I have to manually cover these use cases? If yes, how can I generate my own token and send it to that user's email?

59 Replies

Blank•4mo ago

https://www.better-auth.com/docs/concepts/users-accounts#adding-verification-before-deletion try this

User & Accounts | Better Auth

User and account management.

DukiOP•4mo ago

I am doing this, but as mentioned above. You need to provide a password if the session isn't fresh anymore. An oauth user has no password.

Blank•4mo ago

what happens if you call it without a password

DukiOP•4mo ago

It tells me to re-authenticate

Blank•4mo ago

ah there is no api to trigger the send delete mail manually

DukiOP•4mo ago

Yea but even if there was, How would I generate a token, which tells BA to delete said user?

Blank•4mo ago

ok so you just need to add the method for sending email and call authClient.deleteUser({}); it will send a email with a link which will delete the user

DukiOP•4mo ago

I am providing a function already. When I call deleteUser I get the error code SESSION_EXPIRED_REAUTHENTICATE_TO_PERFORM_THIS_ACTION

Blank•4mo ago

:hmm: let me check the code

DukiOP•4mo ago

Which means I need to provide a password to the deleteUser function but a user created via google, doesn't have a password

Blank•4mo ago

no you should not need to have a password

DukiOP•4mo ago

Isn't it what this section says? https://www.better-auth.com/docs/concepts/users-accounts#authentication-requirements

User & Accounts | Better Auth

User and account management.

Blank•4mo ago

yeah you could also pass in a token but you dont have a api to generate it

DukiOP•4mo ago

yea exactly

Blank•4mo ago

i think there are missing apis which needs to be implemented @bekacru

Blank•4mo ago

it short circuits in the freshAge function, so passing in token also would not help even if you got one

bekacru•4mo ago

“sendDeleteAccountVerification” this is the api, but this means you’d need to send them the form to their email

Blank•4mo ago

yeah but how do you trigger it manually?

bekacru•4mo ago

You can set freshAge to 0 to bypass fresh age checks. But if you just to delete user directly, I suggest making another endpoint Yeah we don’t have a direct method. Even if we had, wouldn’t be exposed to the client

Blank•4mo ago

yeah that would be a server method so the best optioin is to make a api endpoint on their own server and call auth.api.deleteuser from there?

DukiOP•4mo ago

Can I temporarily set the freshAge to 0? I'm actually doing this in a formAction in svelteKit

Blank•4mo ago

:Okay:

bekacru•4mo ago

I mean if you’re already on the server, just call your orm but we may should consider different flow for the server side call No I mean you can using hooks Just return new context

Blank•4mo ago

I think we are using a custom delete at zero but something needs to be done for oauth users, like triggering the send verification email on server

DukiOP•4mo ago

I like the idea of the verfication email, not only because of security reasons but also because the user has to double commit the delete action.

bekacru•4mo ago

Oh that’s should be possible

Blank•4mo ago

ok should I make a pr? btw i have updated my old pr as you wanted

DukiOP•4mo ago

@Blank Thanks a lot four your help btw 😊

Blank•4mo ago

:neuroHeart:

bekacru•4mo ago

I think the only issue here is, we don’t have to be checking for fresh age, if we’re sending them the token to their email.

Blank•4mo ago

there is like nothing we can do for oauth user's either way, forcing them to re login is one option but then we dont need the api either way

bekacru•4mo ago

Which one was it?

Blank•4mo ago

https://github.com/better-auth/better-auth/pull/2643

GitHub

fix: use dynamic list of social providers to allow generic oauth by...

fixes #2610 ref #2557 (comment) the endpoints now use the soclal provider list in context so that generic oauth plugin providers are also allowed in token endpoints

bekacru•4mo ago

Yeah, the idea of fresh age is to require users for re-login to perform some actions Oh thanks! Will check it and merge

Blank•4mo ago

is sending a email not enough verification?

DukiOP•4mo ago

where in the context do I set the freshAge btw? 🤔 Trying to figure out if that workaround actually works

Blank•4mo ago

also there is no api to force re logiin for oauth users

bekacru•4mo ago

It is. That’s why I’m suggesting not checking fresh age if we’re sending the email anyway Just call sign in :))

Blank•4mo ago

yeah but that means you are relying on user to have verification email setup

bekacru•4mo ago

Will send code snippet when I’m at my computer. Using phone rn No. All what needs to be done is if we’re sending an email, don’t check for fresh age

Blank•4mo ago

so this is the flow

1. authClient.deleteUser({}); // pass nothing, not fresh session, no password setup
2. email sent
3. click on the url to delete account

1. authClient.deleteUser({}); // pass nothing, not fresh session, no password setup
2. email sent
3. click on the url to delete account

correct?

DukiOP•4mo ago

ah found it, there is a context inside the context. I've set up the hook like this now, but I still get the re-authentication error (will let you guys discuss now btw 😂 , before I spam you too much)

hooks: {
        before: createAuthMiddleware(async (ctx) => {
            if (ctx.path === '/delete-user') {
                return {
                    context: {
                        ...ctx,
                        context: {
                            ...ctx.context,
                            sessionConfig: {
                                ...ctx.context.sessionConfig,
                                freshAge: 0
                            }
                        },
                    }
                };
            }
        }),

    }

hooks: {
        before: createAuthMiddleware(async (ctx) => {
            if (ctx.path === '/delete-user') {
                return {
                    context: {
                        ...ctx,
                        context: {
                            ...ctx.context,
                            sessionConfig: {
                                ...ctx.context.sessionConfig,
                                freshAge: 0
                            }
                        },
                    }
                };
            }
        }),

    }

Blank•4mo ago

is this what will work for you @Duki ?

DukiOP•4mo ago

Yea I would be happy with that actually. Imo a verification email sounds good enough to me too, don't need to ask for a password again. I think password isn't required either when a user wants to change their email. We (we = BA) just send a verification email too.

Blank•4mo ago

yeah I will make a PR from what we have discussed, will change details if needed

DukiOP•4mo ago

Awesome, thank you and @bekacru so much! Really love BA so far (despite some quirks here and there 😂 but at least it's being worked on them!).

Blank•4mo ago

https://github.com/better-auth/better-auth/pull/2704

GitHub

feat: new user delete flow by BlankParticle · Pull Request #2704 ...

for context: https://discord.com/channels/1288403910284935179/1373686795765547180 This PR changes the delete user account flow to use the email verification for OAuth users to delete their account ...

Blank•4mo ago

you can try this out locally if you want to check if it works for your usecase

npm i https://pkg.pr.new/better-auth/better-auth@2704

npm i https://pkg.pr.new/better-auth/better-auth@2704

need to update tests lol

bekacru•4mo ago

yes

Blank•4mo ago

hey what do I do If there is verification setup, user has a password setup, but he didnt provide it

// if the user has a password but it was not provided, we can't delete the account
        if (account && account.password && !canDelete) {
            throw new APIError("BAD_REQUEST", {
                message: BASE_ERROR_CODES.USER_ALREADY_HAS_PASSWORD,
            });
        }

// if the user has a password but it was not provided, we can't delete the account
        if (account && account.password && !canDelete) {
            throw new APIError("BAD_REQUEST", {
                message: BASE_ERROR_CODES.USER_ALREADY_HAS_PASSWORD,
            });
        }

i am doing this, but it breaks existsing tests ok updated tests to acccount of oauth users seprately

DukiOP•4mo ago

Works perfect for my use case. Even when a user has both, a credential type of account and an oauth account linked together. This flow will ask the user to provide their password, which is perfect imo!

Blank•4mo ago

:Okay: now we wait for merge

elvince•3mo ago

@Blank Sorry to necro this thread, but how do you manage all those cases on the client side? I mean, depanding on multiple condition (credential account present or not, freah token, Oauth ...) we need to provide a different UI and call deleteuser with different parameters. How should manage this on our side? Is there any utils fct that give like a enum that will help to switch UI? Thanks,

Vince•3mo ago

I think managing this on our side would be completely fine but a function to get what flow we should present to the user would be good. I'd like a clarification for this as well 🙂

DukiOP•2mo ago

@bekacru This PR which was created in context to this thread has been merged to the main branch. Unfortunately I cannot find the PR in any of the release notes. The current doc seems to have the version of the PR, but the doc somehow doesn't seem to represent the current implementation. When checking the main branch, it also doesn't have the content of the PR. At least I cant trigger the case, where I have to provide a password when the freshAge is expired. I have set the freshAge to 5 seconds, waited 5 seconds and the email to delete the account still gets sent. Has there been a hiccup during an update or something?

GitHub

feat: new user delete flow by BlankParticle · Pull Request #2704 ...

User & Accounts | Better Auth

User and account management.

DukiOP•2mo ago

It seems like the way it's implemented now, if there is a sendDeleteAccountVerification defined, always send an email and never check for session freshness or password or anything. And if there is no sendDeleteAccountVerification, then check for session freshness only if there is a password, and if that is all fine or the user doesn't even have a password (i.e. it's an oauth user) delete the account immediately. This absolutely doesn't match the current docs, since there is a section saying:

If you have already added the sendDeleteAccountVerification callback, you can just call the deleteUser method without providing any other information. Note that this would fail if they have a password. In that case, you need to provide the password to delete the account.

The Untraceable•2mo ago

Yes I can second this. In my implementation it also always sent the verification email regardless of if password was set. I have not checked against session freshness. I quite like the current implementation, docs need an update

bekacru•2mo ago

the issue here seems like the docs. It doesn't fail if they user has a password and there is sendDeleteAccountVerification callback. It'll be updated

DukiOP•2mo ago

Yea i like the current impl actually. Makes it simpler and more straight forward to work with.

Gaming

Programming

How to delete a user creates with oauth?

Did you find this page helpful?