All right, and before we implement the longer functionality in our interceptor and as a result in our
application, let's discuss quickly why.
So when I'm trying to update some user data, if one of the barriers is missing, I'm getting back this
400, which means, well, it's a bad request.
So essentially, user either needs to add the correct value or he or she just needs to navigate to the
other page.
And then when they come back normal again, this is going to be the default value that is coming from
the database.
Hopefully, that is clear.
Now what would be other possible errors that we get?
Well, we could get five hundred, which is that generic server error, but we can also get for a one
one two four one.
Well, that is unauthorized, correct?
And here's what we need to think about if we're heading here for a one.
Should the user be in the application in the first place?
And what would be the scenario?
Well, the scenario is that, let's say, user logged in and everything is fine and dandy.
But at some point the token expired.
Wouldn't it make more sense if we get back for a one?
We actually log out the user right instead of just displaying that there's an error.
So let me showcase that I'm going to go back to my app context and I'll do the same thing like we already
did in one of the previous videos where I'm just going to comment on the token.
Now again, keep in mind what I'm trying to showcase here is the Aspire token.
I just don't want to go through the server and all that.
But the idea is going to be exactly the same way if this token is not present.
What we're going to get back is not the 400 show.
We will get the 401 and in here now, even with all the values providing all that, I'm going to get
this authentication round.
And again, let me address the question one more time.
What do you think makes more sense if you get four to one?
So essentially, you're not authorized?
Does it make sense to display that or kick out the user and then make sure that he or she logs back
in?
And of course, the answer is the second one where essentially you want to log out the user and make
sure that all the credentials are in place.
Now, how do we do that?
Well, remember, we have right now our request and all that.
I mean, everything is beautiful.
We can save it here and make sure that we have the token and where we have the response.
One, instead of just logging, what is the functionality for us that does the long, hard slog out
user correct?
So we're keeping score and keep on scrolling somewhere here who have the user dispatch, as well as
removal from the local storage and instead of just logging something.
The off air or whatever, I actually want to invoke dysfunction.
I want to go here with logout user and invoke it.
You know what?
I think I was in too much of a hurry, actually.
Still want to showcase this?
My apologies.
So now let's notice something where I'm going to go back to my application.
All the values are here.
Everything is correct.
But since I have the token missing, I will be logged out as I should be.
Now, one thing that I kind of want to quickly mention is the fact that we'll still display this arrow
here, the alert, or simply because I mean, it takes time for us to remove it.
Correct.
Remember, we were doing that delay thing.
So let me just quickly show cause that where I'm going to go with email.
And if I remember correctly, it was Susan now.
Now I believe my password is still secret.
Hopefully, I didn't mess that one up.
And again, let me quickly show something more once I go here and then I go to register notice.
You'll get this alert for a little bit because we have that delay.
Now, why am I showing that?
Not only what I want to do is log out user here if it is for one?
I also want to go to my update user over here.
And I actually want to dispatch this one only if it's not for one.
So essentially, if it's for one, I mean, there's really no point to showing that alert, correct
and how we can do that while we're here, I can just set up the if condition where I'm going to go with
error, then that response response status.
And I'll just say, if it's not for one, then display there otherwise.
I mean, you don't have to do anything.
And yes, to answer your question, you can also attach, for example, five hundred in the log out
as well as here.
I mean, that kind of makes sense.
If the server is not working properly, the user shouldn't be sitting in the front me anyway.
So I'm going to go over here.
I'll say if it's not for one, and then let's take this one over here.
Let's say it.
And now let's go back to our front end application one more time.
So let me quickly log in again.
I know you're probably sick of this, but.
Mean, just do that.
I'm going to go here, I'm going to log in again, I'll provide all the values, so that should be correct.
And then let me go and I'll quickly show that there is an alert in this case.
Again, you might say it's an extra step, but in my opinion, since we're setting up that delay, it
kind of makes sense over here that we're not displaying the alert.
Again, let me repeat, if there would be no delay, this wouldn't be necessary.
Well, right away.
Log out the user.
So that way there's not going to be sending that message over there because keep in mind that we set
this up and then there's that delay for us to remove in my case right away, just remove it when we
invoke the function.
Hopefully, that makes sense.
And before we start setting up the jobs in our application, so essentially, we'll start with the model.
We set up the controller and you already know the drill.
I also want to clean up the app context a little bit where I will comment out of this log.
So essentially, if you want to keep it, it's definitely an option.
In my case, I will comment this one out.
I will uncomment the Birtukan you the request one.
So this one was in response, more specifically in the error callback function.
Now this is going to be in the request one in the callback function.
So a definitely, definitely definitely want to add that token over here.
And then remember.
In a profile, we comment this one, correct.
While we were testing well, we're done with testing.
Just keep in mind that from this point on, we'll be checking for those antibodies right away in the
front.
So if you all try to test the for hire response, I mean, it's not going to work because we'll right
away check for it or we're here and with these changes in place.
Now we can start setting up jobs in our application.