Basics of GraphQL in Ruby on Rails - Authentication, Authorisation, and Access Control | Alex Deva | Skillshare

Basics of GraphQL in Ruby on Rails - Authentication, Authorisation, and Access Control

Alex Deva

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
9 Lessons (20m)
    • 1. What we'll learn

      1:30
    • 2. How authentication and authorisation work

      1:38
    • 3. Login (authentication)

      4:26
    • 4. Authorisation

      3:17
    • 5. Logout

      1:24
    • 6. Access control

      0:48
    • 7. Visibility, Accessibility, Authorisation

      4:13
    • 8. Assignment 3

      0:36
    • 9. Conclusion

      2:07

About This Class

This course teaches the basics of using GraphQL in a Rails application. GraphQL is a query language invented by Facebook in 2012, and made open source in 2015. While it has certain clear advantages over REST, it also has a somewhat steeper learning curve.

Structured in a simple and accessible manner, these lectures will help you get on your way to using GraphQL to circulate data between back-end and front-end applications.

After an introductory class, in the next class we will learn about reading data; in the third, about changing data; and the slightly more advanced fourth class is about protecting data.

This is the fourth and last class: Authorisation, Authentication, and Access Control.

The last lecture in this class is the conclusion of the whole course.

Transcripts

1. What we'll learn: in this slightly more advanced section of our basic course, we're going to learn about Triple A Triple A stands for authentication authorization on access control. We're going to talk about authentication, which is the same as Le Guin. And for that we're going to create a user model that we can authenticate against on. We're going to create a session model on creating. Ah, by authentication, we mean creating a session object and then sending the session key to the front. And after a successful log in, then we're going to talk about authorization, which is allowing the front and access to specific graphical queries. And we'll go. We're going to implement that by having the front and send as the session key together with all the private graphic, your requests. And then we're going to talk about access control, which is which is there is allowed to do what on will implement a very simple way to do that. And then we're going to talk about D authentication, which means losing the credentials in the application, which is the same as logging out, and to do that will seem to delete the corresponding session record with you with a mutation, and then when it comes to use a registration, we won't be doing a lot of that because we've already learned how to create records in this case, users using mutations. And that's all we're going to cover in this section, and I hope you have a good time learning good luck. 2. How authentication and authorisation work: So let's take a closer look on how authentication and authorization work. Let's consider the scenario where we have front and application on the back and application on the back and application uses graphic you'll to communicate. Ah, in order to authenticate the user, we would typically have a form in the front and asking for email or some other kind of user name and a password and authentication request carrying these two things would be sent to the backhand. Ah user would be authenticated, found unauthenticated, based on the email of the user name on. If the authentication succeeds, then a session would be generated, a session object would be created, and a session key belonging to that session object would be returned as the answer to the authentication to the front end. Now the front end's responsibility would be to store that session key and then to use it for every subsequent request. Graphical request that the front and makes the back. And so for every query that the front and then makes it has to attach the session key typically as an http header to the back and now the back end. For every graphical query that it receives has toe authorize that query based on the session key, which is to say, retrieve the key from the http headers and see if there's a valid session that has the key and if so, if these tests pass, only then would it prepare the data and return the data as a quick response. That's the basics of how it's supposed to function. Now let's try and put it into practice. 3. Login (authentication): put all that in practice, we're going to create a user model and we're going to create a session model on. We're going to make a query to log in the user and see what happens. First of all, I'm going to go to gym file on UN command. This line that uses be crypt Onda. Then I can create the user model. You know, Ruby, mine is going to tell rails to create migration on the model and everything quickly around the migration. There we go on now will create a session model. The session will have a user 80 on a key, which would be a strength when creating a session. It might be a good idea to add a data base level constraint against empty keys so that you can't ever have a session that doesn't have a key because that might be a security risk. Right? All on your tables are not created. We're going to add a closest Says has secure possible. I'm going t o let the user have sessions and a session in turn, belongs to a user. Right? With this all in place, we can finally get back to graft. You will now what we want to do now is to create a log inquiry or logon field, a road field. Ah, and that will match against a given email in a password. And if it can successfully authenticate a user by that email and password, it should create a session and return the session key. In order to do that, there's one last thing that we need to do and to make it easier. When we create a session every time a session is safe, we can add a hook to generate a session key, which is just going to be reasonably long, random strength. So now back to the, uh, queries back to graft you well, and we're going to write the log inquiry, which is going to be relatively straightforward. It's going to be called Log in and is going to return a string which will be the session key or kneel in case the authentication fails and, as discussed is going to be is going to receive two arguments on email and password. To resolve this field, we're going to write a method that tries to authenticate the user. And if a user was found by that email address and it authenticates. Then we have a user so we can create a session for him or her on. We can just return the key to that session. Otherwise, um, the matter will just return Neil really quickly from the console. So we're creating a user that is a super at me and the decrypt Jermell automatically created possible to just for him, that is encoded on which we can authenticate against know. Now all we need to do is restarting the application because we've changed the gems. Okay, it's rebooted. And if you try to log in, we'll get no, because we try the wrong password. If it right with the right password, then we'll get a session key and a session record will have been created in the database, as we can see in the in the server locks. And this is how we log in a user using graphical. Now the front end is responsible to store the session key and carried around for every request for the same user. And ah, the way to do that will be explained in the next lecture 4. Authorisation: So now we have a user that has many sessions on. We have sessions that beyond to user. And every time a session is created, key is generated randomly for it. And when he was a tryst to log in with an email and a passport Ah, if the year authentication succeeds, then a user session is created and the key is returned precisely as happened here. Now the question is, how will the front and pass this session key around for every request for for the same locked in user? Well, the easiest answer lies in the http headers on DA. It's relatively easy for a request. Teoh have initially be header and we can simulate that with graphic. You will if we add here ahead of called authorization with the value of the session key that we've just received now all the requests that will come from ah, the assistance of graphic UAL will carry around that header. Now how do we care about that header in rail? Seen in our app where the answer again is in a graphical controller where the were all the HD requests land and some place here We can look in that in those headers and try to find a session by the key that we've just received. And if we found a session, we might even log the other user that we looked in us if the session was found and get its user on. If that's not kneel yet the email and with a little bit of ANSI magic, we can make this a different color now. The important thing is to save the logged in user into the context, which is pretty much what the context is for on we're just going to just going to create a key here, which will have as the value what it was found in the U. S. Recession. If a session was found at all, it's easy enough to create a field query to retrieve the currently logged in user. This will obviously have to return user. Um, in the form of a is a type which doesn't exist yet, but we'll make it soon enough on the resolver method for this field again is enough. Just take whatever is in the context so just quickly will make use a type right, and with this, we should be able to retrieve the currently locked in user. And for that get for example, the email. We don't eat variables again with the HDP Heather probably configured, we should be logged in as the only user that we have. And if we have a quick look in the log, there was a bit of ah character missing here, and there should be a square bracket so that the fancy code works on. If we repeat the query. Yes, now we'll get the email in a nice being color. So that's how we do basic authorization in graphic. You well using unauthorized heather. 5. Logout: in this lecture will talk about locking out well. Looking out means removing the current session. It's as easy as that. But what is the current session? We could remove all the sessions that the current user has opened because we know who the current user is, and that might be its own use case. But for now, let's be specific and only remove the current session. So we have to know which one it is in order to remove it. And for that we can easily store its record I d. In the context next to the current user. Now all the red maze is to create a simple log out query. Let's try it in graft UAL. And first make sure that we are locked in on. Then if we call La Goat, which doesn't have any selectors, we're going to get a value of true. And if we tried the current user again, we're going to get a value off. No, Even though we're sending the correct header, the session doesn't exist anymore. It's been deleted as we can see in the rail slogs. The session has been deleted, so we are no longer locked in. And this is this is how easy it is to Agata user in graphical 6. Access control: the latest version of the graphic You'll Gym offers authorization at three levels. Visibility, accessibility and object authorization. Visibility control means that we can hide certain parts of our schema so that they're not visible or accessible unless certain conditions are met. If you want something to be visible but only accessible under certain terms, then we're talking about accessibility. On Finally, authorization allows us to check during the execution of a query, whether something is allowed or not. That is to say, this check is performed after the value was computed and right before it is about to be sent to the front end. All three levels are enforced in the same way as we'll see in the next lecture. 7. Visibility, Accessibility, Authorisation: So we've seen in the previous lecture that the three levels of security offered by the graphical Jim off the shelf our visibility, accessibility and authorization all of them are implemented. VR class predicates class predicated Remember from Ruby our methods to find on self and which return true or false. And these methods, predictably, are visible, accessible and authorized with question marks. So let's start with visibility. Let's add a check to not allow the use the type to be publicly visible, not even in the schema documentation. Right now, as we can check it, is visible in the schema. There it is. If we go to the user type on ad, a method class pretty good called self visible, that will always receive context as a parameter. We can say that we want this type of visible only if there's somebody locked in. So only if there's a current user in the context. If not, try again. We'll see that the user has disappeared from the recommendation, and so have all the fields which made any mention to it. If we log in, if you log in again and ah use this session, key in the head is than by reloading. We'll see the type again because now we're locked in and that is visibility. No going further. Let's make the mutation to create authors visible but inaccessible unless the user is a Subaru Adami. I changed the mutation so that it used Ah, a separate file in which I can I can define this method this class pretty good. So let's make this a mutation only accessible to super admits. So right now, if you try to create a user, I'm just going to quickly type of mutation. If we not try to create, user and author will see that it works because they user that we are locked in, as is a super admit. But if we look back to a console and change that flag on the user and would fight the same quot again will get the message that says some fields in this story are not accessible. A case in point create author. Even though the mutation is still visible documentation, we are not able to call it and finally object authorization. Let's imagine some very weird scenario in which we don't want to show author so leave in a certain part of the world. We could add this authorization check right in coordinates type that will only allow coordinates that have latitude greater than 10 degrees and a longitude smaller than 10 degrees. So, using the query, Terry, three of some author repeatedly well, sometimes get the center and other times not because the coordinates a random no. Now, this may not be idealist. Faras error messages go. The way to customize it is to define this method right in the schema definition in bookshelf scheme art dot r b. We're going to add this method. Now. The editor is much more descriptive, and we can even tell that it has to do with the coordinates. Well, as far as the Triple A features that the graphic you well, Jim has off the books, our visibility, accessibility and authorization. This is pretty much it. I'm going to attached the application as it is. Up to this point, I'm going to give you one last assignment, and then we'll jump to the conclusion at the end of the course. 8. Assignment 3: In this final installation of our homework project, we're going to add authentication, authorization and access rules. Street 1st 2 will adapt the user model by adding email and password digest to it. Andi will also create a session model. Don't forget to add the beak Ripped gym in Jena file. Then you will implement log in authentication on drug out, just as we did during the lectures. And lastly, you will please make it so that only users who have the role member are allowed to create comments. As before, I'll attach my own solution to the course. Thank you and good luck. 9. Conclusion: in these scores with learned what graphic you will actually, is how it compares to rest. We've learned about graphic well, on exploring schema documentation. We've seen how simple queries look. We've learned about queries with arguments, and we've worked with active record types. We've listed all the support, it scaler types. We've created our own custom types. We've learned about a race with change data using mutations. We've seen the gradual context object with created input types on changed data. Using query variables, we treated validation errors. And finally, we've discussed authentication on its three graphic You'll levels of implementation plus with May the back end of a block up. And that's very good. So what's next? Well, the graphic You'll Ruby gym is full of interesting goodies, such as subscriptions, while you push data into the front and using Web sockets, for example, without having to wait for the front and to ask for it. Or dynamic schemers where he changed the scheme of the data at runtime or lazy execution, where he can handle unfinished queries or ahead of time analysis, where you can see how complicated a query is before you start working with it or complexity management a similar concept where it can measure how complicated the query is multiplexing , where you serve multiple queries at once and many more. I would encourage you to visit the website of the gym, which is graphic Yuldash Ruby that orig on also the website of graphic. UAL, which is graphical dot org's Remember that back and without fronted isn't really useful. So I would encourage you to investigate various front and clients. If you're looking for an alternative to writing, Railsback ends with graphic You Well, I would suggest my own back and framework. Sorry cat, which is entirely graphic. You'll centric Andi, I believe better in many respects. And with that I'm going to tell you Thank you so much. I hope you enjoyed my course on I'll see you soon.