4.4 Authorizing Users for Admin Tasks
The reason we've been doing all this work to authenticate users is that we want to provide the ability to perform some admin tasks within our app. But of course, to do so, we need to authorize our users.
1.Introduction2 lessons, 12:37
1.2What You Need11:04
2.Getting Started3 lessons, 34:33
2.1Creating the App10:06
2.2Creating the Post Component07:53
3.Fetching Other Data3 lessons, 27:16
3.2Pulling in Categories09:53
4.Authentication4 lessons, 47:23
4.1Getting Ready for User Auth15:52
4.2Configuring JWT in WordPress10:49
4.4Authorizing Users for Admin Tasks09:16
5.Conclusion1 lesson, 01:14
4.4 Authorizing Users for Admin Tasks
The final thing we need to do is actually delete a post. So we are going to finish our application in this lesson. And let's just jump right in, we'll start with our API. Now I had thought about to where I want to put things and I want to keep all of the authentication. At least as far as the token, checking to see if the user is authenticated inside of the auth file. So when it comes to deleting a post, what we're going to do is write a method inside of our API. Simply called deletePost, we're going to pass it to the token. That way nothing else in our application has to worry about the token. The code inside of our auth file, and inside of the delete post component that we're going to write, is going to supply that. So we need the token in order to prove that we are authenticated to delete a post. That we need the ID of the post to delete, and the code for this is going to look very similar to the authenticate. The first thing that we need to change however is the header, we don't need the content title we do need the authorization. So there is that, this is going to be set to our bearer token, so let's say bearer, and then we will bring in our token there. But that's the only header that we need. Now we are not be using the auth URL, in this case we are going to be using the base URL. We are going to hit the posts endpoint and we also need to include our ID. So we will have that. The method is not going to be posted as delete. We do not have a body so we can get rid of that but everything else is going to be okay. If there is an error we're going to throw an error so we can catch that inside of our component that we write and then we will return json. I'm assuming we will get a json payload because whenever we played around with the authentication a few lessons ago, we saw that even updating a post gave us a JSON payload. So going to assume that we're going to get JSON. We're not going to really do anything with it but we will have that capability if we wanted to. Now as far as our deletePost component that we are going to write, we can approach this in several different ways. And probably the best approach for this would be to just handle the click event on our link, but instead we're going to make it a little bit complex. And I'm going to use the login form component as a basis, because I want to rely upon the same type of functionality, and that's, we are going to track this redirect to inner state. So let's, first of all, call this DeletePost and as I said, it's probably better to just handle a click event, make the request, and do whatever we need to do. But this is also going to work as well. So as far as the state is concerned, once again we're just going to be working with that redirect too. And instead of a login method, we're going to call this deletepost as well. Just so that we can have a little bit of confusion between our deletePost methods. So as far as this method is concerned, we want to use our API. So let's say let api = new Api. We're going to call our deletePost method. We want to pass in our token, so we're going to call our store function. We're going to retrieve the ID and that is this.props.match.params.id. If that is correct, then I'm gonna pat myself on the back because I remembered that. So as far as the then handler, we're going to have an object because that is going to be JSON, but we're not going to do anything with JSON. Instead, we are going to say this.setState. And we are going to set the state of our redirectTo, that's going to be true. And if we get an error, let's add a catch error. I don't know what we want to do in this case, so we'll just tack on a TODO handle error. So now we need to go to the render method. We don't need this handleChange, so let's get rid of that. Now we want to check to see if the user is authenticated because if they aren't, then we want to redirect them to the login page. So we'll use auth is authenticated, and actually we need to check if that is not authenticated. Then we will return and we will redirect to the login page. So there is that. Now, let me first of all say this, this is going to work, however, if we had a lot of routes that relied upon authentication what we could do is write Is a custom route component. We would actually extend route, and we could call it off route, or something like that. And inside of our custom routes we can check to see if the user is authenticated, and if they weren't, we could automatically redirect them. That would save us time if we were going to write a lot of authorization required routes. We're not going to in this case, so we're just going to leave this as is. So if they are not authenticated we are going to redirect them to the login page. However if we have this redirect too, that means that our delete request worked and we want to redirect back to our list of posts. Otherwise, let's just return null. I don't really know what would be the best thing to be there, but we'll just return null and we need to export this DeletePost because DeletePost is going to be handling a route. So let's go to app and let's put this Route path, we need to put this above our existing route. So we'll say post/delete and that is why and then we'll have our id the component is going to be delete post which we need to import. So we will do that there and I think we're ready. Only time is going to tell. So let's pull up the developer tools, so we can see what else is going on. Let's ensure that our routes will still work. They do. Let's refresh just to make sure. And okay, and everything looks like it's working. Let's delete this Hello, Auth! So we're going to click on Delete Post. Hopefully, well, something happened. Whether or not it was what we wanted remains to be seen. So I don't see anything. We can go back to our list. Okay, so something obviously didn't work so let's see what that was. We do have our route, we are importing DeletePost. Are we exporting delete post? Yes we are. And there it is, we need to call deletePost. We're not calling delete post anywhere, let's do that. Now, let's make sure our routes work, they do. Let's delete Hello Auth! And we got an error, what was that error for? deletePost is not defined. It helps if you type this in front of it. So third time's a charm, let's go back. Because I don't want to save this on a delete route. Let's go, Delete Post and there we go, we just deleted a post. It is gone and if we go to localhost and then wp-admin, is that it? Something like that, we'll find out. We'll log in, we'll just make sure that it is indeed gone, it is. So we just deleted a post. That's awesome, that worked. And we deleted the post that we intended to delete, so everything there is good to go. So we now have a working application. We are displaying information, which is probably the most important thing about a headless WordPress application. But we also incorporated authentication so that we could log in and perform some administrative tasks like deleting a post.