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

3.1 Implementing a Client Application, Part 1

Now that our server application is working, we need to have some sort of a client application to counter it. What better way to do it than with a basic Sinatra application that just tries to communicate with the server. We're gonna have a basic route and a protected route. So what we're gonna do here in specific is a very simple Sinatra app that will contain some sort of a basic URL like localhost with a specific port. And we're gonna have a protected route, something like slash protected. That should indeed be protected. Only signed in users should be able to access that content. So when hitting the protected route, we're gonna redirect back to the login route in the login application, and we're gonna go from there. When we get a ticket parameter in our application, the client, we will identify it and process it by requesting the service validate URL in the user's application. With that, we're gonna get an XML content, and establish a session cookie. Then we're going to redirect back to the original URL in the client application. And then trying to request the protected content, we will validate the session and we're good to go. So let's do that. I've created a CLI folder in which we're going to store our Sinatra app. So I'm going to start by editing a gem file, which will include a reference to ruby gems. So we'll do that, https://rubygems.org. And then we're going to include the Sinatra gem first, and I'm going to specifically indicate the git version. So, I'm gonna go ahead and refer to the GitHub repository, sinatra/sinatra. And the reason for this is, the Sinatra gem is kind of updated. And it has some bugs inside, so I'm just going to refer to the master version. Then were going to include some other gems such as Nokogiri, Haml as well because I prefer Haml over ERB. Let's also include httparty so that we can send that validate request and finally pry-byebug, and this is just for debugging purposes in case we need to. We did need it when implementing the server so let's just include that as well. I'm going to type in the bundle command to install all of those different gems right away. After this step, we can create our application file and a back up file so that we can run that application straight away. Okay, there you go. We have all of the dependencies installed, we can move on to the next step. In here, I'm going to create a config dot [UNKNOWN] file which will basically require bundler and which in turn will require all of the gems that we have previously. Then we're going to run that application like so. But first, we need to require that app so ./app. There you go. And that file will be created right away. So press Enter and then we're gonna go ahead and create a views folder, a public folder to store for example asset files, I don't know. And now I think we're good to go. Let's go ahead and create an index template first and a protected template as well. Remember, the protected content is going to be something like hello, and then we're going to create, for example, a user. You are inside the app. So, remember that this protected template will require a user instance variable. It is going to be protected from the regular user, whereas he can only access the index template. So, we can type in, you are a stranger. This is just to tell the user that he's going to access public content. There you go. Now I'm going to take the chance and create a new link. So, I'm gonna go straight to slash protected because this is the content that we want to access as an authenticated user. So I'm going to type in something like access protected content, so that we can have a means of accessing it. Now, we have the two templates, we can go straight to the application file and create our app. So, let's inherit it from Sinatra base, and create, for example, a get route for the home location. And we're going to type in haml, index. That's really all there is to it. Then as far as protected goes, I'm going to create that route. And the normal procedure should be to access the protected content and create that instance variable, which should really be nil for now because we don't have means of accessing it. But now, there is the missing link. How should you approach authentication in this client app? Well, I'm going to create a similar approach to devise. If you're familiar with it, it has an authenticate_user method like so, which we can define below. So I'm just going to define that here. There you go. And this method will handle all of the authentication process. So what should we do inside this method? Well, given the conditions of the protocol specification, we should cover several conditions. The first one is we need to assert that if the user is logged in. If it is then we should be nothing at all, I mean we're logged in so it's okay. So we're gonna go ahead and cover the exact opposite case. If we are not logged in then we're going to do something about it. Now in terms of not being logged in, we have two situations. One of them is the presence of a service ticket by checking if we have a ticket parameter in the URL. If you do have such a ticket then we need to validate it against the database. You know perform a request. Otherwise, we just need to login, redirect to the login page, fill in the username and password, and go from there. So if there is a service ticket, so if service_ticket, then we are going to validate it. Otherwise, we're just going to login. And notice how I'm writing these methods in the expectation of writing those right below. Let's first implement this one. And this method returns true, in case we have that ticket parameter. So if we do have it, we're going to validate, otherwise, we're going to login. Let's first go to the login method because it is a lot simpler than the validate method. In this method, all we need to do is redirect some place else. So, in this case, I'm just going to hard code it, localhost and then port, whatever port we want. Let's say, for example, that I'm going to boot it up in 7890 and then the login method. Notice how I'm also going to provide a service parameter, which is going to be something like URI.encode, and this is important because it needs to be parsed correctly. And then provide a string, so http://locahost, port, let's say the default one, 4567. This is pretty straightforward. We just want to redirect back to our sign in application. In regards to the validate method, it is going to be a little trickier. Let me push this to the middle and provide a sample of code which I'm going to explain. So here is the validate method. I have a hash which contains a service argument and a ticket argument which will be passed into HTTParty.get. The URL that goes inside contains those parameters via the parametarized method that I've created before. There you go. Now this method is defined in line 48 and basically all it does is it converts that hash into a regular string joined by ampersands. This is just so we can fit that into the URL that goes into the get method. So we'll perform a get response and we'll retrieve an XML file. As you can see, the xml_response will be interpreted by the XML constant in Nokogiri. If we have an authenticationSuccess tag, then we're going to retrieve the user, establish it in the session. And specifically, the email attribute will be the content of the user tag in our XML document. If we don't have the authenticationSuccess tag, then we're going to retrieve the error text, as provided in the authenticationFailure tag. Most likely, we won't need to face that. As you can see, we have quite some repetition in these methods. So I'm going to extract a couple of variables into their places. Namely, the client URL and the server URL. So I'm going to cut this part of the video in order to extract these variables and I'll be right back. Okay, there you go. You can see the server and client instance variables being used all over. They are defined right here in the authenticate_user method just for convenience. So we have the localhost 7890 as the server, and 4567 as the client. These will come in handy to change, for example, the client, so that we have two applications running with different ports so they can represent different applications. So with this, I think we're good to go and try and test this out. I'm gonna go ahead and create a new pane with the API server running. As you can see, we are inside the API folder. So, what I'll do is go to lib/api/app, which is the location of our application. Just type in the bundle command really quick. There you go. And now I can type in bundle exec rackup. You can see that the current port is 9292 but I'm going to change this back to the port that we had to find previously in the client. So, I use bundle exec rackup and then -p 7890. There you go. Now let's go to our browser and create a new tab. I'm gonna go to local host 7890. You will see that we have our list of users. So the application is working just fine. Now we need to go ahead and provide the localhost port 4567 running. You can see that it's still not available. So we're gonna go to the previous tab and I'm going to close the editor really quick and type in bundle exec rack up, but this time the port should be 4567. Let's see if this works, and it seems it is. Let's go ahead and reload this page. And you can see that we are a stranger. Oh, by the way, there's something that I forgot to mention. Let's go to the Enter really quick. In here, I'm gonna go to views and then protected. And inside, I'm gonna go ahead and retrieve the email property. Also in the application file, we don't have this method anywhere. So let's go ahead and do that. So define the logged_in method and I'm just going to retrieve the current_user. If it isn't nil then we are logged in and this current user will just be session and then user. And that's all there is to it. The current user will be available in line eight, which we'll use to retrieve the content of the instance variable. So user will be current_user. Now this is more I like it. Now I can safely quit the editor and run the application once more. Now let's reload this page and you can see that it is totally fine. Now, I'm going to click on this link and you can see on the bottom that we are going to the protected route. I'll click on it. And there you go. We are inside the new application. We're gonna go to the login method and the service argument is there. If we take a closer look at the source, you will see the username, password and lt ticket as well. There you go. I'm gonna go ahead and type in my usual address and my password. I'm going to login. And you can see that unfortunately, we don't have the ticket granting tickets table. Okay, this is actually good, because it means that our application is trying to work itself out. In order to fix this issue, I'm going to go to another pane on the terminal and type in bundle exec rake db:migrate, and this is going to migrate the development database. Okay, there you go. Now I'm going to resubmit the data. And there you go. Now you can see that the service ticket is there. So what should we do here? Stick around to solve this issue in part two.

Back to the top