7

50 を超える列を持つユーザー テーブルを備えた、完全に機能する認証システムがあります。シンプルですが、ソルトでハッシュ暗号化を行い、ユーザー名の代わりに電子メールを使用し、管理者を持つ 2 種類のユーザーも持っています。

電子メールの検証、パスワードの忘れ、トークンの記憶などの追加部分を強化するために、Devise 認証をアプリケーションに組み込みたいと考えています。既存のユーザー構造に工夫します。私のユーザーモデルの必須フィールドは次のとおりです。

  t.string    :first_name, :null => false
  t.string    :last_name, :null => false
  t.string    :email, :null => false
  t.string    :hashed_password
  t.string    :salt
  t.boolean   :is_userA, :default => false
  t.boolean   :is_userB, :default => false
  t.boolean   :is_admin, :default => false
  t.boolean :active, :default => true
  t.timestamps

参考までに、移行の Devise フィールドは次のとおりです。

  t.database_authenticatable :null => false
  t.confirmable
  t.recoverable
  t.rememberable
  t.trackable

  add_index "users", ["confirmation_token"], :name => "index_users_on_confirmation_token", :unique => true
  add_index "users", ["email"], :name => "index_users_on_email", :unique => true
  add_index "users", ["reset_password_token"], :name => "index_users_on_reset_password_token", :unique => true

それは最終的にスキーマ内のこれらの実際のフィールドに変わります。

t.string   "email",                               :default => "", :null => false
t.string   "encrypted_password",   :limit => 128, :default => "", :null => false
t.string   "password_salt",                       :default => "", :null => false
t.string   "confirmation_token"
t.datetime "confirmed_at"
t.datetime "confirmation_sent_at"
t.string   "reset_password_token"
t.string   "remember_token"
t.datetime "remember_created_at"
t.integer  "sign_in_count",                       :default => 0
t.datetime "current_sign_in_at"
t.datetime "last_sign_in_at"
t.string   "current_sign_in_ip"
t.string   "last_sign_in_ip"
t.datetime "created_at"
t.datetime "updated_at"

皆さんは何をお勧めしますか？移行から email、hashed_pa​​ssword、salt を削除し、5 つの Devise 移行フィールドに入力するだけで問題ありませんか?それとも何か他のことをする必要がありますか?

編集：

私はこれを自分で試み始めましたが、すでにいくつかの問題に遭遇しています。上に示したデバイス移行フィールドを既存のユーザー モデルに追加しました。シード ファイルを実行すると、次の Postgresql エラーが表示されます。

ERROR: duplicate key value violates unique constraint "index_users_on_email"

私のシードファイル:

initial_usersA = User.create!(
[
{
    :first_name => "John", 
    :last_name => "Doe",
    :email => "johndoe@gmail.com",
    :is_userA => true,
    :is_userB => false,
            :is_admin => true,
    :password => "password",
    :password_confirmation => "password"
},
{
    :first_name => "Jane", 
    :last_name => "Smith",
    :email => "janesmith@gmail.com",
    :is_userA => true,
    :is_userB => false,
            :is_admin => true,
    :password => "password",
    :password_confirmation => "password"
}

ユーザーモデル:

devise :registerable, :authenticatable, :recoverable,
     :rememberable, :trackable, :validatable
attr_accessor :password_confirmation, :email, :password

スタック トレースは、電子メールが何らかの理由で残りの変数で明らかにフィードされていないことを示しています...シード ファイル内の他のすべてが実際のクエリに表示されますが、電子メールは何らかの理由で '' です。それは明示的に定義されています.auth

4

3 に答える 3

2

同様のことを行ったときに直面した主な考慮事項は、次の 2 つです。

t.database_authenticatableデータベースの移行 -ヘルパーを使用するのではなく、個別のadd_column and rename_columnステートメントを作成したため、列やインデックスの重複エラーに遭遇することはありませんでした。 gem の動作を変更します。

2番目の、そしてより大きな考慮事項は、私たちが使用したハッシュアルゴリズムがDeviseが提供したものと同じではなかったため、独自の暗号化クラスを のサブクラスとして記述Devise::Encryptors::Baseし、独自のロジックを使用してダイジェスト関数を実装する必要があったことです。最後に、適切な config/initializer ファイルで指定して、この暗号化を使用するように Devise を構成しました。config.encryptor = :our_own_algorithm

これがあなたが始めるのに十分であることを願っています。

于 2011-04-16T07:33:09.637 に答える
0

電子メールのスキーマで：default=>""を削除します。deviseはデフォルトで電子メールに一意の制約を課すため、空の文字列のデフォルトは必要ありません

于 2010-07-28T17:40:57.567 に答える
0

昨年、アプリを authLogic (と思います) から Devise に切り替えました。私の教訓は次のとおりです。他の認証方法で行ったように、異なる db フィールド名を追加できる lib マッピング ファイルが見つかりませんでした。

それは実際にそれについてでした。私は自分がする必要があることがどれほど少ないかに本当に驚きました. 私のハッシュは実際にはまだ機能していたか、指示に従ってルーチンに変更したと思います。

私はDeviseで「admin」フラグルートを使用しているので、現在使用されているものからSQL変換を行うことができます。

また、デフォルトの "" ビットを取り除きます。本番アプリがあります（使用する認証がわからない、base64 のものだと思います）。t.string "EMAIL", :limit => 64, : null => false t.string "PASSWORD", :limit => 64, :null => false

于 2011-04-22T17:10:13.013 に答える