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

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.

Philip R.

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: [email protected]

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”

On Mon, Oct 28, 2013 at 7:33 AM, Jordon B. [email protected]
wrote:

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.”

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.

Jordon,

On 2013-10-28 23:41, Jordon B. wrote:

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.

Philip R.

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs