2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【実録】デバッガーへの道 Rails/Devise/OmniAuth/Docker編

Posted at

はじめに

こんにちは。Railsの学習課題で「GitHubログイン機能」を実装しようとしたところ、底なし沼のようなデバッグにハマりました。エラーは次々と姿を変え、解決したと思えば振り出しに戻る。何度も心が折れかけました。

しかし、その戦いの末に得られた知識は、どんな教科書よりも実践的で、私を本当の意味で「デバッガー」へと成長させてくれました。これは、その長く困難な戦いの全記録です。


第1章:始まりのエラー uninitialized constant

最初にOmniauthCallbacksControllerを実装した直後、uninitialized constant User::OmniauthCallbacksControllerというエラーに遭遇。

  • 原因: routes.rbdevise_forで指定したコントローラーのパスが'user/...'(単数形)になっていた。正しくは'users/...'(複数形)であり、Railsが規約通りにコントローラーを見つけられずにいた。

  • 学び: Railsの規約(CoC)の重要性を再認識。rails routesの結果をよく見れば、コントローラーのパスがuser/...になっていることに気づけたはずだった。


第2章:謎のエラー Authentication passthru

コントローラーが見つかったのも束の間、今度はNot found. Authentication passthru.という不可解なエラーに変わった。ここからが本当の戦いの始まりだった。

試行1:設定ファイルの確認

devise.rbconfig.omniauth設定や、.envの環境変数を確認。問題なし。

試行2:GitHub OAuth Appの再作成

古いキーが原因かと疑い、コールバックURLを再確認してキーを再発行。しかし状況は変わらず。

試行3:ブラウザの確認

Chromeの拡張機能やキャッシュを疑い、Safariで試すも、エラーは再現。問題はアプリケーション側にあると確定した。

  • 学び: passthruエラーは、OmniAuthの認証準備段階で何か問題が起きていることを示す漠然としたサイン。設定ファイル、外部サービスとの連携、環境変数など、あらゆる可能性を一つずつ潰していく地道な作業が必要。

第3章:ラスボス Authenticity error

button_toへの変更などを経て、ついに具体的なエラーメッセージGitHubアカウントによる認証に失敗しました。理由:Authenticity errorにたどり着く。これは**CSRF(クロスサイト・リクエスト・フォージェリ)**エラーだった。

試行1:skip_before_action

OmniauthCallbacksControllerでCSRF保護をスキップ。しかし、効果なし。

試行2:omniauth.rbの作成

設定をdevise.rbから分離。これも効果なし。

試行3:Gemバージョンの固定(これが地獄の始まり)

omniauth Gemのバージョンを1.9.1に固定。すると、今度はHerokuへのデプロイでGemNotFoundassets:precompileの失敗など、全く別のエラーが続出。yarn.lockの欠落が原因だと判明し修正するも、元のエラーは解決しないまま。

  • 学び: 安易なバージョン固定は、依存関係の地獄を招く。問題はバージョンではなく、もっと根本にあるはずだと気づかされた。

第4章:終結 - ApplicationControllerへの帰還

全ての試みが尽きた後、最後の手段としてApplicationControllerに以下の設定を追加した。

class ApplicationController < ActionController::Base
  protect_from_forgery unless: -> { request.format.json? }
end

これで、ついに認証が成功した。 振り返れば、omniauth-rails_csrf_protectionというGemが導入する厳格なセキュリティと、button_to+Turboが引き起こすリクエスト形式の複雑さが絡み合い、コントローラーレベルのskip_before_actionでは回避しきれない、ミドルウェア層でのCSRFチェックが発生していたのだと考察している。上記のprotect_from_forgeryの修正は、より広範なリクエストに影響を与え、この問題を解決してくれた。

まとめ

このデバッグで得た最大の教訓は、 エラーメッセージを鵜呑みにせず、一つずつ仮説を立てて、体系的に問題を切り分ける ことの重要性だ。

  • ローカル環境の問題か? → Herokuで試す

  • ブラウザの問題か? → 別のブラウザで試す

  • 設定ファイルの問題か? → rails consoleで直接確認する

  • Gemのインストールの問題か? → bundle showで確認する

  • Docker環境の問題か? → down -vで完全リセットする

一見、遠回りに見えるこれらの手順こそが、解決への唯一の道だった。この経験は、今後のどんな困難なバグに対しても、冷静に対処できる自信を与えてくれた。

もしあなたが同じような底なし沼にハマっているなら、諦めないでください。その沼の底には、必ず大きな学びが眠っています。

2
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?