Die Devise-Authentifizierung in eine bereits vorhandene Benutzerstruktur integrieren?

Question

Ich habe ein voll funktionsfähiges Authentifizierungssystem mit einer Benutzertabelle, die über fünfzig Spalten hat. Es ist einfach, aber es tut Hash-Verschlüsselung mit Salz, verwendet E-Mail anstelle von Benutzernamen und hat zwei verschiedene Arten von Benutzern mit einem Administrator.

Ich möchte Devise-Authentifizierung in meine Anwendung integrieren, um die zusätzlichen Teile wie E-Mail-Validierung, vergessene Passwörter, Erinnerungs-Tokens usw. zu verstärken. Ich wollte nur sehen, ob jemand Rat oder Probleme hat. Bei der Integration von Devise in eine bereits vorhandene Benutzerstruktur Die wesentlichen Felder in meinem Benutzermodell sind:

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 

Zum Vergleich willen, ist hier die Devise Felder aus der Migration:

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 

, die schließlich in diese tatsächlichen Felder im Schema drehen:

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" 

Was empfehlen Sie? Entferne ich einfach E-Mail, hashed_password und salt von meiner Migration und lege die 5 Devise-Migrationsfelder ein und alles wird OK oder muss ich etwas anderes tun?

EDIT:

Ich habe angefangen, dies selbst zu versuchen und haben bereits in einige Probleme laufen. Ich fügte hinzu, die devise Migration Felder ich oben auf meinem vorhandenen Benutzermodell zeigte, und wenn ich jetzt meine Samen Datei ausführen, es gibt mir diese Postgresql Fehler:

ERROR: duplicate key value violates unique constraint "index_users_on_email" 

Meine Samen-Datei:

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" 
} 

User-Modell :

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

der Stack-Trace zeigt, dass die E-Mail scheinbar nicht mit dem Rest der Variablen aus irgendeinem Grund eingespeist wird ... wenn alles andere in der seed-Datei zeigt in der actua up Ich Frage, die E-Mail ist '' aus irgendeinem Grund, obwohl es explizit definiert ist.auth

Answer 1

Ich würde loswerden von: default => "" in Ihrem Schema für E-Mails. legt eine eindeutige Einschränkung auf E-Mail standardmäßig entwickeln, so dass Sie wollen keine Standardwerte von leeren String

Answer 2

Die beiden wichtigsten Überlegungen Ich erinnere mich, wir konfrontiert, wenn wir eine ähnliche Sache tat waren:

Datenbank Migrationen - anstatt Die t.database_authenticatable Helfer, wir schrieben individuelle add_column and rename_column Anweisungen, so dass wir keine doppelte Spalte oder Indexfehler, die Sie gesehen haben, und damit, so dass wir unsere Hash-Passwörter innerhalb von Devise wiederverwenden konnten, ohne zu ändern, wie die Juwel funktioniert. Die zweite und größere Überlegung war, dass der Hashing-Algorithmus, den wir verwendeten, nicht derselbe war wie der, den Devise lieferte, und so mussten wir unsere eigene Verschlüsselungsklasse als Unterklasse von Devise::Encryptors::Base schreiben und die Digest-Funktion implementieren unsere eigene Logik. Schließlich haben wir Devise so konfiguriert, dass er diesen Verschlüssler verwendet, indem er ihn in der entsprechenden Konfigurationsdatei mit config.encryptor = :our_own_algorithm

angibt. Ich hoffe, das gibt Ihnen genug, um Sie zu beginnen.

Answer 3

wechselte ich über eine App von authLogic (glaube ich) im vergangenen Jahr ersinnen und meine Lektionen waren: - Benutzertabelle bleiben kann - Spalten umbenennen Standards ersinnen, ich bin sicher, dass dies nicht notwendig sein sollte, aber Im Gegensatz zu anderen Authentifizierungsmethoden habe ich keine lib-Zuordnungsdatei gefunden, in der ich andere db-Feldnamen hinzufügen könnte, wie ich es bei anderen Authentifizierungsmethoden getan habe.

Das war eigentlich so. Ich war wirklich überrascht darüber, wie wenig ich tun musste. Ich denke, meine Hashes funktionierten tatsächlich noch, oder ich wechselte zur Routine, wie in der Anleitung beschrieben.

Ich benutze die 'admin' Flag Route mit Devise, so dass eine SQL-Konvertierung von dem, was derzeit verwendet wird, tun kann.

Ich würde auch die Standard "" Bit loswerden, habe ich eine Produktion app (nicht sicher, welche Authentifizierung es verwendet, einige Base64, was ich denke) und das sieht so aus: t.string "EMAIL",: begrenzen => 64,: null => false t.string "PASSWORT",: limit => 64,: null => falsch