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.12 Final Assembly

Let's revisit the flow diagram that we've been using so far as a reference. We've done quite a lot of things, but it's important to validate our work against this diagram. So, we have this login route already implemented in the application. It is going to verify whether we have a single sign-on session or not via the cookie. You present a form, which we can then submit with the various different kinds of data. You authenticate the user and due to that fact, we set a cookie for that session and we redirect back to the service ticket. Then, the service ticket is passed onto our application, and being identified, it is going to validate it against our own service. We have this step here, validating the service. We still need to complete the XML content, so that our application can read it and set the appropriate session data. After that, we are redirected back to our application, which will then proceed with a normal flow. We just validate the session cookie, as you would do with any other application, and retrieve the respective content. Aside from the entire application on the client, the only thing that we need to finish is the XML content, so we'll finish that right away. The XML content that we need to render to our client application is this one. We have an appropriate structure already built in, specified by the protocol. So, in case we should have a success state, we should print out this. Otherwise, we should print an appropriate XML response in regards to the error. If you scroll down a bit, you will see that we have this sort of template. This is the appropriate XML response for an error. We have an authentication failure tag with a code and the appropriate error message. You can do this as you see fit. We're going to resort to the simplest case possible. So, let's jump right in. In the service validate template, I'm going to paste the following snippet, that will allow us to represent, as close as possible, what we had in the specification. If you're not familiar with the builder syntax, then I will leave a link in the description below so you can learn about it. Using the builder template engine is really simple. You use the XML object, and then the tag method, which takes a block. The first argument of the tag instruction is the name of the tag. The following arguments would be attributes to that tag. Specifically for line 17, we still have that hash of arguments, but the last one should be the content for that tag. Specifically for the authentication failure, it contains some content inside the tag instead of a block, so you pass that in as the third argument. Remember that this is still Ruby code. It takes blocks and arguments, and these are all Ruby objects. So, what we're doing is just strictly following the protocol. You can see that we are printing a service response, and then in case we have a success message, then we'll print the authentication success tag, then the user tag. The set of attributes, if we do have any extra attributes we want to pass in, such as for example, a link to an image or a name, something like that. For now, we're just going to stick with the basic username. So, we'll just print out the email for that user, but still if you want to, you can print out the list of extra attributes. [BLANK_AUDIO] And that's all there is to is. Really there is nothing else to do. Let's try and run the tests really quick so that we assert that no errors are being spawned based on this change. Well, it seems that we have an error, indeed. Let's check it out. Let me just make sure that I used a test environment, so that the errors pop up. Okay, let's take a look. You can see now that the email method is undefined for nil, and most likely the same thing will happen for the other test. So in line six, when defining the user tag, we are retrieving email from nil. What do we need to do? Well, we need to instantiate that user, but as you can see, we are having trouble retrieving the user. It's returning nil. I'm going to establish a binding here, just to make sure that, that is the problem. Okay, let's check the service first, and as you can see the user right here is nil. We are not retrieving the user whatsoever from the service. I'm going to skip all of these tests and jump right into the actual service. I'm going to open it up, okay. Now we're going to call it, and most likely, the problem is in the service ticket. It doesn't have the reference to the user. So, what should we do? Let's think about this for a second. If you judge this really quickly, you can see that if the user reference from the service ticket is nil, that means that somewhere, when creating a service ticket, it should have a reference to the user. So, what better place to assert on this information than to place where the service ticket it created? Well, where is it? It's in the login class. You can see here, in the generate service ticket method, that the service ticket being created has no reference to the user. So, if we pass that in, then we should have the correct information. Let's make sure that the user is correctly provided. Let's follow the normal procedure. Let's go to the login method, and the valid_auth method is the first one. You can see that it goes ahead and retrieves the user, so we won't have any trouble in regards to the reference to the user here. With that said, we can go ahead and run the tests again. I'm going to remove this instruction and run the test suite. Okay, there you go. Now the tests are passing. See how a little change in the template makes a key difference in asserting on the integrity of our application? Well, I guess we're fortunate that we have this sort of thing. So, the XML template is ready. The last thing that we need to do is to test this live, but we're gonna need a client application to do so.

Back to the top