7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial
FREELessons: 17Length: 2.7 hours

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

2.10 Consolidate the Login Process Into the Application, Part 2

This is part two on integrating our services with the Sinatra application. We're left with this, we're trying to integrate the ticket granting cookie and service ticket onto the Sinatra app, which match two different errors that we still need to solve. The first one is it sends the ticket granting ticket on a successful authentication attempt, which is not working. Well, we need to work that out. Let's see if, by preventing this, this will work. And it is. The reason for this regards the service parameter that we sent. As you can see here on top, the service variable is something that doesn't really exist, it's kind of fictional. So, were gonna have to work our way around the tests and the implementation. So, in this case we are only going to redirect to the service if there is such a parameter. So, we'll type in that condition first, close it in, and this should make the tests pass. If you pay close attention to the tests, let me just go over there. You can see that there is no service argument in this test in specific. That way, this confusion with the different URLs won't mix up our tests. So, let's run the tests now, and you can see that they pass. We see that the location header is there. The ticket is going to be printed out. And, also, we will have that cookie, regardless of having a redirect or not. Okay. So from here, we can move onto the next set of tests. Let me just close these in. I'm gonna open this one. And this will just assert that it redirects to the service. Just mentioning that the 303 status is issued, and that the service argument is there. Oh, there's a mistake that I made here. We need to enclose this not in the post route, but rather as an argument to the form. So, we'll just fix that really quick, there you go. And from here, we can run this test in particular just so we know that the status is there. Well the normal is 302, but according to the specification, we should provide a 303 status code. Let's now run the test, and they're all passing. There's only one test remaining. And this one is very interesting, because it regards a warm login. There's already a ticket. We're going to spawn a new user, perform a login with him, which is going to ensure that the cookie is already there, and then we're going to try and login again. So, just by providing the get route slash login, and we should assert that we are redirected, indeed. So, before we run the tests, we need to implement this method. It doesn't exist anywhere. Let's go to the test helper and create that method. And go ahead right down below, and create that performed login method with a user. So, what should this method do? Well, that's easy. We need to call the post login method, so we'll do just that. As you can see, this perform login method is quite convoluted. It takes a login ticket first, because we need to shove it in to the post prompt. It takes the user, as before, the password, and then the service parameter as well. At the end, we'll want the service ticket already in place by using this command. We're going to parse the header here called location. We're just going to provide the query argument, fetch the ticket and this position is zero. It's just mandatory, because of the return of this ticket key. We'll parse a URI that has a ticket argument in there. That's basically what we want. This service ticket argument will be used later on. So, let's go back to the test. You can see that after performing a login, a ticket granting cookie will appear. Let's run the tests now. As you can see, we have a 200 route when it should be a 303. We're going to assume that the login form is being displayed when it shouldn't be. So, with that, we're going to go to our app file and check here whether the ticket granting cookie is there. So, if the ticket granting cookie is there, so let's just type that in, then we're going to provide something, otherwise we're just going to do the same thing as we were doing. Let's create that method really quick. So, def ticket granting ticket with an exclamation mark, and for now we should run the tests to see whether we made some mistake that compromises the previous behavior. And we do not. Everything is working smoothly. So, let's check for that ticket granting cookie. If we go to the request and check its cookies by using the cookies method, and then we just pass in the key for that cookie like so. And we should check whether it exists. So, if we say that this is not new, and also, we should make sure that it already exists in the database. So, what we do is perform a query on the ticket granting tickets table, where that ticket exists. So a rare condition where the name of the ticket is request.cookies CASTGC, and we check the first one. We just want to know if it exists. Okay. Let's see if this works. I'm just going to run the test to make sure that it works, and it does, well at least the behavior is not compromised whatsoever. So, in the presence of a ticket granting cookie, we should do something very similar to what we already have in the post method. If we have a service parameter, we should redirect back to it. Notice how we should also make sure that the service ticket is issued. How should we proceed about that? Well we already have that scenario covered in our service. However, we're gonna have to take a step back here. Or better, let's just leave it like that. But in terms of this service ticket, we'll need to copy this code right here, paste it right there, but we'll pass in the ticket granting ticket name as request.cookies, and pass that same cookie. So, after calling the service we should redirect to param service, and then pass the ticket that's already generated for us. So, we should be good to go. Let's make sure of that by running the tests as usual. There you go, it works. So the next thing that we need to do is to validate the service parameters based off the information we already have.

Back to the top