Devitsは、更新されたRails 3.1アプリの401を少しカスタムルートで返す

Question

私たちのアプリをRails 2.3.xからRails 3.1.3にアップグレードした後に、私たちの管理パネルにログインしたように見えない。私はDeviseの最新バージョンを使用していますが、この記事の時点ではv1.5.3です。

POSTからsession#createルートは、401応答を返します（すべてのパラメータは正常に入力されているように見えます）。 WardenがDeviseの戦略（:database_authenticatable）の1つを使用してユーザーを認証しようとしたときに発生します。ここに私のユーザーモデルがあります。

class User < ActiveRecord::Base 
    devise :database_authenticatable, :validatable 
    attr_accessible :email, :password, :password_confirmation 
end 

私は私の:admin名前空間（ログインは管理者のみのためのものである、と彼らは自分のサイトのレイアウトを持っている、これオーバーライド）でオーバーライドDevise::SessionsControllerを持っています。特別なことは何もレイアウト以外の、本当に、コントローラにありません：

class Admin::SessionsController < ::Devise::SessionsController 
    layout "admin" 
end 

私は少しカスタマイズしたルートを持っている、とここで私はそのために持っているコードです。

devise_for :users, :controllers => { :sessions => 'admin/sessions' } 

私は私のレイアウトのヘッダにcsrf_meta_tagビットを持っている、と私ApplicationControllerはそれでprotect_from_forgeryラインを持っています。フォームのエラーは、ページを再レンダリングするときに空になります。

私はコードを踏んで（lib/warden/proxy.rbまで）、私が使用している:database_authenticatableの戦略が有効であるとは思われません（その部分にはWarden's source code）。ユーザーは有効なユーザーです... Rails rails console IRBセッションを経由して、有効なパスワードとすべてを使ってゼロから作成しました。私はそれが正当なものであると認識すべきだと思っていますか？それとも、私は正しい木を鳴らしていますか？

Answer 1

うわー、私はまあまあです。 Deviseのauthenticatable戦略に進んだ後、私のdevise.rb設定ファイル（別のプロジェクトからコピーして調整したもの）に:usernameがauthentication_keyとしてリストされていて、それはそうであったはずではないことがわかりました。それを:emailに変更しました。

関連記事では、DeviseがWardenとどのように連携しているかについて、いくらか暗い理解ができました。