Cannot upgrade an anonymous account with magic url

[crystal garden]

Unless I am just not doing it right, its not possible to upgrade an account from anonymous, using magic URL.

This is fine - I have worked around it in my app now - however the docs suggest that this should be possible: https://appwrite.io/docs/products/auth/anonymous (scroll to the bottom section)

I am still sending a magic url, but on the page it takes them to, if they have an old anonymous account, then I perform updates where needed to move data onto their new account for the magic URL. This could be cumbersome though, so being able to upgrade an account from anon using magic url would be nice to have...

Should have been more clear - When creating a magic link request, specifying the users current Id results in an error response, saying that the document already exists. Specifying a different ID creates a new account.

[narrow crest]

Hmm ya...maybe we need to update those docs..

Can you use the update email endpoint?

[crystal garden]

I don't want passwords for users, update email endpoint requires password. (My UI doesn't have anywhere for password entry, and I'm having enough push back from users about not wanting to provide email addresses, let alone passwords... Hence why I am creating an option to allow anonymous logins lol)

Currently I only have magic url option for logging in - and right now I'm working on added anonymous auth as an alternative for those who refuse to provide their email address

[narrow crest]

You can pass anything for the password. It'll be ignored

[crystal garden]

Hm OK I'll have a play tomorrow. Thanks

[crystal garden]

Have been thinking, and whilst this could work in a lot of scenarios, I will be sticking to not using the update email endpoint.

The place where this breaks down for me would be the following:

• User creates an anonymous account
• User goes through my flow to upgrade their account by adding an email
  • I use the update email endpoint
• User has accidentally entered the incorrect email

At this point, there are 2 possibilities. Either, I was generating a totally random and useless password to use for the call to update email endpoint, and in this scenario they are unable to change their email a second time as I would never generate the same random password a second time and their account is stuck, unable to upgrade and unable to change their email address. The other scenario is that I am either storing said generated passwords somewhere (highly insecure, defeats the purpose of finding an auth solution to use) OR I am generating a password in some reliable way based on something like their account ID to enable me to generate the same password again in future - again, insecure as it might be possible to work out other peoples email address.

So for this reason, I won't be using the update account email endpoint, and will be creating a new account for them with magic url, and transitioning any data with them when they do that...

This isn't ideal though, and could get quite cumbersome as the data I store related to a user grows.

My suggestion would be that a client SDK hitting the create magic url endpoint, with cookies for a currently logged in session for an anonymous account, will instead of creating a fresh account for the email address, will add it as an unverified email to their current account. It only will not overwrite their current account when they have a verified email, or a password already stored

@narrow crest