Adding/customizing auth providers without getting them merged

Will it be possible to create and use new auth providers without necessarily getting them merged into the project? For example: the Google provider I created last week doesn’t seem to work in newer releases since the auth provider type checking is now done in authHeaders.ts. Since I don’t think I can easily override that behavior, I can’t upgrade to a newer version of Redwood until I (or someone else) get Google merged as an accepted provider.

Related: I’d like to customize how the Auth0 provider behaves. Specifically, I’d like to use the loginWithPopup method instead of loginWithRedirect. If I could simply write my own auth provider in my project and plug it in then that would be great!

1 Like

Hi @bennett It seems things have been in flux with the Auth package daily during the past week. You got introduced to this during a very dynamic period of development. Expect changes to slow down after Redwood v0.7.0 is released (tomorrow :crossed_fingers:). Excited you dove in and were able to make this work during such early stages!

Re: Writing your own Auth provider
There’s no reason you have to contribute a provider to make it work in your App. Here’s the “how to” roll your own in the docs, which you can just keep in your project. Adding a new Auth Provider

But the advantage to using a package that’s a part of Redwood is community support for features and maintenance. My guess is there will be a Google Auth provider included in the near term (if you don’t get to it first!).

Re: authHeader and Auth0 behavior
Looping in @peterp who’s the master of all things Redwood Auth. (PP, please do correct/guide my comments above as well if needed.)

1 Like

@thedavid, I’m running into this error message from netlify identity when I add it as an auth provider and try to run locally. I have identity enabled on netlify/git gateway enabled. Auth works on the live site but not locally.

Failed to load settings from

Edit: Found that my issues was including the .netlify/... at the end of the url. Grabbed that url from the identity section in netlify and figured that was what I needed

1 Like

That’s a great idea, we’ll add and document a way to do that.

You have access to the client instance via the useAuth() hook, so you could do something like:

const { client } = useAuth()

Thanks @thedavid. Yeah, I’m comfortable with the fact that I’m riding the bleeding edge of Redwood. I expect there will be many gotchas I find along the way, but it’s a testament to how thoughtfully things have been built so far that I’ve been able to temporarily code around the rough spots in a non-hacky way.

Re: Writing your own Auth provider
Maybe I’m misreading the docs, but it does seem like it’s not currently possible to just plug in a local auth provider. The last bit in the docs talks about adding the type definition to the supported types in authClients.ts, which unless I’m mistaken means I’d then need to get that merged into master. While it would be great to have as many providers supported in the core project as possible, it would be nice to be able to run a custom local provider for one-off cases, or even just to get a provider working while waiting for a pull request to be built/approved/merged in the master branch. It sounds like @peterp agrees this would be a useful addition so I’m excited to see how that eventually looks. (I know y’all have a lot on your plate so I’m just happy this will be on the roadmap for “at some point”).

Re: authHeader and Auth0 behavior
@peterp’s suggestion to use the auth0 client directly to access loginWithPopup works perfectly. Thanks!

1 Like

Great! I assume that auth0 redirects to another location after you’ve logged in?

I’m figuring that part out literally right now. If I do nothing but await login() then no, it just sits there with no indication that anything happened unless I refresh. Redirecting should be fine, but it would also be cool if the context/state for isAuthenticated and currentUser got updated reactively.

Ah, that’s important to keep in mind, thanks for letting me know! I think I could expose something via the hooks so that a user can trigger a “re-authenticate” check.