Включение Devise Authentication в уже существующую структуру пользователя?

Question

У меня есть полнофункциональная система аутентификации с пользовательской таблицей, которая имеет более пятидесяти столбцов. Это просто, но он выполняет хеширование с помощью соли, использует электронную почту вместо имен пользователей, а также имеет два отдельных типа пользователей с администратором.

Я хочу включить аутентификацию Devise в свое приложение, чтобы усилить такие дополнительные функции, как проверка электронной почты, забытие паролей, запоминание токенов и т. Д. Я просто хотел узнать, есть ли у кого-нибудь какие-либо советы или проблемы, с которыми он столкнулся. встречается при включении 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"

Что вы, ребята, рекомендуете? Должен ли я просто удалить электронную почту, hashed_password и соль из моей миграции и поместить в поля 5 Devise миграции, и все будет в порядке, или мне нужно сделать что-то еще?

EDIT:

Я сам попробовал это сделать и уже столкнулся с некоторыми проблемами. Я добавил поля миграции devise, которые я показал выше, в свою существующую модель пользователя, и теперь, когда я запускаю свой файл seed, он выдаёт мне эту ошибку 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

Трассировка стека показывает, что электронная почта, очевидно, не передается с остальными переменными по какой-то причине ... хотя все остальное в начальном файле отображается в реальном запросе, электронная почта для некоторых '' причина, даже если она явно определена.

Answer 1

Я помню, что мы столкнулись с двумя основными соображениями, когда делали похожую вещь:

Миграция базы данных - вместо того, чтобы использовать t.database_authenticatable помощники, мы написали отдельные операторы add_column and rename_column, чтобы мы не сталкивались с повторяющимися ошибками столбцов или индексов, которые вы видите, и чтобы мы могли использовать их повторно наши соленые и хешированные пароли в Devise без необходимости изменения работы самоцвета.

Второе и более важное соображение заключалось в том, что алгоритм хеширования, который мы использовали, отличался от того, который предоставил Devise, и поэтому нам пришлось написать наш собственный класс шифра как подкласс Devise::Encryptors::Base и реализовать функцию дайджеста используя нашу собственную логику. Наконец, мы настроили Devise для использования этого шифратора, указав его в соответствующем файле конфигурации / инициализатора с помощью config.encryptor = :our_own_algorithm

Надеюсь, этого достаточно, чтобы начать.

Answer 2

Я переключил приложение с authLogic (я думаю) на Devise в прошлом году, и мои уроки были: - Пользовательский стол может остаться - Переименуйте столбцы в стандарты Devise, я уверен, что в этом нет необходимости, но в отличие от других методов аутентификации, я не нашел файл отображения lib, в который я мог бы добавить разные имена полей БД, как я делал с другими методами аутентификации .

Это было на самом деле об этом. Я был очень удивлен тем, как мало мне нужно было сделать. Я думаю, что мои хеши на самом деле все еще работали, или я переключился на рутину, как указано в инструкции.

Я использую флаг 'admin' вместе с Devise, так что выполнение преобразования sql из того, что используется в настоящее время, может сделать это.

Я бы также избавился от бита по умолчанию "", у меня есть производственное приложение (я не уверен, какую аутентификацию оно использует, какая-то вещь base64, я думаю), и это выглядит так: t.string "EMAIL",: limit => 64,: null => false t.string "ПАРОЛЬ",: limit => 64,: null => false

Answer 3

Я бы избавился от: default => "" в вашей схеме для электронной почты. По умолчанию devise накладывает уникальное ограничение на электронную почту, так что вам не нужны значения по умолчанию для пустой строки