Authentication basics with Ruby on Rails

hey what's up welcome back in this episode we're going to build our own authentication for ruby on rails from scratch now in practice you don't want to do this instead you should depend on some gem or some other very thoroughly code reviewed tool for building your authentication system but we're going to build our own today so that we can understand more of the pieces about how authentication works so recall that in the last episode we scaffolded out a blog article tool so if we go back to the browser here we can come to our post our post tool so if we refresh the page we can go back and we have the ability to update edit create posts what i want to do now is associate posts which are models in our database with a specific user and we're going to walk through the entire flow for how you implement authentication so let's get into it all right so at the very base level right when someone creates an account they're going to give you a username and a password or an email and a password something that can uniquely identify them and something that they can memorize or know so generally when you're authenticating you're going to use something that you know you have or you are so if you uh if you know something that's like a password something memorized what's um what sucks about passwords is they get written down all the time in order to memorize them people think of things that are really easy like the word password don't do that um so things that you know are tricky right if you if you don't have like a really complex password or a password management system or something having a password in your head is tough so the second piece is something that you have maybe you have a physical key a ub key or some sort of thing that you can touch that's plugged into the usb port or maybe you have um you know like a physical card that you touch to a reader these are all things that you might have and only you're allowed to have them if you lose them then you can call the security people and they can disable your key and then they it's like no longer useful so that's something that you have something that you are that's like face id when you hold up your phone and you look at your face id that's something that you have that is like another way that you can authenticate right is through something that you have so something you know something you are or something that you have these are the three ways you can authenticate and the either email address or the username or the user id or the account id these are all things that will like sort of uniquely identify which user in the database we need to look up and so generally when you implement a user authentication system you want to keep track of these things so that you can figure out who is who inside of the database and so what we're going to do is we're going to build from first principles and we're going to go through like every step of the process and talk about ways that we can make it just a little bit better as we go so let's generate we're going to say railsg model user right and we're going to need to track again that you know username and password i'm actually going to use email and password right now it is very very bad practice to store an email and password inside of your database in plain text so if you are storing email and password in clear text i would like go immediately and change your authentication system so that it does something different anything different really so um but we're going to start off with this email and password okay i'm going to generate a model that has the email and password and then we're going to generate we'll say rake d or rails db migrate again don't ever store passwords in the database and we'll talk about why that's really bad okay next we need to generate a controller that can create new users so you're going to like allow people to sign up so we're gonna say rails g controller controller users and on the users controller i'm just gonna create a new view and a uh just start with a new view that'll allow us to at least register users okay all right let's go to our routes we have a new uh get route for like register and that's gonna go to the users controllers create action all right so let's go to our users controller and here we have a new route this is going to render the form back that has the username and password fields or the email and passwords fields and we're going to also create a create action but we'll come back and do that in just a moment so let's go to our new view for users this is our new our registration form and for now we're going to add a form that's going to send a post request to slash users this little bit here is our authenticity token we want to have the authenticity token in the form so that we don't receive crossed site requests that are forged and so let's also add let's add an input for the email and the value is going to start off with at user.email and initially the user is just going to be empty but we'll talk about that in a second and the name is going to be user email so we're going to send in the post request we're going to send a hash where it's user points at another hash and that hash has a key email and a value with whatever we typed in as the email and let's also create another field for the password let's actually do it this way so there is a type and input type of password and the value here is we don't want to type anything into the value because we never ever want the value to be like pre-filled right so we're going to remove that and but we do need a name so the name here is going to be user password okay and instead of submit we're going to say register and let's go back to our form here now we should be able to go to like slash register and see this form we just created create is missing a template uh you know what this register is supposed to be to slash new and then we should have like uh just user like resources uh users only create sure undefined method email for nil class so here we're trying to call email on an instance variable at user but at user doesn't exist yet so let's go back to our new route for the users controller here and we want to create a blank user so we're going to say at user equals user.new okay and we're going to refresh our page and now we see the email and password input and give it an email wave at cjaf.dev and the password is going to be password password one two three because our create action doesn't have any logic so we need to implement some logic to actually save this data in the database now if we go down to the request that we received so we started a post request to slash users we got the authenticity token and we got this hash user points at email that's the email that received password is the password help like there's a really helpful thing in rails where it's like oh we think we're receiving something sensitive let's filter that out so it filtered out our password thankfully right and so that didn't actually get saved and because there was no template and no logic inside of create we just rendered back empty so here what we want to do is actually create our user so we're going to say at user equals user.new user params uh private def user params we're gonna say params.require user.permit email and password okay and i feel so dirty saving the password in the database already like i just this is so bad but we're going to come back and we're going to fix we're going to make it better i promise so now we're going to say if at user dot save maybe like redirect to like posts posts path else render uh new and we'll we'll leave it there so now if we refresh the page and we say our email is this and our password is password and we say register okay now we got redirected to the slash posts page right now we are seeing all the posts and let's go look in the database all right so we're going to look at the database and the way that you can log into the database is with railsdb console this gives you like a really quick way to log into whatever database you're using and so this is this is us actually messing around with the postgres database that's underlying our our data so we can here say select star from users and this is going to give us the data that's in the database and this was literally the password that i typed in on the front end now if some attacker was able to get into your system which you know there's new attacks that come out every single day if someone's able to get into your system and dump your database you're now seeing the combination of email and password have you ever used the same email and password at multiple different places think about that it's terrifying there's like a lump in my throat thinking about like oh gosh i usually do this all the time before i had a password manager which you just saw pop up uh so if your database of email and password stored in plain text is compromised and you lose like this gets leaked out into the world or bought on the dark net or you know there's tons and tons of issues with this right because now attackers can attempt to use this email address and this password at thousands of other sites right they can try it on banks they can try it at um you know on crypto sites they can try it on email on email accounts if they can get into your email account they can get into uh you know like they can start doing password recovery for other systems so this is really really bad like really really bad so we do not ever want to store the password in the database in plain text but we're going to keep going all right the next step here is that we need a way for people to log in and we need to know who the logged in user is so we've created a user they're in our database but we don't have a concept of whether a user is logged in or not and we're going to talk about how that works in order to log in a user needs to provide their email and their password so they're going to provide their email and their password and we somehow need to figure out like who was that logged in user and how do we keep track of who's logged in and who's allowed to access what right and so one way to solve this is using a mechanism called cookies so the way that a cookie works is the server is allowed to write some data into the response that's sent back to the browser and then the browser will say oh i received a cookie from the server let me write that into my log that says anytime i'm going to send a request back to that same server i'm going to pass the cookie back to that server this is how you can like persist how you can establish a you know persistence between requests so typically the web is stateless meaning that like when you make a request and you receive a response the next request you make should know generally knows nothing about the previous request it's they're all going to be uh you know individual requests and responses that are going back and forth the only mechanism that we have to sort of persist state between requests as part of a session is to store data into some cookie or pass data back and forth between the browser and the client for every single request that's happening and so typically the way that you know one of the standard ways this works is by storing reference to whatever the logged in user is inside of the cookie okay so we're going to store when a user logs in we're going to say oh we found the user in the database we're going to take their id or their email address or something that uniquely identifies that user and we're going to stick that into a cookie from the server and send it back to the client and then every request the client makes for the rest of that session is going to pass that same identifier back to the server and we'll be able to use that identifier to look up who the current user is and associate our queries and all the data and the access and the authorization with whoever that current user is and so let's uh let's go through the process of building out what i'm going to call a sessions controller this is just the controller that manages creating that cookie and that relationship between each of these the requests that are going to happen for this specific user from this point forward so let me say rails g controller sessions and again we're just going to have new and that'll probably be good to start we're going to first open up our routes and go down here and add uh let's say get to slash sign in is going to go to sessions uh sessions new and we'll also say um get like sign out is going to go to sessions destroy and then we'll also say resource sessions only create that'll be where we receive the post request for uh for creating the session um okay so session slash news sign in sign out we got sessions okay let's go to the sessions controller in our sessions controller again we're actually going to use the user model because that's going to be the model that stores the email and something not the password but something let me say at user is equal to user.new when we're on the new view and then we're going to say create and inside of create is where we're going to like look up the user if they exist in the database we're going to cookie them and then start you know keeping track of their requests and responses so let's go to the new view sessions new this is actually going to be basically users new with a small change okay so instead of going to slash users we're going to go sessions and this is going to be called sign in and instead of register we're going to say sign in and everything else is just going to stay the same okay so if we go back to our browser and go to slash sign in we should receive that view okay we do and we should say okay i'm gonna i'm gonna say wave i'm gonna type in password and hit sign in and this should hit our create action which isn't defined yet and we got back a blank response so we see the same page so let's go back to our sessions controller and figure out how we want to do this create so first we need to like look up the user then we need to like compare their password right okay so the first step to look up the user in the database we're going to say at user equals user.find by and then the thing we're going to find them by is their email address the email address is always going to come into plain text it's uh it's okay if it's in plain text in the database too okay so we're going to find them by their email address and in the request that we just received we're going to retreat we're going to receive some like user params again and that's going to have an email so this this user params method is going to be the same as our users controller so i'm just going to come down here and copy these four lines five lines and all right so user params email that's going to give us the email address that they typed in if we found the user so if there is a user and if at user.password is the same as user params password then we want to like cookie them so we want to set a cookie with that user's id so that we can keep track of them in between requests all right so now we're going to say cookies at maybe we call it like user id is equal to at user.id okay and then we can say render or like redirect to posts path all right so if we either did not find the user in the database or the password did not match what we want to do is we're going to render we're going to re-render new and before we re-render new we actually want that notice to show up on the page so we're going to say flash dot now colon notice so that we have a notice that's in there just for this this rendering that is in response to this request we're gonna say invalid email or password and if either the email was wrong because and we didn't find a user or because the password was wrong and it didn't match the password for the user we want to set that notice up and from the new view from the new view here at the top we can add a p tag with id notice and we'll print out that notice again this was very similar to what was used by default inside of the posts the scaffold for the posts and if we go back to our browser now and type in an email address and then we leave the password blank we can say sign in and that gives us email invalid email or password and if we try another password which is the actual password and click sign in then we're redirected to slash posts if i right click and go to inspect to open up the chrome developer tools and go to the application and cookies here so we're gonna see a cookie in each cookie that the browser stores is related to a specific domain or a specific like server right so in this case localhost 3000 and inside here we see user id 1 and we actually see the value 1 inside of the cookie directly in the browser now think for a moment why this might be bad so a couple things right we see the raw value for the cookie so we can see exactly what's in the cookie we can see the key is user underscore id and we can see the value is one now let's just log in as user three okay now we're logged in as user three so let's talk about how we're actually going to use this cookie to look up the user and then we'll go back and fix the issue with why that's why that's bad and that's like should not be inside of directly inside of the cookie like that in plain text so generally inside of application controller or somewhere around here we will have methods for looking up who is the current user so we're going to write a method current user and the whole job of this method is to look at the cookies that we received and look up the user in the database who has that id or that whatever we're tracking by so we're going to say user.find cookies user id and that's what we're going to return as our current user so if we come over here and we go to our like let's see layout.application.html.erb this is kind of like the the master layout view that's going to be used for all of our views by default at the top we can say if if there's a current user then let's just print out like a hi and then their their their email address current user.email and before we can call this method here this current user method inside of the view we need to make it available to the view so by default the instance variables we create in the controller those are all going to be available to the view any methods we write in helpers are going to be available to the view but if we want a method that's inside the controller to be available in the view we need to use this special thing called a helper method so we're going to say that current user is a helper method that we're going to call from the view so now if we come back to our browser and we refresh the page here we are oh couldn't find a user with the id3 yeah because we logged in as a different user let's actually go in the database rails c so we'll say rails console we'll use the rails console to create a second user so user.new email is test two at gmail no example.com password is fancy password uh or instead of dot new we can say dot create okay so that puts it in the database and now we can log in as user two just by changing that and we'll refresh the page here so now we're logged in as user two hi test two at example.com and if we wanna log in as ourselves we can change that to user1 and then we can refresh the page hi wave at cjefdev so just by changing the cookie value we're logging in as different users so that's really bad and if we wanted to log out we could right click this and say delete right delete the cookie and now if we refresh no one's logged in and now we have an error that says we couldn't find the user without an id so we need to improve our current user method here and one thing we can say is like if cookies at user id so if there is a value there then return this thing otherwise don't and then we can refresh the page now we don't have any logged in user and if we wanted to we could come over here and log in by just creating a cookie which is bad so sessions are like sign let's sign in again we're going to pass in wave at cgi dev password and we're signed in now we see we're cookied with our user id here uh and we can just change that again to two to log in as this other user again very bad but you can see that like by the the fact that i'm refreshing the page here i'm sending a new request the values here in the cookie are being sent to the server and then the server is able to use that cookie to look up the user in the database and return it or like then use it as part of as part of the the controller's response so typically what we might do is scope all of these posts to the current logged in user and we'll do that later after we clean up all of our security vulnerabilities so the first one that i want to do is let's talk about how we can make this cookie encrypted so there's a couple different ways so you can go back to where we set the cookie so inside of the sessions controller here where we set the cookie this is us like logging the user in right this is where we're actually setting the cookie we don't want to just use cookies with square brackets because that's going to set a plain text cookie all right so instead of using cookies with square brackets directly we want to use some other helpful methods that are available for cookies so here is the documentation for rails cookies here this is where the cookie will be stored in plain text we've also got cookies dot signed this means that the user cannot mess around with the cookie so let's start here and change it to signed so we'll say cookies dot go back to sign in this is when we sign in is where we're going to use the signed cookie so now we can say password we're going to click sign in and now you'll notice that our cookie has like some crazy value that we're not able to tell what it is so it's a little bit trickier to mess with hard to tell that that's actually you know some actual valid value and we get an error that says we couldn't find a user with that id so we actually need to come back over here to our application controller and use cookies dot signed to pull it out of the database like that and now when we refresh we can see wave at cgi dev but this cookie signing thing isn't super secure that's not actually like securing it it's just making it so that it's it's harder to tamper with there is yet another tool here that allows us to encrypt the cookie so we can encrypt we can and we can chain these together so we can say permanent signed or signed encrypted or whatever so we're going to actually like encrypt we're going to encrypt this too we're going to say encrypted.signed so now when we log out by deleting our cookie here and refreshing the page we don't see ourselves logged in we're going to go back to sign in we're going to log back in and now that we're signed in now this cookie is both encrypted and signed now look at how complex that looks there's no way we're messing around with that right and we're definitely not going to switch to another user just by futzing around with this this user id that's here now in practice instead of using cookies at all what we generally do we'll use something called the session so session is another sort of tool that's available inside of the controller and it works by default with encrypted cookies so we can change this entire thing here to just session and store the user id in the session and then here we can say session if there's a session then look up the current user by the session and we'll come back over here refresh the page we're not logged in anymore we can delete this we can refresh the page and go back to slash sign in and we'll log back in password so again session is going to be maintained a very similar way as cookies but now we we no longer actually see any cookie with user id over here we don't actually know what's stored in that session we just know that you know there's some cookies they're being used for something and somewhere inside of this blob is where our user id is stored and on the server we're able to look that up and pull out the user from the database and print out their email address here so that was like the first big improvement is we switched from just like a raw cookie that you could mess around with to assigned one to an encrypted one and now we are using session which is using signed encrypted cookies but it's storing it inside of a value where we don't actually know what the keys are for those cookies so now we are in a much better place in terms of cookies the next thing is we want to fix our password issue so passwords we don't want to again we don't want to store them right in the database right so right now if we say like user.pluck password we're going to see all the these are the raw passwords for our users password fancy password etc we don't want to be able to do that so instead what we want to do is we're going to gener we're going to say like rails g migration change password field or something like that change password to password digest and we will write a little bit of a a migration to rename our password field so let's update we're going to like rename column on users from password to password digest rate db or rails db migrate now instead of storing the raw password in the database what we're going to do is use a hashing function so a hashing function it's going to be a one-way hashing function the hashing function is going to take some raw input in this case the password and it's going to run it through some function and that function is going to consistently and reliably and stable in a stable way generate some other random string where you cannot take that random string and go backwards to the password without like tons and tons and tons and tons of work so much work that it would take longer than our lifetime in order to do at least with the current computing capacity that we know about so what we're going to do is we're going to use bcrypt which is a tool for creating secure passwords so we're going to do this we're going to open up our gem file we're going to look at bcrypt and we're going to install this gem bcrypt bcrypt you'll notice that there is like has secure password that is like a shortcut we're not going to use that yet we're going to use bcrypt directly and talk about how bcrypt might use a one-way password hashing in order to take some raw input and then store it in the database in a way that you cannot reverse so we're going to install this gem so we're going to say bundle install okay now we've installed bcrypt we can go use this so we're actually not going to change our our user our users controller here okay when we create a new user we are going to continue passing down user params where we're going to continue passing down this email and the raw password but we renamed the column in the database to password digest so if we say user.plug password it doesn't have password anymore select star select password from users doesn't exist anymore we could say use pluck password digest and this is going to give us those passwords but we're no longer going to store the raw plain text password anymore but we do need a method where we can set the password so let's go to the user model so here let's actually say like user.destroy all just so we can start from scratch and we will let's clear this out let's actually keep the console somewhere all right so on our user model we're going to write a setter method where we can receive a password in raw plain text so we say def password equals and this is going to give us our plain text password so we need to take in that raw password and use bcrypt as a one-way hashing function to create our password all right so this is the documentation for bcrypt there is a class called bcrypt password and the way that it works is we call password.create and we pass it in the secret and we get back this giant hashed thing okay so we're going to say be bcrypt password dot create raw okay that's going to give us back a a password that's been like uh hashed if our password is banana and we pass in banana this bcrypt password.create is going to return some giant hashed thing when we get that value back that is what we're going to stick in the database so here what we actually want to do is call self.password digest equals bcryptpassword.create so this is going to create the password hash based on our input password and store the hash in the database not the raw plaintext password so okay so let's save that rails c we're gonna say u equals user dot new now if we say u.password equals test and then we say uh u the password digest is filtered so if we say u.password digest this does not equal test so now if we try to say like udot password we don't actually get the password back because there's no reader method for password there's no way to like look at the raw password inside of the database right and so now in the database if we were to save this user if we said like u.s save bang that's going to save a user in the database now if we go to railsdb console and try to look at the data that's in the database like maybe this is the data that got that gets leaked on the dark net or something right we can say like select star from users and at this point we have the id we have no email entered and we have this giant thing that who knows how to get back to test from this no one except what we can do is uh rails see we can now take that password digest and check to see if the hash for another input matches the hash so we can like rehash some other input when we're logging back in and check to see if those hashed outputs match so now we can say like okay we have this user in the database uh u equals user.last right now what we want to do is check to see if we can figure out what that users or if we can authenticate as that user by checking with bcrypt bcrypt password dot new u.password digest dot is password and then we can pass in test and that returns true so what we're doing here is we're initializing an instance of a decrypt password with the hash that's in the database and then a method on that that password instance is called is password and you can pass that a plain text thing that will hash test again and check to see if test is the password in the database so is is the password banana no it's not so that's false so it does not match you can also add like entropy to these things so like it requires a certain number of passes so that it requires even more computation to create the password check the password etc tool that we're going to use to confirm that it is the password when someone is logging back in so we're going to go back to the user model and we're going to add another method here called is password and this is going to take in the raw and we're going to say here we want to initialize a new instance of a password a bcrypt password object so bcrypt dot password.new and the way we initialize it is with whatever is in the database already so password digest and then we're going to call dot is password on that instance passing in the raw and whatever we get back from this is password method is what uh whether or not that is their actual password notice that here i'm using just password digest as a bare word i don't call self.password digest here i did use self.password digest that's because i'm calling a setter method and when you're using a setter method you have to prefix with self dot so it doesn't think that you're creating a local variable inside of this this method all right so now that we've got these let's go back to our sessions controller and update this logic so instead of just checking if the password that was passed in matches the password that we're able to look up on the user let's now say user dot is password and pass in the password that was you know sent to us from the front end so now we can refresh this page actually let's log out uh couldn't find user with id1 ah because we deleted them from the database all right so let's uh let's let's do that rails see user.destroy all and then we got to like log out so we're just going to delete this session cookie thing okay so now we're going to sign in and our we're going to enter or actually we need to register so let's go to slash register and when we register we're going to put in our email and when we put in our password now i'm going to again put in password and when i click register uninitialize constant ah we need to restart the server so if you get this error uninitialized constant decrypt we installed the gem so it should have the gem right but we're getting this uninitialized constant because after i installed the gem i did not restart the server so i gotta stop the server with control c restart the server with rails s and then we'll come back over here refresh the page go back to slash register and okay let's try this again banana click register all right fantastic we're again seeing our posts we don't see uh are we logged in we see the session here why don't we see the session at the top um oh you know what okay so this is great this is great when we're creating the user for the first time we're redirecting to slash posts but we didn't do the bit where we're setting the user id on the session okay so in the user's controller after we create the user right here we're redirecting to posts but we're not actually logging the user in so there is no logged in user at this point we created the user but they're not signed in so let's go to sign in in practice too you might hide that list of posts or something so we'll sign back in put in our email and our password and now we are signed back in and we can see our our email address at the top and we are we're totally logged back in if we go back over here and we say railsdb console the user that we created should not have a password a raw plaintext password in the database we can say select star from users and we see this hashed password now in the database that is looking fantastic right that is looking really really good and yeah i'm pretty happy with that all right next step here is that generally you you want to have like some restrictions around the password that you're creating right you don't want people to just sign up with like uh x at example.com and then have their password be like a and be able to register you shouldn't be able to register if your password is just one character there's not enough entropy in a one character password to be secure like someone could just guess that if you were allowed to have one character passwords so the next thing we want to do is add some validations to our user model that requires that the password that's passed in the raw password that's passed in has at least some sort of restrictions or some sort of limits so we'll go to the user model here and in order to actually like ensure things about the password that we're creating are valid we're going to add some validations all right so inside of our user model we want to validate the password has a length of at least 9 and allow nil true so when we say validates and then pass it some some symbol here it is going to the the the model is going to call this method on the instance of the model when it's running its validations and it is going to check to see if whatever is returned from this method passes these validations so in this case what we're saying is like whatever the value is returned from the password method must be at least nine or it can be nil and the reason why we're saying you can it can be nil is that we want to be able to update the users maybe want to update the user's email address or their profile picture or something like that when we're updating we're also going to run the same validations and in the update case we're not going to have any password at that point so we're only going to validate this password is at least nine characters let's actually make this a little bit shorter we'll just say like four so that we have uh it's like easy to play with maybe five we're going to validate this password only when we are creating the user or updating the user's password explicitly and so how does this actually work so it's actually going to call the password method and right now we don't actually have a password method we have a password equals setter method but we do not have a password getter method so we could we could write a method here like def password but how would we return the raw value for the password that was passed in without saving it in the database well what we want to do is we're actually going to store the password in memory for just a second when someone passes in the password we're going to store it in memory here we're going to say at password is equal to raw now this app password instance variable is not put in the database in any way it's just in memory for the the duration of that single request to create the user and in our getter method for the password here we can say at password so when the password method is called during the validation step before the user is saved in the database we will check to see if the password is nil or if the password is at least five characters long all right so let's test this out so we're going to refresh the page we're going to go back to register we're going to type in our uh maybe wave 2 and then if we if we type in a password that's one character long and say register it failed but we didn't get any notification so let's let's go update um let's go update our users new so that it has a id or uh p id notice notice and then we'll go back to our users controller where we're registering and if we fail we're going to again going to say flash.now notice equals like at user dot errors dot full messages dot dot two sentence all right so let's refresh all right password is too short the minimum is five characters so now we are getting some feedback here that we're not allowed to pass in a password that's too short so now we'll try more than two characters one two three four five six or five characters and we'll say register now we have successfully registered and we were re-logged in as the same email address okay so now let's look in the database rails rails console user dot pluck email uh oh we've got two people with the email of x at example.com so that's a problem so we've got to go back over to our user model and let's add another validation validates email uniqueness true okay so now if we were to come back over here and try to go to uh register and we're still look that we're still logged in so let's like log ourselves out delete and we say let's like try to register with the same email address with one two three four five six and say register that fails invalid authenticity token ah because we we deleted the cookie after the page was loaded let's try this again one two three four five six register email has already been taken fantastic so now we are ensuring that the email is unique and that the password is hashed and that the password is a certain length we're getting somewhere let's try another thing what if we registered with just a password if we just say register uh oh that worked if we look at the user.last their email address is empty that's not cool that is like not that is not cool so let's go back to our user and make sure that we have a we have an email so we're gonna say validates uh email presence true we wanna make sure that we actually have an email so if we go back to register and we try to register again with no email we get an error that says email has already been taken and email can't be blank so it both has to be unique and it can't be blank so that can be really handy for validating that the email and password is valid or that we have an email and we have a password and the password is at least five characters you could write your own custom validation too that ensured that the password was at least eight characters and had at least one number and at least one symbol etc etc so that you are enforcing good good password behavior uh in practice i think email and password is going away in place like in in preference of having like uh in uh sending a magic link to an email address and or sending a text message with some code and or like using an a third-party oauth auth provider like authy or google authenticator so this is really just talking about the fundamentals of how you might build an authentication system again we're going through the whole process here by hand there are these like helper methods called has secure password that does a lot of this stuff for you but i wanted to show like all the different pieces and how this might actually work under the hood so that they are familiar and if you need to actually debug something or get into something you uh you you can do that and you know where to find things and then in the next episode what i want to do is actually scope the list of posts so posts here we will scope this down to only the posts that are associated with the current user and we will update the scaffolded posts controller to use the current user the authenticated user to only show them their own posts basically so that will that will be fun in the next episode thank you so much for watching i hope you learned a ton and yeah we'll see you next time you

Channel: CJ Avilla

Views: 1,282

Keywords: cjav_dev, web development tutorials, web development for beginners, vim, ruby, rails, javascript, authentication, email and password, password authentication, ruby on rails tutorial, ruby on rails, cookies, session, bcrypt, password hashing

Id: MGNc6qCZBmE

Length: 46min 17sec (2777 seconds)

Published: Wed Aug 11 2021