Transcript
Hello, France. For many years, there has been a debate in the Ruben Rails community whether there should be a generator for authentication by default in Rails. And as of now, there is going to be one. So let's see how it works in the European Rails application. Uh, at, at the moment, uh, the code is not yet, uh, available in the latest, uh, stable release of, uh, ribbon Rails, but it's available on the main branch as it has been merged to Main. So I'm going to create a new repository using the main branch. And to do so, I will say rails new, then the name of the repository, let be author and dash dash main to indicate that I want to use the latest, uh, main branch of Rails, but not, uh, the latest stable release. So, um, now I'm generating the application and, uh, let's open it. So cd o code, and if I go to the gym file, I see that I'm using the latest version of, uh, rail. So the branch is, uh, main, uh, I will say gi, the at all GI com. Main message, create app. And now I'm going to generate this, uh, a scaffold, uh, to have one page that requires authentication and one page that does not require authentication. So I will say rails generate actually not discovered, but a controller, let's say controller, uh, it'll be like home controller and there will be an index action. And the dashboard action bo, or, yeah. So index will not require authentication and dashboard will require authentication. Let's create this, uh, uh, controller. Let's, uh, go to our application, go to our roots. The route will lead to home index, and I will get the dashboard to, uh, home dashboard. So this phase when I start the rail server and go to local host, I have home index open by default, and I also have slash dashboard available. Let's add these route to our layout. So I will go to application html dot, er b, and above the body somewhere, I will say link to home route path and link to dashboard, dashboard path. Okay, so here I have this to links and both pages are accessible to anybody. Let's save our changes. For now, I will say, uh, GI at all, gi commit message, uh, scuff, oh no, uh, home controller. Okay. And now let's, uh, actually add this, uh, authentication. So if we go to the usage docs, we see bin rail generate sessions, and uh, let's run this generator and see what it gives us. So it, uh, creates couple of migrations. Let's go and have a look. In DP Migrate, we create a user model that has an email address and the password, uh, session. A user can have multiple sessions, and in the session, the, the IP address and user agent. So we can know that the user is logged in, uh, on a Mac, uh, computer from, uh, a specific browser in a specific location. Uh, and the user can have multiple sessions. That's cool. Then, uh, in our models, we create a current, uh, model where we'll have current session and current user available. We create a session so user can have multiple sessions, and we also create, uh, we update our route. We add resources, sessions and resources. Sessions is linked to the sessions, uh, controller. Here it is, and in the sessions controller. So the new actions should be available to all unauthenticated users. Then, uh, the create action to sign in the destroy action to sign out. And we also have the straight limiting added by, added by default. This is also a new rails, uh, feature. And, uh, allow of unauthenticated access means that, uh, users that are not logged should be able to access the sessions controller. And this is defined. Let's see where this is defined in the authentication concern. So in our application controller, we include this authentication concern. And this is kind of the heart of, uh, the code around authentication added by this, uh, pull request. So, uh, we have a helper to check whether the user is authenticated or not. We can, uh, require authentication. We can, uh, skip, uh, requiring authentication. We can, uh, uh, sign in and sign out. All this, uh, code or the hot of this code is in this authentication concern. So here we have the create method, we have start new user session. It is also defined in this authentication concern. And uh, interestingly, we store the information about the current session in, uh, permanent cookies. So this is a good approach. It's better to store information about the, uh, currently sent end user in the, uh, cookies, but not in the session. Okay, let's try running our application and see how it works Out of the box, let's say rail server, we need to run the migrations. Okay? And yeah, I'm related to sessions new. So at the moment, any page within any page requires, uh, uh, being sent in by it. So, because in this authentication concern, we have this before action require authentication. So it's the same as adding it inside our application controller, 'cause it includes this authentication. So as of now, by default, uh, within any patient, our application requires authentication. Let's skip requiring authentication for our home controller. Uh, yeah, before doing anything else, that's just save our changes. I'll say, uh, Git, add all Git, commit main, uh, generate authentication. Okay, yeah. Now let's make, uh, the homepage accessible for not logged in users. Uh, to do this, I will go to this authentication concern and we, uh, have this, uh, helper allow unauthenticated access. So I will add this to our home controller. So allow authenticated access only index. Let's, uh, refresh. And you see home index is accessible for unauthenticated users. And if I go to the dashboard page, I see the sign in info on the screen. Okay, this is, uh, uh, good, let's try signing in. Let me try, uh, full@bar.com. And, uh, it says to another email passport. Well, I don't have any users, uh, available in the app yet. And actually this, uh, uh, basic sessions generated, it doesn't handle, uh, registrations. It only session handles authentication for existing users. So at the moment, I cannot, uh, send in if I don't have an user. So I will create a user in the console. I will say user dot, create email address will be this, and password will be the same. Okay, now let me try signing in. Will it work? Okay, yeah. I don't have the server running, So I'm signing in and, uh, it must have worked because now I have the home dashboard page accessible. Let's display the information about the current user and sign out link. So I will go back to our application html, uh, B and, uh, say, uh, if authenticated, again, authenticated is, uh, a helper defined in this authentication module. So if we are authenticated, I will display current session. Let's, uh, try this. So we have the current session. We can display the current user email address, and we can also display a link to sign out. So actually it's going to be not a link, but a button button to, uh, sign out, session off and method delete. I think it's delete. Okay, it says undefined method, destroy for nil class. This, uh, happens because, uh, there seems to be a bug in this, uh, pull request, uh, by, uh, the hh, uh, that destroy methods should be accessible only for signed end users. But now, uh, we don't have a user defined and we're trying to access the destroy methods. So I will say, uh, allow only think dedicated access only to the new and to the create actions. So destroy actions should be authenticated to access. Let's try, uh, sign in again. Okay, yeah, I seem to be signed in. I click on sign out and go into the dashboard page. I need to put my login, uh, information once again to be able to sign in. So I did manage to sign out. Let's, uh, try and scan. Signing out seems to work. Let's add some, uh, error messages. So I will go back to this authentication concern. I will go to, uh, request authentication and say, uh, alert, uh, sign in to continue. So now when visiting our dashboard page, I get this error signed into continue, and then signing out. Let's also display a success message that the user has signed out. So, uh, notice signed out, let's, uh, try once again Signed out. And yeah, I don't have the notice visible because I don't have, uh, flash, uh, in our application. H ml B, so I will say equals notice and equals alert. So again, let's try to sign in. Uh, I don't have the messages visible. So, uh, let's try again. Now I'm going to try to send in, I will also add the, some sort of flash message to the successful send in. So, uh, notice send in, yeah, let's, uh, put the notices on another line, the flash messages. Okay, so I'm going to dashboard. I'm signing out. I see the send out message. I'm going to sign in. I see the send in message. Okay, this looks good. We've added some, uh, flash messages for our sessions controller. Now let's, uh, try going to our homepage. And you see if we go to the homepage, we actually don't see the information about the current user. And this is, uh, a bit strange. Why is it? So? Because, um, the home controller, we allow unauthenticated access for index and, uh, allow unauthenticated access. Skips require authentication and require authentication. Has this resume session team. So we are not setting the current session at all for our home controller index action at the moment. And that's not very nice because we want to know on this page that the, there is a signed end user and, uh, let him sign out. We don't want to make the end user visible on only on the pages where he is sent in. So, uh, I'm going to set resume session in the home controller for this user. So, uh, I will say before action resume session only index. And now when I am on the homepage as, uh, sending user, I still see that I'm sent in, I will sign out, I'm going to the homepage. I still have the homepage accessible. Okay, this looks, uh, fine. And, uh, yeah, I think that's, uh, mostly it, uh, on top I would, uh, also recommend adding the, or updating your tests to work well, uh, with this authentication methods. So let's try running our test rails test And let's open our home controller test. So, uh, this is going to be Route U RL response success, and this would be dashboard URL. Okay. And, uh, well, I tried to get the, uh, dashboard path, but I was redirected to sessions new. So this is, uh, uh, good. Uh, I wasn't let to access the dashboard URL, but uh, I need to update the test to make it a success. So let's say, uh, assert redirected to new session URL. This is good. Now let's, uh, post, uh, session UL uh, email password. Uh, let's create a user for this. So I would say user dot create email address would be full@bar.com. Password would be, yeah, let's say password. Now I'm going to say post, uh, session url, email address full@bar.com. Password, password assert to response. Uh, success. Let's see if this works. Okay, uh, it was a direct, so let's say assert, redirected to dashboard, URL. And, uh, let's, uh, yeah, let's say follow, redirect And assert response success. This is good. Now let's also test signing out. So let's say, uh, delete session, URL. Uh, and again, let's get the dashboard URL, and it should, uh, direct us to the signin path. Uh, yeah, I made a small typo, but yes, this is basically it. So, uh, we have tested the unauthenticated access. We have tested the authenticated access and, uh, signing out, uh, uh, for this dashboard path. And that's, uh, basically it. I think, uh, this, uh, addition is going to work really nice for new ribbon rails applications. And, uh, I'm sure this code will be improved and the some bugs will be fixed and it'll be more mature by the time Ribbon Rails eight is uh, released. So I'm super excited about this new, uh, authentication generated in ribbon rails. See you in the next one.
1