ITEC 325 2020fall ibarland

home—lects—hws
D2L—zoom (snow day)

testing forms

We've been talking about input forms (html elements), and then php scripts to process a submitted form:

• The URL that handles the submitted form is the one given in the form tag as the submit attribute:

  <!-- inside form.php (or, form.html) --> <form submit='submit.php' action="post"> Login: <input type='text' name='userid' /> <br /> Remember me?: <input type='checkbox' name='remember' value='yep' /> … </form>

• Use the $_POST (or, $_GET) array to look up values; for indices (keys), use the name attribute that you gave the input-element back in the html.

  <!-- inside submit.php --> <?php echo "Hey there ", $_POST['userid']; if (array_has_index('remember',$_POST)) { echo "How could I ever forget?"; // $_POST['remember'] = 'yep' } ?>

• Note that checkboxes which weren't checked, etc., don't have any entries in $_POST (even though you might wish it had an entry with value “false” or something).
• If you gave several input-elements the same name attribute, and the name ends in “[]”, then in $_POST look it up without the “[]”, and you'll get an array of all the values (with numeric indices/keys).
• Use http post when the URL-request                                                                                                                                           ;
  Use http get when the URL-request                                                                                                                                                                                                                                                                                                                                       .
• php detail: When a php program contains anything not inside “<?php … >”, those lines are simply                                           .

testing a form-handler

Our functions have test cases, and this helps gives us confidence before we ever deploy to the web. But what about form-handlers? The result from form-handler is a long page that includes various bits from the form. It's too tedious to make this a check/expect sort of test, since the details of the html part of the output aren't relevant (and might change). Moreover, generating the page requires the POST data, that were entered by hand back in the form. But we would like to be able to check that the form-handler without going through the web, and also eyeball-check the result on certain inputs w/o having to continually re-type the inputs and call up the form.

Understanding how values get put into $_POST: Apache does it!

The php server, when it gets a request for a file foo.php, chooses to run foo.php (and serve back whatever that file printed). If the server sees that the http-request-packet included form info, then before it (creates and) runs the following php program instead: it runs the php

<?php
  $_POST["quest"] = "more pizza";  // Assign the key/value pairs that
  $_POST["is-happy"] = "yep";      //   were in the http-request-packet.
  // etc
  require_once('foo.php');
?>

testing our form-handler:

We can use the same trick Apache does! We will write the following programs, to test our form-handler:

<?php
  // ~~~~ this is the file: form-handle-test2.php ~~~~
  $_POST["quest"] = "more pizza";
  $_POST["is-happy"] = "yep";
  // etc
  require_once('foo.php');
?>

<?php
  // ~~~~ this is the file: form-handle-test0.php ~~~~
  // $_POST is empty
  require_once('foo.php');
?>

<?php
  // ~~~~ this is the file: form-handle-test1.php ~~~~
  $_POST["quest"] = "this is something very very long that soembody might type in";
  // etc
  require_once('foo.php');
?>

<?php
  // ~~~~ this is the file: form-handle-test3.php ~~~~
  $_POST["quest"] = "this is something very very long that soembody might type in";
  $_POST["is-happy"] = "here is an input that might come from a malicious attacker who bypassed the form and is trying to overflow an internal string buffer by providing a very very long input.";
  // etc
  require_once('foo.php');
?>

Reasons why testing like this is good/handy:

• I can easily see what my form-handler does with different inputs, without having to go hand-type anything into a form, or even visit the page.
• I can test my form-handler independently of any network/web/file-permission issues.
• I can also run that test-handler via the web, thereby also testing the web-connection.
• I can test for attackers who are submitting key/value pairs that couldn't come from a innocent use of the my own form. [After all, an attacker can bypass the form entirely, and still submit to the form-handler!]

Real-world note: curl

in addition to running such programs entirely separate from web, a web-firm would also want to auto-test their pages w/o needing to go to the URL from a browser "manually". So, you'd run `curl`, which is a *program* that can request URLs (including headers and form-data). That way you can fully automate your test suite: make `curl` requests with different form data, and then have a program that examines the resulting html to make sure certain things do/don't appear in it.]

Examples: Here are php programs which simply initialize $_POST, and then require the form-handler. Recall the sample form from last lecture (and recall what happens when it submits). Then, inspect:

• formB-handle-test-1_php.txt source; results.
• formB-handle-test-2_php.txt source (alternate init syntax); results.
• formB-handle-test-0_php.txt source (degenerate sample); results.
• formB-handle-test-3_php.txt source; results.

Awesome sauce: We can run these handler-tests locally, or over the web. The former is useful when the latter isn't showing up as expected.

home—lects—hws
D2L—zoom (snow day)

This page licensed CC-BY 4.0 Ian Barland Page last generated

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu