 OK. Ready for the next talk, then? This is Federico Fraenguele, who's a C++ and Python developer at Evernove. And he's going to talk about how to make a full-fledged REST API with Django and OAuth 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 OAuth 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 allows the users to track the time they spend on their activities. And at the beginning, at first, 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 seeing the times, they are changing. And what has changed? Actually, front-end development has changed a lot. Sorry. Today, we have a lot of web front-end frameworks. And that allows you to create amazing front-end 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. 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 front-end web front-end application. Then the Android project, the IIS project, and the desktop application for the old desktops. And moreover, there are third-party services that wants 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 back-end application? What's in the back-end application? There is a service that exposes 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 spends on an activity or a task. And these are the end points 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 are a slash API slash activities. If you send a request, you get back a list of the available activities. To create the end point, 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 frameworks. 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 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 end points. 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 end points because you get a lot of results. And also, you want, maybe, to handle response and requests for marketing to support, for example, JSON, XML, YAML. So this is a lot of stuff, but you just keep calm and use Django REST framework because Django REST 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 401, 403, sorry, and the default renderer and default parser for the formatting, for the format. Well, to create the end point, you can use the API view-based class provided by Django REST framework, which allows you to add some code to the handler meters. And this class, this base class, will use the settings. We can see here to realize, to create an end point 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 have to repeat this code, 44 end points. But you can't avoid to write this code using the generic class base view provided by Django REST 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 Browsable API provided by Django REST 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 wants to access your user's data. So you need some authorization engine behind. If you don't have this authorization engine, these are the problems you are 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 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 OAuth2 authorization framework. So how does it work? And I want to explain how it works using this simple use case. So imagine that 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 OAuth2 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 OAuth2 authorization framework defines 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 entity 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, 0.2, and 0.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 OAuth2. 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 toolkit package. And now I want to show you how it works. So these are the steps. We are going to de-authorization. First, we are going to create a developer application. Then 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 details from the OAuth2 framework. Anyway, I got my Songify application ready. Here it is. So we can just use this one to step one. The Songify 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. OK. Of course, this should be the URL of the client application. So Songify.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 the 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 are to support Alt1. Maybe Alt support for the OpenAD Connector RFC, which I 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? First, thank you for your talk. My question is, can we use the same framework to post tweets on Twitter? No, Django Toolkit actually is the implementation of the server side part of the 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? Like, can you separate out the authorization part? Actually, 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, so just one quick question. So if you want to expose your API differently, your resources differently from the actual model definition, can you simply handle that in the serializer class so you don't have to use the Django or AM? Yeah, the model serializer. Yes, of course. You just use serializer. If your data is, for example, on MongoDB, you just write your, you just use the serializer-based class to write your own serializer. And it just works. You have to write some more code. But it works. It is OK. OK, thanks. You're welcome. Hello. Hi. Thanks for your talk. What are you using for object ownership? Sorry? Object ownership. So how do you say this object belongs to this user? And I only showed this request coming from this user. Oh, well, this is object-level permission. But you are using any component for that? We are just filtering the query set, looking at the, actually, OK, sometimes we can get back, which is the user bound to the token, OK? And with the user instance, you can filter the query set. This is a solution, really simple solution. No problem. Any more questions? OK, thank you very much. Thank you.