Feature: Support for email and password change

[lexum0]

Goal

Allow a user to change the account's email or password

Email

The function in AuthClient to update the email is:
try await supabase.auth.update(user: UserAttributes(email: email), redirectTo: url)

The function to resend the email:
try await supabase.auth.resend(email: email, type: type)

Password

The function to change the password:
try await supabase.auth.update(user: UserAttributes(password: "newPassw0rd?"))

The function to reset the password:
try await supabase.auth.resetPasswordForEmail(email)

Session

To refresh the session:
try await supabase.auth.refreshSession()

Reference

https://supabase.com/docs/reference/swift/auth-updateuser

[marcprux]

This would be very useful, but we probably won't be able to get to it for a while.

If you want to take a try at implementing it yourself, just follow the instructions at https://skip.tools/docs/contributing/#local-libraries and add a test case for it to SkipSupabaseTests.swift. Just getting the Auth.update and Auth.resetPasswordForEmail functions to compile by implementing them at SupabaseAuth.swift would likely be fairly straightforward.

[lexum0]

I tried setting up a test case with auth.signIn(email:password:) to deal with actions that require a session or user but couldn't make it work. It doesn't throw an error when calling it, but it returns a nil session and nil user. I'll try again later

Thanks for the quick response

[marcprux]

Most of the auth tests in the sample are expected to fail – they are currently just inside an if false block in order to verify that the API is the same on Swift as on Kotlin.

You could try calling the auth.signIn() function from your app (which, if you have in the same Xcode workspace as your fork of skip-supabase, will use your local version of the library). That will let you test it out in a "real" environment.

[lexum0]

I'll try that next time.

I know the skip-supabase tests are just for testing the API compiles, not to actually work, but I was expecting the session or user to work at least on iOS only. I don't know what's the issue. After so many attempts I'll work on some other areas and then come back to it.

[marcprux]

I know the skip-supabase tests are just for testing the API compiles, not to actually work, but I was expecting the session or user to work at least on iOS only.

I'm guessing it is related to the demo account we are connecting to. We never configured anything for auth. All the Auth work so far has been contributed by users.

You might try locally changing the Supabase key to point to your account and see if it changes anything.

[lexum0]

I already did. All the tests were done with my account (I assumed you have no users).

I did some research but I haven't found anything online about unit tests with Supabase, so I don't know if there's some special configuration or anything