I'm trying to use has_secure_password on my user model, but have found that while it works in the application it breaks all my tests. I have a simple user model:
class User < ActiveRecord::Base
has_secure_password
attr_accessible :email
validates :email, :presence => true,
:format => { :with => /\A[\w+\-.]+#[a-z\d\-.]+\.[a-z]+\z/i },
:uniqueness => { :case_sensitive => false }
validates :password, :presence => true
end
My first test (rspec) simply confirms that I can create a new user with valid attributes:
describe User do
before(:each) do
#attr = { :forename => "Captain",
:surname => "Hook",
:email => "email#test.com",
:password => "password",
:password_confirmation => "password" }
end
it "should create a new instance given valid attributes" do
User.create!(#attr)
end
end
This doesn't work, however when I do
user = User.new(#attr);
user.password = "password";
user.save
it works fine. I believe this is because has_secure_password adds a new method, password, which deals with the generation of the password_digest, so calling it directly like this generates the fields that I need. Is there any way I can use User.create but still call this method?
Turns out the problem was really simple. Since I hadn't added :password to attr_accessible it wasn't populating the field when I called User.create or User.new. The only modification I needed to make to the code was
attr_accessible :email, :password
Related
I have the following simplified model:
class User
attr_accessible :password
validates :password, :presence => true
validates_confirmation_of :password, :length => { :minimum => 4 }
end
That's pretty straight forward. I'm testing it with RSpec/FactoryGirl, and have the following tests:
it "cannot create with password < 4 characters" do
expect{ model = FactoryGirl.create(:user, :password => "12", :password_confirmation => "12") }.to raise_error
end
it "cannot update to password < 4 characters" do
model = FactoryGirl.create(:user)
model.should be_valid
model.update_attributes({:password => "12", :password_confirmation => "12"})
model.reload
model.password.should_not eq("12")
end
However, the second test fails. For some reason, "12" seems to be able to be saved into the database as a valid password. Why? The API states that update_attributes should not bypass any of the validations!
I don't think it is skipping validations.
I suspect this:
model.update_attributes({:password => "12", :password_confirmation => "12"})
is returning false. Password is probably not a column in your database, rather you probably have crypted_password and password_salt so reloading it does not read the password from the database (this would be bad)
Also, you probably want :
attr_accessible :password, :password_confirmation
I'm trying to set up my application to use Sorcery. When I add authenticates_with_sorcery! to my user model, my specs start to run really slow (about one per second). Is there some kind of configuration or set up that could cause this with Sorcery?
Here's my user model:
# This model represents a user of the application, disregarding that person's use of the system. For
# instance, a user could be a job hunter, an employer, an administrator, or some other stakeholder.
class User < ActiveRecord::Base
authenticates_with_sorcery!
attr_accessible :email, :password, :password_confirmation
# validations
validates :email,
:presence => true,
:uniqueness => true,
:format => /[^#]+#[^#]+\.[^#]+/
validates :password, :presence => true, :confirmation => true
validates :password_confirmation, :presence => true
# before filters
before_save :sanitize_email
private
# Strips and removes HTML tags from the email parameter.
def sanitize_email
self.email = email.strip
# remove anything that looks like an email
self.email = email.gsub(/<[^<>]+>/, "")
end
end
and my user factory:
require 'factory_girl'
require 'ffaker'
FactoryGirl.define do
sequence :email do |n|
"email#{n}#example.com"
end
factory :user do |f|
email
password "password"
password_confirmation "password"
end
end
My first guess is slow password encryption. For instance in devise we have config.stretches configuration variable which in the test env could be set to a small number.
check What does the "stretches" of database_authenticatable of devise mean?
I have this code in my user model:
class User < ActiveRecord::Base
attr_accessible :email, :password, :password_confirmation
attr_accessor :password
before_save :encrypt_password
validates :email, :presence => true,
:uniqueness => { :case_sensitive => false },
:format => { :with => /\A[^#]+#[^#]+\z/ },
:length => 7..128
validates :password, :presence => true,
:confirmation => true,
:length => 6..128
private
def encrypt_password
return unless password
self.encrypted_password = BCrypt::Password.create(password)
end
end
Now in my controller when I'm updating some user fields with
#user.update_attributes(params[:user])
the password field is always validated, even when it is not set in the params hash. I figured that this is happening because of the attr_accesor :password which always sets password = "" on update_attributes.
Now I could simply skip the validation of password if it is an empty string:
validates :password, :presence => true,
:confirmation => true,
:length => 6..128,
:if => "password.present?"
But this doesn't work because it allows a user to set an empty password.
Using update_attribute on the field I'd like to change is not a solution because i need validation on that attribute.
If I pass in the exact parameter with
#user.update_attributes(params[:user][:fieldname])
it doesn't solve the problem because it also triggers password validation.
Isn't there a way to prevent attr_accesor :password from always setting password = "" on update?
New answer
This works for me:
validates :password, :presence => true,
:confirmation => true,
:length => { :minimum => 6 },
:if => :password # only validate if password changed!
If I remember correctly it also took me some time to get this right (a lot of trial and error). I never had the time to find out exactly why this works (in contrast to :if => "password.present?").
Old answer - not really useful for your purpose (see comments)
I get around this problem by using a completely different action for password update (user#update_password). Now it is sufficient to only validate the password field
:on => [:create, :update_password]
(and also only make it accessible to those actions).
Here some more details:
in your routes:
resources :users do
member do
GET :edit_password # for the user#edit_password action
PUT :update_password # for the user#update_passwor action
end
end
in your UsersController:
def edit_password
# could be same content as #edit action, e.g.
#user = User.find(params[:id])
end
def update_password
# code to update password (and only password) here
end
In your edit_password view, you now have a form for only updating the password, very similar to your form in the edit view, but with :method => :put and :url => edit_password_user_path(#user)
The solution I have started using to get round this problem is this:
Start using ActiveModel's built in has_secure_password method.
At console
rails g migration add_password_digest_to_users password_digest:string
rake db:migrate
In your model:
class User < ActiveRecord::Base
has_secure_password
attr_accessible :login_name, :password, :password_confirmation
# secure_password.rb already checks for presence of :password_digest
# so we can assume that a password is present if that validation passes
# and thus, we don't need to explicitly check for presence of password
validates :password,
:length => { :minimum => 6 }, :if => :password_digest_changed?
# secure_password.rb also checks for confirmation of :password
# but we also have to check for presence of :password_confirmation
validates :password_confirmation,
:presence=>true, :if => :password_digest_changed?
end
And finally,
# In `config/locales/en.yml` make sure that errors on
# the password_digest field refer to "Password" as it's more human friendly
en:
hello: "Hello world"
activerecord:
attributes:
user:
password_digest: "Password"
Oh, one more thing: watch the railscast
I just wrote a test for testing if a new user creation also consists of an admin setting. Here is the test:
describe User do
before(:each) do
#attr = {
:name => "Example User",
:email => "user#example.com",
:admin => "f"
}
end
it "should create a new instance given valid attributes" do
User.create!(#attr)
end
it "should require a name" do
no_name_user = User.new(#attr.merge(:name => ""))
no_name_user.should_not be_valid
end
it "should require an email" do
no_email_user = User.new(#attr.merge(:email => ""))
no_email_user.should_not be_valid
end
it "should require an admin setting" do
no_admin_user = User.new(#attr.merge(:admin => ""))
no_admin_user.should_not be_valid
end
end
Then, in my User model I have:
class User < ActiveRecord::Base
attr_accessible :name, :email, :admin
has_many :ownerships
has_many :projects, :through => :ownerships
email_regex = /\A[\w+\-.]+#[a-z\d\-.]+\.[a-z]+\z/i
validates :name, :presence => true,
:length => { :maximum => 50 }
validates :email, :presence => true,
:format => { :with => email_regex },
:uniqueness => { :case_sensitive => false }
validates :admin, :presence => true
end
I clearly created a new user with an admin setting, so why is it saying it's false? I created the migration for the admin setting as admin:boolean. Did I do something wrong?
Here's the error:
Failures:
1) User should create a new instance given valid attributes
Failure/Error: User.create!(#attr)
ActiveRecord::RecordInvalid:
Validation failed: Admin can't be blank
# ./spec/models/user_spec.rb:14:in `block (2 levels) in <top (required)>'
Oddly enough, when I comment out validates :admin, :presence => true, the test creates the user correctly but fails on "User should require an admin setting"
EDIT: When I change the #attr :admin value to "t" it works! Why doesn't it work when the value is false?
From the rails guides:
Since false.blank? is true, if you want to validate the presence of a
boolean field you should use validates :field_name, :inclusion => {
:in => [true, false] }.
Basically, it looks like ActiveRecord is converting your "f" to false before the validation, and then it runs false.blank? and returns true (meaning that the field is NOT present), causing the validation to fail. So, to fix it in your case, change your validation:
validates :admin, :inclusion => { :in => [true, false] }
Seems a little hacky to me... hopefully the Rails developers will reconsider this in a future release.
I'm a newbie watching a Lynda.com video about rails 3. The teacher creates a method like this to find a user
def name
"#{first_name} #{last_name}"
end
He says this will return first name and last name for this user, but I don't understand how this function accesses first_name last_name, since there is no call to a database or no form parameters.
I know that without looking at the whole application it will be impossible for you to explain this, but you may be able to guess what this function might be dependent on.
this is the whole AdminUser model
require 'digest/sha1'
class AdminUser < ActiveRecord::Base
# To configure a different table name
# set_table_name("admin_users")
has_and_belongs_to_many :pages
has_many :section_edits
has_many :sections, :through => :section_edits
attr_accessor :password
EMAIL_REGEX = /^[A-Z0-9._%+-]+#[A-Z0-9.-]+\.[A-Z]{2,4}$/i
# standard validation methods
# validates_presence_of :first_name
# validates_length_of :first_name, :maximum => 25
# validates_presence_of :last_name
# validates_length_of :last_name, :maximum => 50
# validates_presence_of :username
# validates_length_of :username, :within => 8..25
# validates_uniqueness_of :username
# validates_presence_of :email
# validates_length_of :email, :maximum => 100
# validates_format_of :email, :with => EMAIL_REGEX
# validates_confirmation_of :email
# new "sexy" validations
validates :first_name, :presence => true, :length => { :maximum => 25 }
validates :last_name, :presence => true, :length => { :maximum => 50 }
validates :username, :length => { :within => 8..25 }, :uniqueness => true
validates :email, :presence => true, :length => { :maximum => 100 },
:format => EMAIL_REGEX, :confirmation => true
# only on create, so other attributes of this user can be changed
validates_length_of :password, :within => 8..25, :on => :create
before_save :create_hashed_password
after_save :clear_password
scope :named, lambda {|first,last| where(:first_name => first, :last_name => last)}
scope :sorted, order("admin_users.last_name ASC, admin_users.first_name ASC")
attr_protected :hashed_password, :salt
def name
"#{first_name} #{last_name}"
end
def self.authenticate(username="", password="")
user = AdminUser.find_by_username(username)
if user && user.password_match?(password)
return user
else
return false
end
end
# The same password string with the same hash method and salt
# should always generate the same hashed_password.
def password_match?(password="")
hashed_password == AdminUser.hash_with_salt(password, salt)
end
def self.make_salt(username="")
Digest::SHA1.hexdigest("Use #{username} with #{Time.now} to make salt")
end
def self.hash_with_salt(password="", salt="")
Digest::SHA1.hexdigest("Put #{salt} on the #{password}")
end
private
def create_hashed_password
# Whenever :password has a value hashing is needed
unless password.blank?
# always use "self" when assigning values
self.salt = AdminUser.make_salt(username) if salt.blank?
self.hashed_password = AdminUser.hash_with_salt(password, salt)
end
end
def clear_password
# for security and b/c hashing is not needed
self.password = nil
end
end
The method "name" is not finding a user from the database, however the variables inside it (first_name and last_name) are read from the corresponding database table fields. In this case assuming the usual rails conventions are followed you will find a database table called "AdminUsers" and inside it some fields of which one is first_name and another is second_name.
How this all works and why it is so can be found in the Ruby on Rails documentation for ActiveRecord