View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Chris Logan (Query Strings)

Query Strings are very useful when getting information from an html or ssp page and transferring this information to other html or ssp pages, but there is a downside. Query Strings display to the user what is being used in the query.



PART I
Simple Query Strings



To understand query strings better, create two web pages on your desktop call one login.html and post the below code into it, and call the other game.html and this can have whatever code you would like to have, but it does not need any code for the purposes of this demonstration.

Here is an example of how a query string gets created (copy this code into login.html):


<html>
<body>
      <form name="input" action="game.html" method="get">
      Username:<input type="text" name="uname" /><br>
      Password:<input type="password" name="pass" /><br>
      <input type="submit" value="Log In" />
      </form>
</body>
</html>



This code does the following:
  1. creates a new web page
  2. creates a form on this web page
  3. creates an input box for the Username and Password and makes the password not be displayed when typing
  4. creates a button called Log In that will take the user to the web page called game.html
  5. links the Log In button to create a query string with variables uname and pass that will hold the values of the username and password respectively

The problem with this is that when the user types in a username and hidden password, both get displayed in the form of a query string when game.html loads. Open login.html in your internet browser (Firefox, IE, etc.) and you should see the form. Go ahead and fill it out and click Log In (for this example I am entering Student as my username and CS2340 for my password). This should take you to the game.html web page, and if you look at the url bar you will see that the url is something like (note this was done on Windows XP so your location might be different on different systems):

file:///C:/Documents%20and%20Settings/HP_Administrator/Desktop/game.html?uname=Student&pass=CS2340


This is a web page using a query string where:

?uname=Student&pass=CS2340


is the query string.

It has the values I entered into the form on the login.html page, but the problem is my username and password are labeled and displayed for anyone to see! This is definitely not a secure method of logging in and can easily be exploited by simply looking over the shoulder of a person as they log in. A quick and easy way around this is to have a validation or verification web page between these two. This middle page will handle the query string but it will happen so fast that it won't even get displayed, so the user's identification is protected on a minimal basis. Because this is a Smalltalk class you will most likely require getting the username and password from an html for and incorporating it into Smalltalk somehow, so lets do it in the next example.



PART II
Creating a Validation Page



In the previous example, the form was connected to the game.html page because of the piece of code:

<form name="input" action="game.html" method="get">


But we don't want to link directly to the game page, instead we want to link to the validation page we are about to create, so we should change this line to read:

<form name="input" action="validation.ssp" method="get">


Then we will create a validation.ssp page with the following code:

<html>

<% uname := request anyParameterValueAt: 'uname'.
   pass := request anyParameterValueAt: 'pass'.

   ((uname = 'Student') & (pass = 'CS2340')) ifTrue: [
          response redirectTo: ('game.html').
   ].

   ((uname = 'Student') & (pass = 'CS2340')) ifFalse: [
          response redirectTo: ('login_incorrect.html').
   ].
%>

</html>


This is a very simple version of a validation page. What this code does is first creates a variable uname with any values at the parameter called 'uname' in the query string. The second line stores an values in the query string labeled 'pass' into a variable called pass. Essentially what has happened is the form from the login.html page created a query string that looks like:

?uname=Student&pass=CS2340


and this bit of Smalltalk code gets the Username input and stores that into a Smalltalk variable called uname, and then gets the Password input and stores that into a Smalltalk variable called pass. So now in our Smalltalk code we should have:

uname = 'Student'
pass = 'CS2340'


If I logged in with those as my uname and password on the previous page.

The next section of code:

((uname = 'Student') & (pass = 'CS2340')) ifTrue: [
          response redirectTo: ('game.html').
   ].


is a simple check. What this does is check to see if the uname is Student and the password is CS2340. If it is, then this means that the correct user has logged in and should be redirected to the game.html page. This is a bare minimum of what can actually be done here. The code could start the game and log the user in, or check to make sure that the user has a saved file, or even be combined with the
session at:
function to create a session variable to be passed between .ssp pages.

The next section of code:

((uname = 'Student') & (pass = 'CS2340')) ifFalse: [
          response redirectTo: ('login_incorrect.html').
   ].


checks for the input to be incorrect.



Part III
Redirection Page



Now a very simple way to handle this is to create a simple check, which is what I have done, and then if the input is incorrect simply redirect the user back to the login.html page. The problem with this is that the user doesn't get to see that the log in failed, it simply looks like the login.html page just reloaded. A proper way to handle this would be to redirect to a near identical web page with some sort of indication that the log in failed. For instance, a very simple login_incorrect.html would have the following code:

<html>
<body>
      <b>INCORRECT USERNAME/PASSWORD COMBINATION</b>
      <form name="input" action="validation.ssp" method="get">
      Username:<input type="text" name="uname" /><br>
      Password:<input type="password" name="pass" /><br>
      <input type="submit" value="Log In" />
      </form>
</body>
</html>


This notifies the user that the input information was incorrect, and has the form that they have already seen which connects back to the validation page in case the user would like to make another attempt at logging in.



PART IV
Summary



We have just created 4 very simple web pages that can be easily modified to accommodate almost any log in or query sequence. The final code for each file should look as such:

login.html
<html>
<body>
      <form name="input" action="validation.ssp" method="get">
      Username:<input type="text" name="uname" /><br>
      Password:<input type="password" name="pass" /><br>
      <input type="submit" value="Log In" />
      </form>
</body>
</html>




login_incorrect.html
<html>
<body>
      <b>INCORRECT USERNAME/PASSWORD COMBINATION</b>
      <form name="input" action="validation.ssp" method="get">
      Username:<input type="text" name="uname" /><br>
      Password:<input type="password" name="pass" /><br>
      <input type="submit" value="Log In" />
      </form>
</body>
</html>




validation.ssp
<html>

<% uname := request anyParameterValueAt: 'uname'.
   pass := request anyParameterValueAt: 'pass'.

   ((uname = 'Student') & (pass = 'CS2340')) ifTrue: [
          response redirectTo: ('game.html').
   ].

   ((uname = 'Student') & (pass = 'CS2340')) ifFalse: [
          response redirectTo: ('login_incorrect.html').
   ].
%>

</html>




game.html
<html>
YOUR CODE HERE!
</html>



A quick site mapping of the interaction of web pages we have created is:

SUCCESSFUL LOG IN:

login.html –> validation.ssp –> game.html

UNSUCCESSFUL LOG IN –> SUCCESSFUL LOG IN:

login.html –> validation.ssp –> login_incorrect.html –> validation.ssp –> game.html



The code provided on this page was the beginning test code that we used to create our website, which ended up dropping the password feature because it was not needed for the game we created, and allowed for us to use the username in game by setting the variable of the player name to the uname on the validation page. This also allowed for us to maintain the save feature by making the save file incorporate the username, thus ensuring that online users could have unique save files. This page briefly touched on the use of the Smalltalk session manager. The session manager acts like the Smalltalk version of query strings, allowing you to not have to worry about creating a verification or validation page in between the log in steps, but it does require that you add in some Smalltalk code into a file that doesn't really need it. The idea of the validation page is also useful in creating a stepping page that allows for the web page to interact with the game engine and give it enough time to process data and then reload it, but it is not necessary. The validation code could have been simply handled on the game.html page to prevent from needing a new web page, but still requires more work in that every time the game page is loaded it has to deal with the validation code in some way, which is not preferable. Remember code smarter, not harder.

Also, check out http://www.w3schools.com/ for help on html and css coding, it is an awesome website with interactive examples and has saved me on numerous website designs before this class, and helped me remember how to use css and query strings for this class in particular.

Good Luck!


Link to this Page