【Supabase】ローカル開発でOAuthの処理に苦しめられたので解決策のメモ書きを残します
Supabaseは凄まじいスピードでアップデートされているため、わずか数ヶ月前の情報すら役に立たないことがあります。過去にZennにローカル環境でのOAuthの処理について投稿しましたが、もはや使い物にならない情報となってしまったため、改めて詰まりポイントを抑えてメモ書きしておきます。
※この記事はタイトルにもある通り、「ローカル環境での開発」に特化 しています。
※公式ドキュメントに書かれていること（またはすぐに気づくこと）には触れません。
本記事は公式ドキュメントの補足的な内容となっています。（主にローカル特有のハマった箇所のポイントを抽出している）
▼ Supabase公式 X（Twitter）認証 ▼
何にハマったのか？
http://localhost:3000/ で閲覧していたはずが、 http://127.0.0.1:3000/ に飛ばされてしまう問題に遭遇しました。ローカル開発特有の問題かと思うのですが、公式ドキュメントにも特に言及されておらず、問題解決に時間を要しました。
また、この影響で認証が適切に行われず、ブラウザ側で await supabase.auth.getSession() の実行するまでブラウザ側には認証済みであることが認識されない状況でした。しかし、この実装方法はベストな方法ではありません。根本的な解決方法がちゃんとありました。
本記事では、これらの問題を全て解決し、スムーズな認証ができるようになりました。
この記事で取り扱う認証プロバイダー
認証プロバイダーとは、NotionやSpotify、Facebookなどの各種サービスからユーザー情報を貰う供給元のことです。
本記事では
- X（Twitter）
この2つだけを取り扱います。
X側の認証設定
開発者プラットフォームの「User authentication settings」画面にて、App infoの Callback URL欄に http://localhost:54321/auth/v1/callback と入れておきましょう。
Supabase CLIで起動すると、 http://127.0.0.1:54321 がAPIのURLとなりますが、これは罠です。（開発アプリ側で認証をするとlocalhostから127.0.0.1に飛ばされてしまう。）
Google側の認証設定
「APIとサービス」欄の「認証情報」ページにて、「承認済みのリダイレクト URI」の欄に http://localhost:54321/auth/v1/callback と入れておきましょう。
【本記事のメイン】ローカル環境のSupabaseの設定「config.toml」を編集する
config.toml を編集する必要があります。
[auth] 箇所の
site_url = "http://127.0.0.1:3000"additional_redirect_urls = ["https://127.0.0.1:3000"]
これら2箇所をそれぞれ、
site_url = "http://localhost:3000"additional_redirect_urls = ["http://localhost:3000"]
に変更します。
これによって認証のリダイレクト先が localhost:3000 へと変更されます。認証後、127.0.0.1には飛ばされず、そのまま http://localhost:3000 を維持してくれるという訳ですね。
※ちなみに、 [studio] の api_url = "http://127.0.0.1" を localhost にしてしまうと、Supabase Studio（GUI）での Authentication でのユーザー追加ができなくなるので触らないようにしましょう。罠が多すぎる！
config.toml に認証プロバイダの設定を追加する
ファイルの最下部で結構ですので、
[auth.external.twitter]
enabled = true
client_id = "【ここにキー】"
secret = "【ここにシークレットキー】"
redirect_uri = "http://localhost:54321/auth/v1/callback"
[auth.external.google]
enabled = true
client_id = "【ここにキー】"
secret = "【ここにシークレットキー】"
redirect_uri = "http://localhost:54321/auth/v1/callback"
としておきます。
ローカル環境のSupabaseを再起動してconfig.tomlを反映しておきましょう。
Next.js側の signInWithOAuth() 関数の redirectToを指定する
認証時には signInWithOAuth() 関数を使う旨が公式ドキュメントにも書かれています。書き方は公式ドキュメント通りです。
const { data, error } = await supabase.auth.signInWithOAuth({
provider: "google",
options: {
redirectTo: `http://localhost:3000/auth/callback`,
},
});
const { data, error } = await supabase.auth.signInWithOAuth({
provider: "twitter",
options: {
redirectTo: `http://localhost:3000/auth/callback`,
},
});
redirectToの値を絶対に忘れてはなりません。
これを書き忘れてしまうと認証が完了できません。気をつけましょう。
おしまい
英語の記事でもまとまった情報が無かったので苦労しましたが、これで快適にSupabaseでの認証ができるかと思います。誰かの役に立てば幸いです。
【おまけ】Android実機からローカルで確認するには？
chrome://inspect を使えばUSBデバッグでAndroid実機の確認ができます。（それ以外にも同じWi-Fi接続であれば、ipconfigで確認したIPアドレス経由でもアクセスできます。）
その際の Port forwarding settings では、 54321 も追加するのをお忘れなく。SupabaseのAPIのポートも向けてあげないとOAuth処理が完了できません。
【おまけ2】ローカルのSupabaseを物理的に別マシンに分ける
ローカル環境の Supabase は結構重いです。Next.jsと同じ環境に置いていると Supabase の存在が少し邪魔に感じるときがあります。そこで、Supabaseの処理だけを物理的に別のマシンに分けると、快適な開発が可能となります。
同じWi-Fiに繋がっているという条件下ではありますが、非常に有効的な手段ですので参考にしてみてください。ガッツリ分けて開発に取り組んでみましたが問題は特に起きませんでした。（唯一、Edge Functionsの反映のために再起動する必要があり、そこだけは手間でした。）
Discussion
同じ現象にぶつかりました。
GitHubのProviderでもこの対処で解決しました。
お役に立てたようで嬉しいです！
助かりました、ありがとうございます