Oh, that’s great! I am using the GoTrue library with Netlify auth, with custom sign up and login pages. Is there any open source code out there with your supabase changes? I would like to investigate converting my code base over.
And RW supports all that auth - I’ve used it, one just has to implement the login/signup widgets (and we need to upgrade to Supabase 1.0)
Is that widget similar to the netlify widget? does superbase-js client support custom forms and implementation? for signup and login.
BTW the chamges Supabase made was in fact to mirror those in GoTrue:
We've bumped the major version because there are a number of breaking changes. We've detailed these in the release notes, but here are a few to be aware of:
* signup() is now signUp() and email / password is passed as an object
* logout() is now signOut()
* login() is now signIn()
That said, the RW authClient will remain the same. It will just use those new ones under the hood.
That makes sense and I figured it was wrapped, hence why I gotta wait for the v1 update.
Once thing I ran into in the story around how to do additional fields. Such as Full name, company name etc.
Assuming the form has all these fields required at the time of registration.
Based on what I read, there are a couple of ways to do this
Use UserProfile model, and link that to the user.
Use the user_metadata on the Auth implementation.
Which of these methods is recommended? what are the pros and cons of each?
In terms of how to actually set the data, in implementation there seems to be two ways:
Use a identity trigger serverless function - With this method I worry about the user logging in before some required metadata is set. May cause a race-condition related error on the application?
Use a success callback after the signup method, to then update the user metadata. - Similar for this method, the second call for update may fail, but the user gets created. Thus leaving that user with blank metadata which may be required for the application.
If we consider traditional MVC stacks, there is the concepts of transactions (where all the operations need to succeeds or it fails), how do we handle this with these auth providers and redwood?
Hey @dthyresson! I’d generally recommend keepin the auth roles out of app_metadata. Roles/permissions aren’t great in JWT because it’s too hard to revoke access (you have to wait for the JWT to expire or somehow invalidate it). It’s generally better to handle roles in your schema (eg. set up a “members” table with access levels, or something similar). We’re creating a Stripe template now which demonstrates this - will release this month. It’s also much more flexible if it’s in your public schema because your permissions model might evolve (eg you might add multitenancy).
We recommend that you create a public.users table for this. You can see this in our “Slack Clone” Quick Start template in the dashboard. You can reference auth.users in public.users using the UUID so there is a one-to-one mapping. This is much better for security. In general the user_metadata is a nice to have, and a bit of a relic from GoTrue. If we implemented our own auth server we probably wouldn’t have added this - it doesn’t make much sense for a Postgres implementation (although it’s nice for prototyping).
In terms of how to actually set the data, in implementation there seems to be two ways:
Either of those methods if fine. If you want to go down the track of guaranteeing the successful creation then I would either use Postgres Triggers on the auth.users table, or you can create an rpc() function to wrap it all into a transaction. If you need help with this feel free to start a GitHub Discussion on our repo - we could even create a quickstart script for this in our code editor.
and we need to upgrade to Supabase 1.0
Wow that’s cool that you caught this already. We even added Magic Links on our GoTrue fork (which we will push upstream when we can). I’ll see if I can help with this - I’m planning to add a with-redwood example to our repo + docs, and I’m looking forward to diving into the code.
Thanks for reply @kiwicopple. In the past few days, I’ve gone about doing exactly that and maintaining my own user table with a 1:1 mapping against the UUID. Then mapping tables like TeamMembers, Team etc. This works pretty well
With features like Magic Links, and other updates you are doing to your GoTrue fork, will we need to wait for upstream changes to redwood? or can we call the client directly?
That’s great to hear @viperfx. And the nice benefit is that it will be simpler to switch to another auth system in the future if you ever wanted to (though we hope you wouldn’t).
With features like Magic Links, and other updates you are doing to your GoTrue fork, will we need to wait for upstream changes to redwood? or can we call the client directly?
All of these require supabase-js > v.1.0. You could manually upgrade, but there are some breaking changes and it looks like Supabase has some blockers (missing types) which I will resolve in the next 2 days.
