supabase/auth

Expose provider name being used to log in

Open

#174 创建于 2021年7月31日

在 GitHub 查看
 (2 评论) (1 反应) (0 负责人)Go (662 fork)auto 404
enhancementhacktoberfest

仓库指标

Star
 (2,443 star)
PR 合并指标
 (平均合并 11天 3小时) (30 天内合并 20 个 PR)

描述

Feature request

Expose the name of the provider that's being used to authenticate a given user.

  • A project can have 12 different ways to log in (email, magic link, phone, plus 9 third-party OAuth providers.)
  • A user may sign up using one provider, say google, which results in the provider being set to google in the app_metatdata like this:
app_metadata: {
  provider: "google"
 }
  • Then the user may later log in using the Facebook provider, but there's no easy way for the developer to know that the login came from Facebook, because the app_metadata will still always say 'google' as the provider.

Describe the solution you'd like

Adding the currently used provider name to the access token would be fine. Basically anywhere you can expose the name of the provider that was just used to authenticate the user would be fine. The use case here is to log each different provider a user has used to log in, to help troubleshoot authentication issues for a user.

"I tried to log in but it didn't work!" <-- would be much easier to troubleshoot if we could see they registered using email then logged in using twitter, then google, then github.

Describe alternatives you've considered

  • We could log the attempt to log in from the client, since the client sets the provider name when calling supabase.auth.signIn(), but that's not a real login, that's just an attempt that might not be completed successfully.
  • We could add the provider to the redirectTo parameter of the signIn() call:
redirectTo: `${window.location.origin}?provider=${provider}`
  • This would require the developer to parse this information from the search part of the app's querystring, then make a second call back to the database to log this info
  • This would also require that every possible provider is added to the Additional Redirect URLs, which in an app with every possible auth provider, would make it a significant list. If you wanted to have redirect URLs for localhost (dev) and production, you might need 2 dozen or more redirect urls: http://localhost:8100?provider=facebook,http://localhost:8100?provider=google etc.

贡献者指南