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

[Philip Rhoades]

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 Rhoades

GPO Box 3411
Sydney NSW 2001
Australia
E-mail: ph...@pricom.com.au

[Jordon Bedwell]

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"

> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-ta...@googlegroups.com.
> To post to this group, send email to rubyonra...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rubyonrails-talk/065b9bd87fb07c98be71910158089f35%40localhost.
> For more options, visit https://groups.google.com/groups/opt_out.

[Jordon Bedwell]

On Mon, Oct 28, 2013 at 7:33 AM, Jordon Bedwell <envy...@gmail.com> 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."

[Jordon Bedwell]

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.

On Mon, Oct 28, 2013 at 7:33 AM, Jordon Bedwell <envy...@gmail.com> wrote:

[Philip Rhoades]

Jordon,

On 2013-10-28 23:41, Jordon Bedwell wrote:
> 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.
--
Philip Rhoades

GPO Box 3411
Sydney NSW 2001
Australia

E-mail: ph...@pricom.com.au.