t.string :name, :null => false - is being ignored! (Devise)

rubyonrails-talk
1

People,

I have included the devise gem in an app and it is going OK but I needed a name field as well as the email so I added it to the migration file:

class DeviseCreateUsers < ActiveRecord::Migration    def change      create_table(:users) do |t|        ## Database authenticatable        t.string :name, :null => false, :default => ""        t.string :email, :null => false, :default => ""        .

and recreated the DB, the schema.rb:

create_table "users", force: true do |t| t.string "name", default: "", null: false t.string "email", default: "", null: false .

confirms that the change looks sensible, however when I add a new user, I can do it without the user name! - how is that possible?

Any help appreciated!

Thanks,

Phil.

2

In Ruby a blank string is a null note a null bit so you need if you set :default => "" it will allow blank strings, which means your model needs to validate with :allow_blank => false or you need to set the ALLOW NULL 0 on the field by doing `:null => false` without the ":default => true".

The preferable solution from both a security and a proper application standpoint is to do tell both the model and the db that it doesn't want null or blank strings because a db error should protect against manual entries and the model would be quicker when testing for blank strings, you can do that with "validates :field, :allow_blank => false, allow_nil => false"

3

In Ruby a blank string is a null note a null bit so you need if you

That should say "In Ruby a blank is not a null bit."

4

Apparently my laptops touchpad was on so let me reword it:

In Ruby a blank string is not a null bit so if you set :default => "" it will allow blank strings, which is what you consider a null string even though there is no such thing. Which means if you want :default => "" you need to have your model validate with :allow_blank => false, or you need to ALLOW_NULL 0 and remove the :default => "".

The preferable solution from both a security and proper application standpoint is to tell both the model and the db that it doesn't want null or blank strings because it's faster to have the model do blank? than it is to hit the db and have it return and error and complete a cycle (short-circuiting is a good thing.) The db protection is simply to protect yourself against manual entries and edge cases in the application.

5

Jordon,

Apparently my laptops touchpad was on so let me reword it:

In Ruby a blank string is not a null bit so if you set :default => "" it will allow blank strings, which is what you consider a null string even though there is no such thing. Which means if you want :default => "" you need to have your model validate with :allow_blank => false, or you need to ALLOW_NULL 0 and remove the :default => "".

The preferable solution from both a security and proper application standpoint is to tell both the model and the db that it doesn't want null or blank strings because it's faster to have the model do blank? than it is to hit the db and have it return and error and complete a cycle (short-circuiting is a good thing.) The db protection is simply to protect yourself against manual entries and edge cases in the application.

Right - I should have realised that what I was looking at was the DB stuff - I have found:

.gem/ruby/bundler/gems/devise-4e2cdc2d5b81/lib/devise/models/validatable.rb

and it seems to have some stuff in it that is relevant - I will check that out.

Thanks,

Phil.