How to Add Custom Attributes to a Devise Based Authentication System

Jordan Hudgens
A free video tutorial from Jordan Hudgens
CTO at Bottega Code School
4.4 instructor rating • 16 courses • 75,776 students

Lecture description

Learn how to customize the Devise authentication system by adding new User attributes that can be added during the sign up process.

Learn more from the full course

Dissecting Ruby on Rails 5 - Become a Professional Developer

Don't simply follow a tutorial, learn what it really takes to become a pro Rails developer with this immersive course.

43:17:08 of on-demand video • Updated March 2021

  • Build a professional Rails application.
  • Implement advanced JavaScript components, such as persistent drag and drop functionality and live page update via ActionCable into a Rails application.
  • Deploying a Rails application along with the ActionCable web socket feature to Heroku.
  • Build a Rails 5 application that utilizes multiple layouts.
  • Build jQuery and CoffeeScript components that can be utilized by the Rails application.
English [Auto] Starting now in the pivotal tracker project management dashboard, you can see the next item on the list is to customize our attributes. And what I mean by that is we want the ability for our user to have a name. So instead of simply going by their email address, I think it makes sense for them also to be able to type their name out. And if we come back to the site and click on register, you can see by default device only gives us the ability to have a email address and a password. So that is what we're going to change. Now, if you remember back to when we created the migration, if we scroll down, you can see that we added a name attribute, but even then we added it in the migration that doesn't automatically add it to the form fields. So we're going to start off by doing that. I have opened up our items right here. So we have if you go to views Devi's registrations, you can see that we have two files here. You open up both of them and I'll put them right next to each other. So get a view and then go to layout and let's select columns. So I'm going to have edit right here and new right here. So all we have to do is actually create and we can just copy and paste right here, these fields. And I'm going to also show you what edit does. In fact, before I even save this, let me show you what edit does. So you have register if you switch that off and just say edit, oh, we're going to have to actually register. So let me save that to show you after we've added this just so you can see the change. So right here, I'm going to change this to name and I also want to change this to TextField and get rid of autofocus. True. We don't want this exactly like the email address. And if you're curious what this essentially does, if you click on sign up, you notice how the cursor is automatically in the little email field. That's because it has autofocus true set on it. You only want one field. You can only have one field to have autofocus. True, when you load the page. And by default and usually this is what you want is to have it on the email address. It makes a little bit easier for the user to simply start typing instead of having to click in it. So that's the reason why I removed it from name. I also remove this so it's not using the email field type. This just gives some kind of easy nothing too big, but just some little validation. So if your user starts typing something in and it's not a valid email address, then it is going to throw an error. This is just for the HTML5 client validation. So, you know, I talked about how in the configuration file had all those validations for the email address. This is different than that. This is just the will form field. This is not the server side validation. But with that still being said, we do want to have a TextField here for name and that's it. We're not going to worry about the styling or making it pretty right now. This is on the edit side. Now come to the new side. This is actually the registration page. And if you ever want to test it out, you can just come here up to the top hit, save up some gibberish right there, hit refresh. And you can see that this is the page that we are working on. Delete that. And right below here, I'm going to paste in what I copied from the edit page hit Save. And now if I hit refresh, you can see that now we have a name value. Now this by itself is not going to work just as it is. And I'll show you because if I create a new account, I'll say test to test dot com and I can type in my name password and then hit sign up. You can say welcome. You have signed in successfully, which you may think, oh, that worked. No, it did not. For one thing, look, the name value is blank right here, so it didn't capture the name. And if you go to the terminal and you come and see what was attempted right here, then let's take a look at the actual sequel. So it selected one and inserted two users the email address they created at Values, but it didn't do the name. And if you scroll just up just a little bit right here, you can see. That right here, it created a post request, that's the route that it uses whenever it wants to create something. So this is the point right here where it said, OK, we're creating a new user and we're going to use the Devi's registration controller create and we're going to pass in these parameters. It passed in the type passed in an authenticity token, which is something we'll talk about later. And then it passed in this user object. This is what we're concerned with. So it passed in the user. It said here's his email address. It's test to test dotcom. Com So far, so good. It passed in the name just like I typed it in. Then it passed in the password, which you notice it filters. It doesn't show this even in the log files for security reasons. And that was it. But so but this didn't get passed in here in the reason is because this one little line right here, it says unpermitted parameter name. So what this means is if you remember to back to when we talked about our controller. So let's just open up just for review, not the model. Let's look at the blog controller. If you scroll all the way down. Do you remember when I talked about the blog programs and talked about how the title and body right here are items that we have to list off? And what they're telling Rales is these are the attributes that can be passed in, but these are the only attributes that can be passed in. You cannot submit anything besides these two items in the form or else we're going to think that it might be a hacker that's trying to send some other bad parameter. They're trying to send some bad data. So white listing, this is very important. And so that is what is happening right here. If I open up the terminal and you can see unpermitted print, unpermitted parameter, this means that it needs to be told that name can be passed in the form. Now, whenever we're doing this with Divines, it's not quite as easy as when we're doing it just with a regular controller because we don't have access to the device controller directly. If you come to your list of controllers, you may notice one of the things that was not created for us was a device or a user controller. We have our application controller, blogs, pages and portfolios, but not actually one for our users. So that is what we're going to fix in order to get this working. I'm going to close these into one and let's open up the application controller. So this is the controller and we're going to talk a lot more about this when we get into our controller section. But this essentially is the master controller for the entire app. And if you click on blog controller, you can see that blog controller actually inherits from application controller and so does pages and so does portfolios. So if you remember your Ruby inheritance, what this means is that all of these controllers, since they inherit from it, they are going to be able to do anything that you put inside of application controller. All of the other ones are going to have access to. So this is where we're going to start by putting our special devices parameter white list in the next guide. I'm going to show you how we can refactor this and follow best practices, because this is something I've spoken about with a number of developers. No one likes putting their devices whitelist in the application controller, but it's something that's been done for years. I'm going to show you what I personally do and what I think is considered a better practice. But I'll do that in the next guide. So what I'm going to do here is I'm going to add a before filter. Now, remember that if you look at any of our let's take a look at our blogs controller. If you remember, we have a before action right here and before action and before filter are pretty similar. And what they're essentially doing is they're saying that whatever happens before everything else, that is what I want to tell it to do. So whatever I say right here, whatever method I pass in, I'm saying run this before you run everything else in the rest of the controller. And since this is the application controller, we're saying run whatever I say here, run this before all of the other controllers. So I'm going to say before filter and then configure permitted. Permitted parameters, and this is a name. I'm just coming up with there's nothing special about this and I'll say if. Dubai's comptroller questionmark, this is a special method here that is going to check and say, I want you to run. So I want you to run this method, but only if you're receiving some type of device controller communication. So we're not gonna have to worry about this running all the time, even though it's in our application controller, because I can put this flag at the end of it. It's not a big deal on that side of it right now. We're going to get more into all of this when we get in the controller section. But for right now, just know that we are essentially just saying, I want to add and create a method and have it run any time you're communicating with device. And now we can instantiate this method. So here I'm going to create a method called configure permitted parameters. And this is what's going to be called right here and now inside of it, I have some new things that I need to put in. Now, these are specific to Rales five. So if you have come from Real's three or rails for there are some new methods that device came up with and those old ones that you're using will no longer work. So if I do devise parameter and hope, if I spelt it properly sanitiser permit and then pass in, sign up and then pass in the keys that I want to permit now, I don't have to pass in the email password and all of those because Devizes own system already has that. I just need to add on to the one so that I want to add in this case it's just name. So here, I'm going to copy this because this is for our sign up, our registration. We also need to do it for our editing room. So I'm going to say account update because that's actually the name that Devi's uses. And this one is also going to be his name. So if I hit Save now, let's come back to our page, click log out and let's do this from scratch. I'm going to say test three, test dot com, save just the name of Jordan and pass in a password. Click sign up and let's test this out. And one, yes, we can come to edit. So if I come to edit right here, you can see that look now that's working. So now it says Jordan. And if I update this, I say Hudgens. And whenever you're making a edit on the user, you also have to type in whatever the user's password is to confirm the change update. And there you go. And this is all working. So now we are good to go. And if I come up hit edit just to verify one more time, you can see it has been updated to Jordan Hudgens if I change it and cleared my middle name, Jordan David Hudgens update. We can check out the controller. And now look, if you see where all of this happens, where you have the request now, it says the parameters. When you see the user object, it says test three, test dot com name Jordan, David Hudgens. And we no longer have that unpermitted parameter list. So that is all working in good. Let's see all the changes we made. So we made a change to the application controller, to the registration controller and for editing and for creating a new login. So that's good. Let's say I did get status, get at all it commit and say added new parameters for user registration and editing. I account get Bush origin authentication and everything is now pushed up to GitHub. So very nice going through that. And in the next guide, what we're going to do is we're actually going to implement some best practices so we can clean up our application controller and we're going to use controller concerns in order to do it. So we'll see you then.