I'm making my first app with rails and this app would be accessible only if user are logged and only admin can create user, so when my app would be online I need at least one admin to create the other right ?
I tried with seed to create an user, the user is well created but I can't connect to my app with it, I think it's a prob with the encrypted password, here is what I have done :
UserManager::User.create({ name: 'a', surname: 'a', email: 'a', active: true, id: 1, password_hash: 'a', password_salt: 'a'})
Is that possible and it is right to create user with seed ? and if it is how can I do to encrypt the password in seed ?
I'm making my first app with rails and this app would be accessible only if user are logged and only admin can create user, so when my app would be online I need at least one admin to create the other right ? Yes
Is that possible and it is right to create user with seed ? This is probably a debatable point, but as long as you secure your seed file, it may be a reasonable approach. You probably want to change the password as soon as possible and/or use an environment variable for your password. Whatever you do, don't use plaintext, add your admin password to your git repository and then leave it unchanged in production.
and if it is how can I do to encrypt the password in seed ? You probably shouldn't be loading attributes like password_hash and password_salt explicitly. Instead, just set password (and password_confirmation if you have it).
You should be Running:
UserManager::User.create(name: 'a', surname: 'a', email: 'a', password: 'foobar123', password_confirmation: 'foobar123')
Other answer by Steve answers the remaining issues.
Related
At my company we're designing a new flow for our user to register. User and Company are very closely tied to each other. Due to several reasons we can't create the user and the company one after the other but we need to create them at the same time.
However as our form is on several steps, we collect all the user input in a separate Registration model in a jsonb attribute and then create the user and company at the end of the process from this intermediate model.
One of the problem is that we collect the user password. However as we're storing the registration in our database, the password is exposed.
How would you try to protect this?
EDIT: We're using Bcrypt to encrypt password
I have not tried this but I guess this will work. You can use the following code to encrypt the password before storing it as intermediate json.
my_password = BCrypt::Password.create("my password")
If you have designed the User model properly, there will be a password_digest field in your table. So while saving encrypted password, use:
#user.password_digest = my_password
instead of
#user.password = my_password
where you expect encryption to take place in the background.
I'm following this tutorial, as I wanted to learn how to create user authorization with singular roles (each user has one role) from scratch rather than using a gem like rolify that does it all for me, but I'm hung up on assigning the users access levels.
When I type erin = User.find(9) in the console it finds my test#test.com user. I try to issue the erin.admin! command but it throws an error about the password? (ActiveRecord::RecordInvalid: Validation failed: Password can't be blank).
I've also tried erin.access_level = "admin" which returns "admin" while I'm still in the console but no longer exists when I exit the console, fire up the rails server and try to test out my test#test.com user in my app.
Is there any other way to assign access levels? Am I just doing it wrong?
The User record cannot be saved because a validation exists that requires a password. I don't know if there are special rules for the format of the password, but you can easily set a password so that you can save the user:
user = User.find(9)
user.password = 'Test1234'
user.password_confirmation = 'Test1234' # you might need this as well
user.access_level = 'admin'
user.save #=> true
If user.save returns false, check user.errors for any other validation errors that would cause the record not to save.
For the second part of my question, where my database didn't seem to deploy to Heroku, it's because I was working in the dev db, not the production db.
To do that, I ran "heroku run rails console" and then followed the above steps to give a user admin access levels. More here: https://devcenter.heroku.com/articles/getting-started-with-rails4#console
I'm making an app with a User model that will use devise for authentication. I'm also seeding it with a lot of data that I already have, and making columns for data that I anticipate having (such as social network profiles and personal information I don't have yet). As the table columns started to add up, it occurred to me that I might create a User table for authentication data, and then some sort of User_Profile table for details about the user that will appear on their profile page. I'm wondering if this would be a better idea or just stick everything in one table and then continue to add more columns related to the user as i think of them.
User.create!(
devise related columns ommitted....
firstname: "Marcy",
middle: "Eve",
lastname: "Bishopf",
sex: "f",
company: "Johnston Windows",
address: "210-3260 North Dr",
city: "Victoria",
province: "BC",
postal: "V9T 1XS",
email: "mb#blahblah",
phone: "(250) 756-3777",
website: ""
twitter: "",
facebook: "",
linkedin: "",
year: "",
school: ""
motto: ""
more columns for personal data that I haven't thought of yet
)
If I understand correctly, you need to have User Authentication as well as User meta data (name and other profile fields) persisted in the database.
You should definitely normalize the database, User Table for Authentication along with a separate User Profile table referenced by user_id from User Table is preferred.
This is important for the following reasons:
When the user needs to log in, you simply have to check the hash of the password against the User Table.
When the user is logged in, you can simply fetch the profile from the User Profile Table by using the user_id of the logged in user.
When a new column is added to User Profile table, your User Table is not impacted.
However when your number of Users are large, altering the table User Profile could be costly operation locking the table.
I've developed a Rails 3 application with Devise for registration and login control. I want to be able to modify any user's password to one I provide.
The solution I've come up with (I haven't had the chance to test it yet) is to make a fake new registration with the password I choose, copy the password from the table record to the user's record in question, and then delete the fake record I generated in the DB. It's not the most elegant thing to do, but it is all I've got. I wait for better suggestions.
I might be misunderstanding the question but it should be as simple as;
#user = User.find(<some id>)
#user.update_attributes(:password => 'anewpassword', :password_confirmation => 'anewpassword')
then their password will be 'anewpassword'
The rails framework Hobo is brilliant and automatically creates the first user as the admin user (unless you ask it not to). The problem I have is that running rails in development I can't remember what the password was. This should be trivial because I just run rails console, find the user admin = User.find :first and reset the password (trying)
admin.password = 'Anything1234'
admin.password_confirmation = admin.password
admin.save
>false
admin.errors
>{:current_password=>["is not correct"]}
I.e. the implication is that the variable current_password needs to be set correctly before I can change the existing password.
I'm afraid the Hobo documentation doesn't help in this case. Does anyone know the how to drive the Hobo user model to reset the password?
4 possible solutions:
1: run your app, and click on the forgot password link. The message will appear in your logs, so you don't need a mailer set up.
2: Just save without doing any validations:
admin.save(false)
EDIT: in Rails 3 this is
admin.save(:validate => false)
3: Another option is just to delete all users so you get your initial user entry screen back.
4: If you really want to run the validations, you can trigger the request_password_reset lifecycle:
admin.lifecycle.request_password_reset!(Guest.new)
then look in development log for the reset password key
u.lifecycle.reset_password!(Guest.new, :key => 'a0a2db1035065fa7ad5d46d35669d206aee73668', :password=>"test123", :password_confirmation=>"test123")
Yes, you need to set the current_password before you set the password and password_confirmation fields. This is to stop the user from changing the password without originally knowing the password.
Therefore, you would need to do something like this:
admin.current_password = 'password'
admin.password = 'Anything1234'
admin.password_confirmation = admin.password
admin.save