2.8 Validate Service Tickets
Service tickets are important for establishing a proper session in each of our applications. They will trigger the mechanism that retrieves the user data to be used in our application.
1.Introduction2 lessons, 07:43
2.Creating the API Server12 lessons, 2:10:56
3.A Client Demonstration App2 lessons, 20:49
4.Conclusion1 lesson, 01:35
2.8 Validate Service Tickets
Let's continue on with the specification. In the diagram that you see here, we have loads of different data that we have already covered. Namely the service parameter, then the data that concerns the lock in procedure, such as the username, the password and login ticket. Then the ticket granting ticket is also taken care of, as well as the service ticket right down below. The next step is to use the service ticket to validate the service. So the service ticket should be associated with this particular service. Let's say for example that you use this ticket to validate a different service. That shouldn't be valid as well. This will work as a tuple that wont work one without the other. At the end, we will generate an XML content but that will be for another lesson. That specifically concerns the presentation of that data. Not exactly its manipulation or operation. We do, however, need to establish a relationship between the service and the service ticket. We're going to cover the service validate method here. We're going to create a new service that will validate the service ticket against a service. In our editor, we're going to create a new test called validate test. This will handle the specific case of trying to validate a service. Let me paste a set of tests so that we can study them. As you can see, these are two very simple tests, but they will allow us to cover the most successful case of a validation process. As you can see, we have a service variable, a user, which will be spawned via the helper that we have here, the test_helper. The service_ticket will be a new service ticket, which gets the service and the user. The reason for this is, as I've mentioned before, we need to counter the service ticket with the service URL. If we have the same service ticket for multiple apps that wouldn't be good. It would compromise security. Also, we need to establish a relationship between the service ticket and the user, because when validating the service ticket successfully, we will need to retrieve the information about the user. Where is the information stored? Well, through the ticket granting ticket. When we perform a successful login, we create that ticket granting ticket with information on the user, which is essential to connect all of these. Well, at the end of it all, we'll just create a new validate service. It takes the service argument and the service ticket's name. We'll call the validate service. And at the end, we'll assert that the status is okay and also that it retrieves the user. Okay, let's run the tests right away. You will see that the validate class isn't there. Well let's take care of that right away. Under lib > api > services, we'll create that validate class and open it up right away. We're also gonna go to the api.rb file and include that service. Switch this with the validate. Save. Now let's go back to the validate file and create the validate class. It is going to be under the Api, double colon, Services module for name spacing purposes, and also let's take the chance to create the call method and the initialize method. Okay. Now let's run the test again. And you will see that spawn_service_ticket doesn't exist. Well, that's easy to fix. Let's go to the test_helper and create a new helper method. Very similar to the ticket granting ticket. We'll create that as well. So, spawn_service_ticket, which takes a name, which will be nil. And user, which will also be nil. In fact, let's just omit the name. We're just going to rely on the user. The name for the service ticket, let's replace that, will be something like ST-random. And then we're just going to call save and return it as a service ticket. Oh, I forgot about the actual service parameter, which we need to pass, as well. So, let's go ahead and type that in. Service will be the contents of the service variable. And, that's a go. Let's run this again. And now we have a different error. You can see that service is not available as an attribute for the service ticket. Because this need only appeared now because of validation purposes, we are going to adapt our migrations in order to accommodate that service parameter. So we'll create a new string, which will be called service, and that's it. Remember that the service argument is not actually required, but we are assuming that the service parameter will always be there. Let's go ahead and remove the test database and migrate the changes. This is okay because we are using database cleaner, we are not actually doing any sort of live testing in the browser or anything. So this is okay. Now let's run the test again, most likely that error should disappear. Now this time we don't have the user reference for the service ticket. We should have predicted this but, let's just go with the flow. Create the user reference, like so. Migrate the changes again, okay. Now, let's run the test again. It seems that we still don't have that user attribute in the service ticket. However, notice how this has been called test_helper, in the spawn_service_method. Well, there's one thing that we should do. Let's go to the service_ticket class. Okay, now inside, we're gonna have a reference to the user as well the same way we did with the ticket granting ticket. Let's run the test again. And there you go. Now there's a different error. You can see in line three, in the initializer for the service, that we are not taking any arguments. Well, that was purposeful. We can see in the class that we indeed don't have anything. Let's see what we should do. The constructor for a the validate method expects a service name and a service ticket name. Let's do that. So, this will be the service and then the service_ticket_name. Let's initialize the class by typing in the respective instance variables. There you go. We can now save and run again. This time, we get two specific errors. One for the status, and another one for the user. Let's go ahead and define attr_reader methods for them, because we'll be needing those instance variables available. The status is just a control flag and a user will be necessary to render the XML content later in the course. Now, if I run the tests, you will see expectation failures. We expected an okay status and the user not to be nill. Okay, let's take care of what needs to be implemented in the call method. Let's try and find the service. So, if service_found, and this is a method I'm going to define here, privately. So, let's define that method really quick, service_found. And, basically, all this is going to do is find the ticket. So we'll use a where condition and the first record, really. Now, what should be going into the where condition, the where method? We have the service and the service_ticket_name. The two conditions must be met simultaneously, so we'll use those and the where condition at the same time. The name should be equal to the service_ticket_name and the service variable, or attribute, should be the contents of service. So, if the service is found, then we're going to say that the status is okay. And let's go ahead and run the test now. One of the tests is already working and it means that the service was indeed found. So let's assign this to a service_ticket variable, really quick. Because this will be necessary to establish a user instance variable which will be service_ticket.user. Since we have that reference from the active record relationships, this will be good to go. As you can see, all tests agree. This is very important because the validation process is mandatory as for the specification in the diagram that we saw at the beginning of the lesson. As you can see here, I don't believe there are anymore attributes that need to be taken care of. We have the service parameter being handled. The ticket granting cookie, the service ticket, which is going to be validated as well. We will need to render a specific XML content, but that's going to be for the next lesson.