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

3.2 Implementing a Client Application, Part 2

This is part two on implementing a client application for our authentication system. We were on our way to validate this service ticket that you see on top. Well we need to make sure that this ticket is parsed in the root URL. Well this is rather easy to fix. I'll open another pane, go to the cli application, and inside I'm going to create a before filter. Let's do that. Inside the before method, I'm going to check for the service ticket, so I'll create that method, check_service_ticket. And at the end I'm going to define it. So check service ticket and if there is one, then just validate. That's all we need to do. Because we already had those methods before, we just need to reuse them. So now that we have that, I'm going to start over. I'm going to clear the CLI application. Run it again, and this time instead of using this regular window, I'm going to provide an empty window, an incognito window so that we don't have any sort of ticket, okay? So I'm going to go ahead here local host 4567. Okay. I'm gonna access my protective content, and I'm going to be redirected to the login page. Let's type in that password really quick. Login, and this time it seems that we have an error in our own server. Okay, so the gsub method is being called on nil. You can see that the problem most likely is in here. The instance variable most likely isn't defined. So, let's go back here really quick. You can see that the validate method expects a client instance variable. So instead of putting these two variables in the authenticate user method, I'm going to place them in the before filter. This will most definitely solve the problem, because the instance variables will be defined before anything else. With that, I'm going to close the server really quick, or rather, the client application, and run that again. There you go. Now I'm gonna go ahead and close this window and open it again so that we can start the process all over again. So, localhost 4567. Let's access the protected content. Okay, I am going to type in my username and password. Login, and you can see that it seems we don't have any ticket. If we try to access the protected content, you will see that it doesn't work. You might be wondering what is the problem. We did everything right, but we are not managing to work it out. Well, the solution is quite simple, and that is because I forgot to enable sessions in the Sinatra app. And that's all there is to it. I forgot to add this. Because we didn't enable sessions before, we can actually retrieve the contents of the session, that's why. So, I'm gonna kill this application again, restart it all over. And now I can simply go here, access the protected content. I've clicked on it, and the session is now established. And clicking on it, you will see our address. We are inside the application. So that's it. Congratulations on building essential authentication service with Ruby. We have used Sinatra to accomplish it for both server and client applications. But the main important part is following the protocol specification through test driven development. By closely following the specification, we were able to create several different services that match each different specification, each different use case. With a set of models we are able to store the information and relate all components together. The service ticket and ticket-granting ticket are both related to the user and also to a particular service. The login ticket was also fundamental in order to assess that the login procedure is safe. With the use of active record, we were able to establish a persistent schema in a specific database. We have also provided a sample Sinatra application that supports and resorts even to our own gem, the API gem. So whenever we want to provide a service like this we just need to clone the gem and run the application. That's all there is to it. In terms of the cli application, we have just created a set of helpers that can most likely be included in a module so that we can integrate them in more than one application. In this case we have the authenticate user method, along with the current user method, which we can use in our applications. Going back to the browser and reloading multiple times, you will see that we are still able to persist that session. Now how about the case of having a separate application? For example, spotting the same app, but with a different port. That should work. Let's go to our application here and actually create a new point. I am going to go to the cli folder really quick. And I'm going to change it just a little bit, in the way that I'm going to provide, for example, a 1234 port, and then spawn this application in that port. So, I'll just type in bundle exec rackup, but then a different port, 1234. I'm going to do that, and then your client instance will be spawned. And then we can go to the same window, go to localhost port 1234, and you can see that we are indeed a stranger. But if we try to access the protected content, we will be instantly redirected to the homepage. Because we already have the ticket-granting cookie, we don't need to go through the login process all over again. So, accessing the protected content, we will go there. This is the phenomenon of central authentication. Single sign on is all about creating multiple applications that resort to the same authentication mechanism. I'll see you soon in the last lesson.

Back to the top