How to make a full fledged REST API with Django OAuth Toolkit
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Frenguelli, Federico
synasius - How to make a full fledged REST API with Django OAuth Toolkit World is going mobile and the need of a backend talking with your apps is getting more and more important. What if I told you writing REST APIs in Python is so easy you don’t need to be a backend expert? Take generous tablespoons of Django, mix thoroughly with Django REST Framework and dust with Django OAuth Toolkit to bake the perfect API in minutes.
 Okay. Ready for the next talk, then? This is Federico Fraenguieli, who's a C++ in Python developer at Evernove, and he's going to talk about how to make a full-fledged REST API with Django and Oth Toolkit. So, over to you. Hi, everyone. So, the goal of this talk is to show you how to create a REST API protected with Oth Tool. But first, I want to tell you how you should know how to do it. And I want to tell you a story. So, let me introduce you to this small and simple application, the Time Tracker, which is, of course, a web application that tracks the... allows the users to track the time they spend on their activities. And at the beginning, at first, I had... I had to choose to pick one tool, which was Django, and they had one single big project, and I deployed it once, and everything was fine, more or less. But as he used to see, the times they are changing. And what has changed? Actually, what Frontend development has changed a lot. Sorry. Today, we have a lot of web frontend frameworks, and that allows you to create amazing frontend applications. And they have their own development tools to build, to test, and to run the application. And so they are completely separate applications. And I also had to support multiple devices, which means to support different browsers and different platforms. But I should also take care of the native applications. So, I ended up with a lot of projects. I had a Time Tracker backend, a Time Tracker web, which is the frontend application, and the Android project, the IIS project, and the desktop application for the old desktops. And, moreover, there are third-party services that want to connect with my Time Tracker application. They want to send me data. They want to read data from my Time Tracker applications. So, what happens in the backend application? What's in the backend application? There is a service that exposed an amazing and reliable REST API. And this is the recipe. Django, Django REST framework, and Django of Toolkit. These are the models. They are really, really simple. There is the activity and the time entry, which is the model that allows us to track the user, the time that a user spent on an activity or a task. And these are the endpoints that I want to create. Yeah, on the mouse left column, the URL, the HTTP method supported, and the semantic meaning of each method. So, for example, the first row, you have API slash activities. If you send a request, you get back a list of the available activities. To create the endpoint, I need to show how Django REST framework works in, I hope, in less than five minutes. So, the first thing you have to do is to serialize your data. And this is really, really straightforward in Django REST framework. You can use this base class, serializer. And this works just like Django Forms. So, you just define the fields you need and add some code to restore or create the instance of the model from its serialized representation. And then you can use, easily use the serializer and you'll get back a dictionary representation of your object. Of course, this is boilerplate code, which should be repeated for every model of your application. But you can avoid to write that code using model serializer, which allows you to just specify which is the model you are serializing. You want to serialize. Then we have to create the views, the endpoints. And what do we need? We need, of course, to respect the semantic meaning. And we should take care of the user authentication. And also we should take care of permission checks. Also, sometimes, object level permissions. Sometimes you need to paginate your endpoints because you get a lot of results. And also you want, maybe, to handle response and request formatting, to support, for example, JSON, XML, YAML. So, this is a lot of stuff. But you just keep calm and use Django as framework because Django's framework is really, has a lot of settings that allows you to customize its behavior, its default behavior. These are just small examples. The first one allows you to define which is the class that takes care of the user authentication. And then we have the default permission class. So, if you're not authenticated, you won't get anything just for 01, for 03, sorry. And the default renderer and the default parser for the formatting, for the format. Well, when you, to create the endpoints, you can use the API view-based class provided by Django as framework, which allows you to add some code to the handler meters. And this class will use, this base class will use the settings. We can see here to create, to realize, to create an endpoint with the correct behavior, with the behavior you want. And, well, the code, it is really, really easy to understand. Here we have the query set to retrieve all the activities. We serialize the query set and return the serialized response. And, of course, this is boilerplate code. So, you can, you have to repeat this code, 44 endpoints, but you can avoid to write this code using the generic class-based view provided by Django as framework. Here you just need to specify which is the base query set and the serializer class you want to use. There is also a built-in browserable API provided by Django as framework, which we are going to see at the end of the talk. So, the next step is how do you authorize client applications? I mean, your applications like the Time Tracker Android and the Time Tracker iOS, they need to be authorized to talk to the Time Tracker backend API. And also, there are third-party apps that want to access your user's data. So, you need an authorization, you need some authorization engine behind. If you don't have this authorization engine, these are the problems with your going to face. First of all, you have to store the first solution without the authorization framework as to store the user password in the application, which is not good, of course, because the application gets a full access to the user account. And if the user wants to revoke his password, it wants to revoke the access, sorry, to the application. He needs to change his password. So, also compromised apps can expose the user password and username. This is the solution, the ought to authorization framework. So, how does it work? And I want to explain how it works using this simple use case. So, imagine there is a songify, music streaming service that wants to connect with the Time Tracker application. So, their users can track their listening activities on the Time Tracker application. These are the actors. This terminology is the same used in the RFC, in the ought to RFC. And I'm just trying to translate these terms to this use case. So, the resource owner is, of course, the unit, the resource server is the Time Tracker API. And the authorization server, in this case, is the same as the resource server. And the client is the songify application. I want to explain you what the ought to authorization framework defines for flows, for authorization flows. I want to show you how one of these flows work. This is the most popular one, the authorization code flow. So, the first step is when the client registers with the authorization server, and the authorization server provides a client, provides a client ID and a client secret. The client, of course, is the songify application. So, there is someone at songify that, for example, goes to developer.timetracker.com, add developer application, and it gets back a client ID and a client secret key. The second step is when the songify application redirects the user to the Time Tracker application via its user agent, via its browser, for instance. And next, the Time Tracker application authenticates the user and obtains the authorization to communicate with the songify application from the user. Now, the Time Tracker application redirects the user back to the songify application with an authorization code, which is later exchanged for a token. And the token can be used by the client to authenticate requests. How to do that in Django? With Django, our toolkit, of course, which supports Django from 1.4 to 1.7, Python 2 and Python 3, and it is built on top of Outlib, which actually is a really great library. It takes care of the compliance with the RFC. We just wrote some glue code. And its integration with Django is really, really easy. You add the auto provider application to the installed apps, add our URLs to your patterns, and you can create a protected endpoint using our generic protected resource view. And here you have an API endpoint, which is protected with OAuth 2. Now, it comes with batteries included. So we have built in views to register developer apps and a form view for the user authorization. It is integrated with Django as framework. You just need to switch the default authentication classes with the one provided by Django, our toolkit package. And now I want to show you how it works. So these are the steps. We are going to the authorization. First, we are going to create a developer application that we are going to simulate the step when the user is redirected to the authorization endpoint. So here you can see this is one of the built-in views to register new developer applications. So you create new application. You add the name. Here you have your client ID and client secret. You can choose these are details from the OAuth 2 framework. Anyway, I got my Sangify application ready. Here it is. So we can just use this one to... Step one, the Sangify application is redirecting the user agent of the user to the authorization form. But first the user has to authenticate. And now the application is asking for my authorization. And we authorize, of course. Come on. Okay. Of course, this should be the URL of the client application. So Sangify.com, for example. Now we can take this authorization code. Just substitute the code here. And we are going to exchange the code to obtain a token. Here is the response. And this is the token. And the token can be used to create a proper request with this header, authorization bearer with token. So I just want to show you that I'm not lying. If I try to get the list of the activities, just tell me that I'm missing the authentication credential. If I use my new token, I can get back the list of the activities. And that's all. The future plans for Django, toolkit art support, alt1. Maybe alt support for the open AD connector, RFC. We really don't know. I still have to read the paper. And add no SQL storage support for the applications storage. So we need some help. And thank you. That's all. Any questions, please? Anyone? Thank you for your talk. My question is, can we use the same framework to post tweets on Twitter? Django toolkit actually is the implementation of the server side part of the alt2 specification. So if you want to send tweets to Twitter, you need a client side implementation of the alt2 RFC, the authorization framework. In your examples, the authorization server was always the same as the actual service. With your toolkit, can you make two services? Can you separate out the authorization part? We have to work to keep the resource server and the authorization server separated. But maybe you can. Actually, you have to write some more code to keep the authorization server and the resource server separated. Hi. One quick question. If you want to expose your API differently, resources differently from the actual model definition, can you handle that in the serializer class so you don't have to use the Django or the RAM? Yes, of course. If your data is, for example, in MongoDB, you just write your, you just use the serializer base class to write your own serializer. And it just works. You have to write some more code, but it works. It is okay. Okay. Thanks. You're welcome. Hello. Thanks for your talk. What are you using for object ownership? Sorry? Object ownership. How do you say this object belongs to this user and I only showed this request coming from this user? Well, this is object level permission. You are using any component for that? We are just filtering the query set looking at the, well, actually, okay. We sometimes you, we can get back, which is the user bound to the token. Okay. And with the user instance, you can filter the query set. This is a solution, really simple solution. Yeah. No problem. Any more questions? Okay. Thank you very much. Thank you. Yeah.
 Okay. Ready for the next talk, then? This is Federico Fraenguieli, who's a C++ in Python  developer at Evernove, and he's going to talk about how to make a full-fledged REST API  with Django and Oth Toolkit. So, over to you.  Hi, everyone. So, the goal of this talk is to show you how to create a REST API protected  with Oth Tool. But first, I want to tell you how you should know how to do it. And I want  to tell you a story. So, let me introduce you to this small and simple application, the  Time Tracker, which is, of course, a web application that tracks the... allows the users to track  the time they spend on their activities. And at the beginning, at first, I had... I had  to choose to pick one tool, which was Django, and they had one single big project, and I  deployed it once, and everything was fine, more or less. But as he used to see, the times  they are changing. And what has changed? Actually, what Frontend development has changed  a lot. Sorry. Today, we have a lot of web frontend frameworks, and that allows you to  create amazing frontend applications. And they have their own development tools to build,  to test, and to run the application. And so they are completely separate applications.  And I also had to support multiple devices, which means to support different browsers  and different platforms. But I should also take care of the native applications. So,  I ended up with a lot of projects. I had a Time Tracker backend, a Time Tracker web,  which is the frontend application, and the Android project, the IIS project, and the  desktop application for the old desktops. And, moreover, there are third-party services  that want to connect with my Time Tracker application. They want to send me data. They  want to read data from my Time Tracker applications. So, what happens in the backend application?  What's in the backend application? There is a service that exposed an amazing and reliable  REST API. And this is the recipe. Django, Django REST framework, and Django of Toolkit.  These are the models. They are really, really simple. There is the activity and the time  entry, which is the model that allows us to track the user, the time that a user spent  on an activity or a task. And these are the endpoints that I want to create. Yeah, on  the mouse left column, the URL, the HTTP method supported, and the semantic meaning of each  method. So, for example, the first row, you have API slash activities. If you send a request,  you get back a list of the available activities. To create the endpoint, I need to show how  Django REST framework works in, I hope, in less than five minutes. So, the first thing  you have to do is to serialize your data. And this is really, really straightforward  in Django REST framework. You can use this base class, serializer. And this works just  like Django Forms. So, you just define the fields you need and add some code to restore  or create the instance of the model from its serialized representation. And then you can  use, easily use the serializer and you'll get back a dictionary representation of your  object. Of course, this is boilerplate code, which should be repeated for every model of  your application. But you can avoid to write that code using model serializer, which allows  you to just specify which is the model you are serializing. You want to serialize. Then  we have to create the views, the endpoints. And what do we need? We need, of course, to  respect the semantic meaning. And we should take care of the user authentication. And  also we should take care of permission checks. Also, sometimes, object level permissions.  Sometimes you need to paginate your endpoints because you get a lot of results. And also  you want, maybe, to handle response and request formatting, to support, for example, JSON,  XML, YAML. So, this is a lot of stuff. But you just keep calm and use Django as framework  because Django's framework is really, has a lot of settings that allows you to customize  its behavior, its default behavior. These are just small examples. The first one allows  you to define which is the class that takes care of the user authentication. And then  we have the default permission class. So, if you're not authenticated, you won't get  anything just for 01, for 03, sorry. And the default renderer and the default parser for  the formatting, for the format. Well, when you, to create the endpoints, you can use  the API view-based class provided by Django as framework, which allows you to add some  code to the handler meters. And this class will use, this base class will use the settings.  We can see here to create, to realize, to create an endpoint with the correct behavior,  with the behavior you want. And, well, the code, it is really, really easy to understand.  Here we have the query set to retrieve all the activities. We serialize the query set  and return the serialized response. And, of course, this is boilerplate code. So, you  can, you have to repeat this code, 44 endpoints, but you can avoid to write this code using  the generic class-based view provided by Django as framework. Here you just need to specify  which is the base query set and the serializer class you want to use. There is also a built-in  browserable API provided by Django as framework, which we are going to see at the end of the  talk. So, the next step is how do you authorize client applications? I mean, your applications  like the Time Tracker Android and the Time Tracker iOS, they need to be authorized to  talk to the Time Tracker backend API. And also, there are third-party apps that want  to access your user's data. So, you need an authorization, you need some authorization  engine behind. If you don't have this authorization engine, these are the problems with your  going to face. First of all, you have to store the first solution without the authorization  framework as to store the user password in the application, which is not good, of course,  because the application gets a full access to the user account. And if the user wants  to revoke his password, it wants to revoke the access, sorry, to the application. He  needs to change his password. So, also compromised apps can expose the user password and username.  This is the solution, the ought to authorization framework. So, how does it work? And I want  to explain how it works using this simple use case. So, imagine there is a songify, music  streaming service that wants to connect with the Time Tracker application. So, their users  can track their listening activities on the Time Tracker application. These are the actors.  This terminology is the same used in the RFC, in the ought to RFC. And I'm just trying to  translate these terms to this use case. So, the resource owner is, of course, the unit,  the resource server is the Time Tracker API. And the authorization server, in this case,  is the same as the resource server. And the client is the songify application. I want  to explain you what the ought to authorization framework defines for flows, for authorization  flows. I want to show you how one of these flows work. This is the most popular one,  the authorization code flow. So, the first step is when the client registers with the  authorization server, and the authorization server provides a client, provides a client  ID and a client secret. The client, of course, is the songify application. So, there is someone  at songify that, for example, goes to developer.timetracker.com, add developer application, and it gets back  a client ID and a client secret key. The second step is when the songify application  redirects the user to the Time Tracker application via its user agent, via its browser, for  instance. And next, the Time Tracker application authenticates the user and obtains the authorization  to communicate with the songify application from the user. Now, the Time Tracker application  redirects the user back to the songify application with an authorization code, which is later  exchanged for a token. And the token can be used by the client to authenticate requests.  How to do that in Django? With Django, our toolkit, of course, which supports Django  from 1.4 to 1.7, Python 2 and Python 3, and it is built on top of Outlib, which actually  is a really great library. It takes care of the compliance with the RFC. We just wrote  some glue code. And its integration with Django is really, really easy. You add the  auto provider application to the installed apps, add our URLs to your patterns, and you  can create a protected endpoint using our generic protected resource view. And here you  have an API endpoint, which is protected with OAuth 2. Now, it comes with batteries included.  So we have built in views to register developer apps and a form view for the user authorization.  It is integrated with Django as framework. You just need to switch the default authentication  classes with the one provided by Django, our toolkit package. And now I want to show you  how it works. So these are the steps. We are going to the authorization. First, we are  going to create a developer application that we are going to simulate the step when the  user is redirected to the authorization endpoint. So here you can see this is one of the built-in  views to register new developer applications. So you create new application. You add the  name. Here you have your client ID and client secret. You can choose these are details from  the OAuth 2 framework. Anyway, I got my Sangify application ready. Here it is. So we can just  use this one to... Step one, the Sangify application is redirecting the user agent of the user  to the authorization form. But first the user has to authenticate. And now the application  is asking for my authorization. And we authorize, of course. Come on. Okay. Of course, this  should be the URL of the client application. So Sangify.com, for example. Now we can take  this authorization code. Just substitute the code here. And we are going to exchange the  code to obtain a token. Here is the response. And this is the token. And the token can  be used to create a proper request with this header, authorization bearer with token. So  I just want to show you that I'm not lying. If I try to get the list of the activities,  just tell me that I'm missing the authentication credential. If I use my new token, I can get  back the list of the activities. And that's all. The future plans for Django, toolkit  art support, alt1. Maybe alt support for the open AD connector, RFC. We really don't know.  I still have to read the paper. And add no SQL storage support for the applications  storage. So we need some help. And thank you. That's all.  Any questions, please? Anyone? Thank you for your talk. My question is, can we use the  same framework to post tweets on Twitter? Django toolkit actually is the implementation  of the server side part of the alt2 specification. So if you want to send tweets to Twitter,  you need a client side implementation of the alt2 RFC, the authorization framework.  In your examples, the authorization server was always the same as the actual service.  With your toolkit, can you make two services? Can you separate out the authorization part?  We have to work to keep the resource server and the authorization server separated. But  maybe you can. Actually, you have to write some more code to keep the authorization server  and the resource server separated. Hi.  One quick question. If you want to expose your API differently, resources differently  from the actual model definition, can you handle that in the serializer class so you  don't have to use the Django or the RAM? Yes, of course. If your data is, for example,  in MongoDB, you just write your, you just use the serializer base class to write your  own serializer. And it just works. You have to write some more code, but it works. It  is okay. Okay. Thanks.  You're welcome. Hello. Thanks for your talk. What are you using for object ownership?  Sorry? Object ownership. How do you say this object belongs to this user and I only showed  this request coming from this user? Well, this is object level permission.  You are using any component for that? We are just filtering the query set looking at the,  well, actually, okay. We sometimes you, we can get back, which is the user bound to the  token. Okay. And with the user instance, you can filter the query set. This is a solution,  really simple solution. Yeah.  No problem. Any more questions? Okay. Thank you very much.  Thank you.  Yeah.
synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_0_1871.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_1872_1943.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_1944_7199.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_7200_7451.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_7452_7499.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_7500_7559.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_7560_7631.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_7632_7703.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_7704_9779.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_9780_9875.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_9876_10187.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_10188_10559.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_10560_11063.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_11064_11255.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_11256_12059.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_12060_15779.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_15780_15935.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_15936_16187.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_16188_17351.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_17352_17603.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_17604_18071.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_18072_19163.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_19164_19331.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_19332_19415.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_19416_19943.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_19944_20003.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_20004_21443.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_21444_23819.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_23820_24383.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_24384_25571.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_25572_29411.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_29412_29459.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_29460_29627.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_29628_29687.png synasius_-_How_to_make_a_full_fledged_REST_API_with_Django_OAuth_Toolkit_29688_35952.png