Transcript
Device, the most popular Ruby Rails authentication gem. If you are a URS developer, most likely you have used it. And actually in one of the annual Ribbon Rails servers, it was rated both the most liked and the most hated Ruby Gem. Now, there are lots of threads about like, uh, uh, is device cool? Should you use device or not? Should you, can you use device correctly with rail seven? And I think all the criticism for device, uh, mostly boils down to a couple of things. First of all, it feels too much like magic. So you just run the gem, run the, uh, installation, and you have authentication working in your application without actually adding a lot of code into your app. So you don't have to dive deep into how the authentication, uh, uh, registrations, uh, work. It just works so too much magic. And the second is that it can be a bit hard to extend device out of the default, uh, flows. So for example, if you want to add to factor authentication, then you need to override the default device, uh, controllers quite the, a lot and it feels a bit hacky. Now, there are different other alternative approaches to authentication. There are lots of rubber jams. There are external services like All Zero. Actually, in one of my applications that I inherited, the, they were using the old zero for authentication instead of a ruby gem. And it was a big pain to maintain it and to just make it work good enough rails. I don't recommend using external, uh, authentication if you have so many wonderful Ruby Gems now Rails eight ships with its own authentication generator that I have covered in a couple of previous videos. But unfortunately, uh, the authentication generator is not, uh, good enough for production yet, in my opinion. So, uh, there is still a lot that needs to be added for this moment. Uh, you can just, uh, sign in as an, uh, existing, uh, user by default. You don't even have registrations and, well, that's what my second video was about, adding registrations to the authentication generator. You would also want to add confirmations. You would want to add, uh, uh, the possibility to change, uh, uh, the email. For example. Uh, you would want to add the default tests for the authentication. And it's still all like in from the default rails eight authentication generator. So it is all been developed and maybe someday it'll be a very good solution, but until, uh, yeah, and it, it's supposed to cover a lot of things that the device, uh, doesn't cover. So with this, you generate all the authentication logic into your application. So you see all the files, you can change the authentication inside your application. You get all the authentications related to files, uh, so it will not feel like magic and you can override anything you want. But again, it is, uh, still, uh, some way to go To have, uh, the whole authentication logic inside this, uh, authentication generator. And for now, I think the best alternative to this authentication generator might be authentication zero by Lazaro Nickon. So the cool thing about this gem is that, uh, it is basically everything. This rails authentication generator wants to be in a mature state. So with it, you would be able to generate, uh, all the authentication, the route views, controllers, models, and the, again, it is not like measured 'cause you see all the files, it, the connections between them inside your application, you can edit them. And the the cool thing is that it has, the gem has a lot of different options, uh, out the box. So you can add two factor authentication that just adding dash dash two factor. And you don't have to find a hack bay to integrate it into like device. You can add the, uh, even basic multitenancy basic functionality to log in as another user. I think that's, uh, really cool, uh, suitable. So like you have to enter a password to view app protected page. So, uh, let's have a look how, uh, we can use authentication zero in a new Ribbon Rails application. Now here I have, uh, a new, uh, ribbon Rails application and I'm going to try to install this Gem authentication zero. So, uh, run into generator. Now let's, uh, run Rails generate authentication. And you see it generates a lot of files in, uh, my, uh, Ruby app. Let's a look at them in the Git. I think it's a comfortable way to look at what has been added to our app. So, uh, first of all, in the application control, we have this method to set the current, uh, user current session. Um, I like starting to look at it from the migrations. So let's look at the migrations. A user has an email and a password. And by default, uh, user email is not verified and a user has many sessions. So, uh, a user can be logged in, in the same, uh, uh, device from two different browsers. And this would be two different sessions and you'd be able to log out of one of the sessions, uh, uh, from another one. So you can like remotely log out from another device. This is really cool. And Rails eight authentication generator also has this feature. Now let's have a look at the roots. So we get the roots for logging in, for signing up, for changing the password, uh, for viewing, uh, where you are logged in and logging out remotely, uh, for resetting the password, for verifying your email. And you also get a basic homepage. Let's have a look. So we have a homepage where we can see the, uh, basic, uh, code for like signing in, signing out, and seeing what user you assigned in with. Uh, then again, user we use has secure password. You see how the tokens are generated for email verification for password resets. Again, the user has many sessions validations. So, uh, there's everything you wanted. You don't magically extract, uh, or outsource your authentication logic to device. You have everything in your app. And again, it is now your burden to uh, make sure that this logic, uh, is not broken by your further actions. Okay, let's, uh, run Rails, tob my and run the application. Okay, let's open local host. And you see on the new application, it gives me the send in page. 'cause uh, I have to be sent in to use the app. Let me sign up@bar.com. Okay, at list 12 characters sign up. You see I'm signed in. Uh, I can uh, go to the console and you see whenever I will signed, uh, uh, I created an account, I get an, uh, email to verify my account. So by default, my account is not verified. You can see it in the, uh, migration or in the schema. I have this user verified falls by default. Let's open it in the console, rails console user dot account. Do first you see verified false. Now, uh, by default, uh, users that did not confirm the email can access the application, but it is, uh, for you the developer to potentially limit the un verified email access to your application. You could do it as, uh, in device, either, uh, straight away, not allow unverified users to access the system or after some period of time after the user account has been created. Okay? So let's, uh, try to open the link below and, uh, verify our user. I will open in you tab. Okay, thank you for verifying your email address. I will go to the console user first. You see verified True. Okay, I'm sent in as a user. I can, uh, change my password. I can, uh, change my email and here has the school tab devices and sessions. I'm quite sure that the rails authentication generator down the road is also going to add something like, uh, this, uh, page. So, uh, I can click log out and log out from the device remote. Let me try it for the new B browser tab, local host. Okay, signed in and now I'm going to try to send out of this one remotely. You see, now I refresh. I'm sent in from two different, uh, uh, browsers. I will click log out here. Now I refresh here and you see I'm, uh, logged out. So it is wonderful. You see, I managed to remotely log out. Okay. Uh, so this is the like basic, basic authentication logic, and you can extend it, uh, with the different plugins. So there are these plugins for like, uh, uh, enabling two factor authentication, uh, tracking activities and yeah. And then we'll also maybe try multi-tenancy. So, uh, let's save our changes. Uh, add authentication zero. I will also add a link to the G. Okay? Now the cool thing and good way to learn, uh, how the generator works with and without all these plugins is trying to add them one by one and, uh, see the difference in the code generator. For example, I'm going to rerun this generator with the two factor. Let me run rail generate authentication. Two factor, okay? Uh, I get a conflict, I will say force. And uh, you see, uh, here is the diff between the initial generation and generation. If I run it together with two factor. So you see the sessions creation controller is somewhat different. We get all these, uh, controllers for uh, two factor. Uh, then a user has, uh, many recover codes and uh, the views have also been updated and the migrations are also somewhat different. And you see we have the roots for two-factor authentication. You see quite a lot of roots because, well, there are quite a lot of views involved with two factor authentication. Let's run rails to be drop, to be create, to be migrate. Okay, let's run the rail server and see how could this, uh, two factor authentication work. So lemme sign up. Okay? Okay. Now I have this, uh, tab two factor authentication. You see, I click on it and I get this whole guide to add to, to authentication. I can scan this code with my camera and, uh, well, the thing will work. So you see outta the box, you have two factor authentication. Now, again, uh, running the correct generation, uh, of all the, uh, plugins is best to do. I think when you're just creating a new application, uh, this way you will have, uh, all the lo logic that you need for your application out of the box. Uh, let's try something else. So, uh, I'm not going to save these, uh, changes. I'm going to try to add, for example, multi-tenancy. I will, again run rails. The B drop, the B create, B create, I will run rail, generate authentication, and I will say tenable and force. Okay, let's, uh, run the migrations and let's see the difference. So see, we have an account. So users belong to an account. Uh, we have a concern. We have, uh, current account and a user belongs to account. So, uh, you see with this, uh, authentication zero approach to multi-tenancy, uh, one user with one email by default belongs to one, uh, account or organization or team. And if you wanted to implement, uh, the possibility for one user to belong to multiple accounts, you would need to still do it, uh, manually. But this, uh, very, very good, uh, start now, uh, in many cases for multi-tenancy, really it is enough for just users with one email to belong to one organization. I've worked in, uh, some organizations and it was just fine. But if you're building, uh, an app, uh, like Slack or like, uh, discord where one user can be a member of multiple organizations, then you would need to add an additional layer. User, uh, has many accounts through membership, but, uh, for many cases this is just, uh, enough. So in the schema we have, uh, a table of accounts and users belong to accounts. Let's, uh, have a look at this account middleware. So it is a way to, uh, I think find the current, uh, account, uh, based on the ID in the roots, I think. Okay, well, I, uh, showed you, uh, what the jam is, how it generates different files. Uh, I invite you yourself to run each of these generators on top of the default generator as added. So like I added authentication, zero base basic without any plugins. And on top of it, you can try all the plugins, see what code it, uh, each of these plugins generates. It's a a good way for you to learn how To create all these features. Uh, Lazaro did some really good work for this. And, uh, yeah, one thing you should definitely keep in mind if you are importing all the authentication logic into your app, but not, uh, just, uh, outsourcing this work to an external library as device, it's your responsibility to manage this code. Now, uh, it is not the libraries. It is not like device. There's no more device that is in the background, authenticating all the users. You own the code inside your application and you can override it. And, uh, sometimes, uh, overriding the default path can lead to errors. So be mindful, then run out your own authentication and, uh, making changes to the defaults 'cause you can break something unintentionally. Uh, finally, I don't know whether I mentioned it, uh, uh, it, uh, the gem imports, uh, default tests, uh, for the generators. So, uh, you have broken tests for your authentication flow and this should make, uh, the possibility of errors lower. Anyway, I invite you to try out authentication zero. It is, uh, vote Rails eight authentication, wants to be in an ideal state. Thanks for watching and see you in the next one. I.
0