Upgrading to 1.2

[Roger Ertesvåg]

On upgrading to 1.2.1 I get the following message:

[DEVISE] From version 1.2, there is no need to set your encryptor to
bcrypt since encryptors are only enabled if you include :encryptable
in your models. To update your app, please:
1) Remove config.encryptor from your initializer;
2) Add t.encryptable to your old migrations;
3) [Optional] Remove password_salt in a new recent migration. Bcrypt
does not require it anymore.

I find step 2 a bit confusing since when I read the documentation I
get the understanding that t.encryptable is only needed when you use
other encryptors than bcrypt. So can I skip step 2 if I just want to
contuine to use bcrypt?

Also, is there a writeup somewhere on why password_salt is no longer
needed?


Regards
Roger Ertesvåg

[José Valim]

You need to add t.encryptable to your old migrations because your old
migrations did generate the password_salt field. If you don't need the
password_salt, you should remove in a later migration (step 3).

Bcrypt bundles the password and salt in the same string. If you look
at your DB, you can see that the beginning of encrypted password is
the same value as the salt column. That said, Devise 1.2 now allows
you to get rid of this extra info.

[Roger Ertesvåg]

Thanks for the swift response.

So if I understand you correctly step 2 is for a situation where you
have an old migration that you want reuse. But for an app that is
already in production where the old migration will not be run again
you can skip this and optionally run step 3?


Regards
Roger

[dukha]

HI José
I'm afraid that I'm confused about step2 also.

"add t.encryptable to your old migrations"

Does this mean add a new migration which adds a column
encryptable :boolean ? (It won't help much to add it to an already
executed migration)
Does it mean add :encryptable to the model ? As in devise :encryptable

If we don't care about the development db, can we just drop and
recreate the database with t.encryptable in a migration?

No one says why this is necessary as the old devise clearly encrypted
anyway.

Regards

dukha

[José Valim]

Roger,

You need to step 2 exactly to make your development database the same
as production.
Otherwise, if you do just step 3, it will work fine in production and
explode in development, because development will never have that
column in the first place.

[José Valim]

No, you just need to add t.encryptable to your migration, so it will
generate the password_salt column again. Previously, password_salt
column was generated by database_authenticatable, now not anymore. So
you need to add t.encryptable to it so it works the same as
previously.

[Todd A. Jacobs]

> 2) Add t.encryptable to your old migrations;

If we don't have our old migrations handy, what should go into a new
migration? I can't find any documentation about what type of
field :encryptable should be. I tried this, but it obviously fails
without a column type:

class AddEncryptableToUsers < ActiveRecord::Migration
def self.up
add_column :users, :encryptable
end

def self.down
remove_column :users, :encryptable
end
end

If one already has a database in production using devise 1.1.7, and
can't rebuild the database from scratch, what should the migration
look like?

[klebervirgilio]

+1 My doubt is.... How Can I add t.encryptable in my olds migration??

[José Valim]

If you can't rebuild it anyway, there is no need to add encryptable.
Btw, you could use change_table:

change_table :users do |t|
t.encryptable
end

[José Valim]

Open your old migrations where your first defined your devise model
and add "t.encryptable" to it.

[Roger Ertesvåg]

I believe step 2 is only necessary if you want to rerun the
migrations, but the recommended way is to recreate the database from
schema.rb

http://guides.rubyonrails.org/migrations.html#schema-dumping-and-you

So if you create the database with

rake db:setup

Or recreate it with

rake db:reset

These should recreate the database from schema.rb and step 2 should
not be necessary.


Regards
Roger Ertesvag