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

  • Overview
  • Transcript

2.7 Ticket Granting Cookies, Part 2

This is part two on integrating ticket granting cookies and service tickets into our application. We were on our way to exploring a few tests around authentication using the ticket granting cookie. This is the scenario where we already had filled in the login parameters, such as a user name and password. We already had a ticket granting cookie. And, we want to login to another application. But, we already have that cookie. We are going to spawn a new ticket granting ticket, which creates that ticket in the database. Notice how it requires a user variable to be registered along with the ticket. Well this is fundamental. Because when we want to access the users data in a particular session in the application we want to know who it is logged in. We already have that user here, we're going to associate it to the ticket. And then when we try to log in we will have that status service. The user will be important later on when trying to validate the service and provide the user information. So we're going to create this method and we'll take the user along. So in the test helper class, I'm gonna go here and define that spawn ticket granting ticket which takes a user. So the body of the method, it is basically something like this. We're going to create a new ticket granting ticket so it'll be the new instance of that. We'll pick up on a name we can really create something totally random, so, tgt and then random. And the user should be that user. We're gonna call tgt.save, and return, that ticket. Once again, create that new instance with a name and a user. Then we're gonna save the model, and return it. Now, this is taken care of. We have the ticket in our hand. And we're going to shove it into the service. And finally we're going to call the service to see if the login is successful. Notice how we still don't need any login ticket because we're not filling in any user name or password. That's not part of it. We just want the ticket. Now let's run the tests, but let me just comment this out. So let's run it. And notice how the attribute called user doesn't exist. We're gonna need to change the ticket granting ticket migration file. We could create a new file. To add that change to the table, but I'm just going to pick it up on where we left, and I'm going to create a new reference to the user. So t.references user. The next step should be to remove the entire database and migrate the data all over again. This might look a little odd to you, changing the migrations. But since this is going to be a better fix situation, this is kind of a normal atomic development, this should be treated as a whole unlike regular applications. This is more of a gem rather than an app. So we've already migrated the changes. Let's now move the log in service. In which we should actually provide a user here. So what I'm gonna do is pass in a user instance variable and then we're going to assign it in the valid authentication. Let's run the tests first to see if you are having more than one failing test and we are. These are all related to the ticket granting ticket so we should go to the model. Let's just go there. Let's see. Ticket granting ticket model, there it is. And we should say that it belongs to a particular user. This is the notation that we should be using because we have a column called user ID. We can now run the tests and the result is a lot different. In the Login class in line five. You can see that this keyword is unknown. Well, that's because the constructor still doesn't take a ticket granting ticket name. Let's do that. So, ticket granting ticket name, as you can see here, and we'll shove it in a new instance variable. There you go. Now we can run the tests again and this time it will be a lot different. So the status should be okay based off the ticket granting ticket. In the valid auth method, we should check whether it is via a ticket or regular user password data. Let's go there. This is the method. And in this method we are just covering one scenario. So we should check whether the ticket granting ticket name is there. So, if ticket granting ticket name is nill, then we are going to return this user instance variable. Otherwise, we will want to check whether the ticket granting ticket is valid. So, user will be something like ticketgrantingticket.wherename equals our ticket granting ticket name. We're going to fetch the first one and then the user. We are still going to want the user information. And for that, we're going to find the ticket granting ticket first and if it exists in our database, we will want to fetch its user. This is going to fail, of course, because if we don't have that ticket, so this should return nil, then, this would pop an exception. So first we're going to type in a ticket variable and then if the ticket exists then we want to assign the user to ticket user. If there is no such thing as a ticket then we will just return false. Because the valid auth method expects something. In this case, if we don't have the ticket, we're going to fetch for the user. Otherwise, we're going to go and fetch the ticket, retrieve the user if there is one, otherwise return false. Let's run the tests now. And you can see that the status method still doesn't exist. We're going to create another reader for this, so status here. And at the end of it all in the log in method, if the authentication is valid we should provide a status variable to be okay. Let's run the test. And you can see that the status is expected to be okay but we got nil. There is a reason why the status variable is set to nil. That's because it hasn't gone through this stage of the code. So, it means that either it didn't pass in the valid auth method. Or even worse, it didn't pass the first condition at all. As you can see in line 14, the condition of the username variable being there is not being met. It is going to generate the login ticket before even considering that there is a ticket granting ticket name. So what we need to do is check for either the username or the ticket granting ticket name. So we want to check for the ticket granting ticket name as well. If both of these are nil, then we're going to generate the ticket. Let's run the tests once again. And this time, we have an error because the update attribute is being called on nil. Well, that's easy to explain. The log in ticket isn't there. So, we are only going to expire the log in ticket if there is one. So, let's just do that. If the log in ticket name is there then we're going to expire it. Let's run the test again and there you go. This is really good. It means that we are indeed fetching the ticket and respective user from the data base. And we'll be able to return that same ticket granting ticket. So what I'm gonna do here, is I'm going to change this back to ticket granting ticket, because we either generate it or retrieve it already from the database. Let's do the same here, so ticket granting ticket here. And let's run the tests, just to make sure. Oh, it seems that we now have a different expectation. We've managed to create a bug, so let's just fix that. I'm going to fix the if condition. Let's run the tests again. And now it's working. Well done. Now, let's move on to the next test. Let me just bring that up really quick. There you go. The last test that we need to focus on is the one in line 25. It provides a service ticket as well. So, let's just run that in. It already passes, because the generate service ticket is being called the same way. That's why the tasks are green. So regardless of having either a ticket granting ticket or a username and password combo, the service ticket is generated anyways.

Back to the top