=====
CS 328 - Week 9 Lecture 2 - 2026-03-25
=====
=====
TODAY WE WILL
=====
* announcements
* APPLICATION TIER - continue intro to PHP
* whirlwind tour of PHP needed to respond to
a FORM
* prep for next class
=====
* should be working on Homework 7!
* deadline: 11:59 pm on Friday, March 27
* submit files EARLY and OFTEN!
* coming soon: zyBooks Chapter 5 on PHP fundamentals
* will send a class e-mail when linked from Canvas
* should be well-along on zyBooks CSS Chapters 3-4 at
this point, if have not already completed those
activities;
=====
PHP command line interface (CLI)
=====
* you can run PHP from an application-tier command line
* (this is more useful some times than others...)
* but, on a computer with PHP installed,
(such as nrs-projects),
in a terminal, you can run a PHP script using:
php desired_file.php
* the document created by this PHP will be output to
standard output
* (so you CAN redirect that to a file as well:
php desired_file.php > looky.txt
...and looky.txt will contain the result from execusting
this PHP document)
* this can sometimes be useful in debugging --
you might see an error message that is not being sent
to the web browser...
* IMPORTANT CAVEAT: without additional kluges, this
does NOT appear to have access to the superglobal
associative arrays mentioned later in these notes;
=====
PHP named constants
=====
* in some ways, what you expect:
* once assigned a value, they CANNOT be changed
* ALSO are case-sensitive,
and COMMON style is to write in ALL_UPPERCASE
* but, more quirkily:
* DON'T use $ in a named constant's name!
* there are TWO ways to define a named constant:
const DES_CONST_NAME = desired_expr;
define("DES_CONST_NAME", desired_expr);
* for example:
<?php
const MAX_TEMP = 100;
define("MIN_TEMP", 0);
?>
<p> Desired range for acceptable temperatures:
[<?= MAX_TEMP ?>, <?= MIN_TEMP ?>] </p>
=====
PHP if statement
=====
* one of its if-statements:
if (bool_expr)
{
statement;
...
}
else
{
statement;
...
}
* (but, if expression given to if not actually of type bool,
it will be treated a bool based on the guidelines mentioned last
class...!)
* CAN use elseif, but you can also use else if
* and you can "jump" in and out of PHP throughout
the if statement...!
* (this will be the case of other PHP statement
types as well!)
* See the if statements in 328lect09-2.php
* note: == is true if its operands are the same value
(even if they aren't the same type)
=== is true if its operands are the same value AND
the same type
=====
postback PHP
=====
* a single PHP document that handles different parts of a small
application;
for example, if requested one way,
its reponse might include a form,
and if that form is submitted,
its response might handle that submitted form;
* FUN FACT: when you request a document from a browser,
by default that is considered to use method get
* SO one can use this in a simple postback PHP
such that it assumes, if requested with method of get,
it includes a form in its response, a form with
method="post",
and so if requested with a method of post,
it tries to respond to that form in its response
* so, in a PHP document, how can I see how that document
was requested?
Using one of PHP's superglobal associate arrays!
=====
PHP Superglobal Associative Arrays
=====
* a set of PHP special global variables that are arrays
and are visible in all PHP code
* superglobal: a PHP global variable visible in all PHP code
* associative array: keys in this case are strings
* PHP convention: these variables' names are ALL_UPPERCASE
and start with $_
* One of these superglobal associate arrays
is named $_SERVER
and its key "REQUEST_METHOD" will be either "GET" or "POST"
(depending on how this PHP document was just requested)
if ($_SERVER["REQUEST_METHOD"] == "GET")
{
// generate a form with method="post"
}
else // assume method was POST
{
// respond to previously-generated form
}
* fun fact: in $_SERVER, the key "PHP_SELF" to get the
URL of the requesting document
<form method="post"
action="<?= $_SERVER["PHP_SELF"] ?>" >
but this is possibly prone to cross-site scripting,
so one should sanitize it;
* PHP provides a number of useful functions to help with
sanitizing input from users!
* htmlentities - expects a string, returns that string with
any special characters encoded into non-executable versions
* htmlspecialchars - does this for just special characters that
are HTML-specific
* strip_tags - expects a string and REMOVES anything within that
follows tag syntax and returns the resulting string
* this, then, is RECOMMENDED for the action attribute for a form
created by a postback PHP (that it is expecting to later handle):
action="<?= htmlentities($_SERVER["PHP_SELF"],
ENT_QUOTES) ?>">
* another useful superglobal associative array:
$_POST - contains the name=value pairs from a submitted
form that had method="post"
* $_POST array's keys are the names of all
name=value pairs associated with that submission,
and the value at each key is the value of its name=value
pair
* (there's an analogous array $_GET for obtaining the name=value
pairs from a form submission that has method="get")
* AND YOU ALWAYS CHECK and/or SANITIZE ANYTHING IN THE
$_POST (or $_GET) ARRAYS BECAUSE THESE VALUES COME FROM
THE USER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
* and an application tier programmer should NEVER trust
values coming from the user!!!!!
* Because one really CANNOT stress this enough:
=====
IMPORTANT: ON THE APPLICATION TIER,
****** NEVER TRUST ****** user-provided data!!
=====
* cross-site scripting! SQL injection! and more!
* MANY dangers are possible, and we'll be discussing at least some of
them as the semester continues!
* IN THE MEANTIME: note that application-tier especially (and also
data-tier) programmers CANNOT and SHOULD NOT trust client-tier
provided data, EVER.
* what if you wrote a beautiful form with all kinds of HTML and
client-side JavaScript error checking?
* doesn't matter -- a rogue user can write their OWN HTML page
that happens to, for example, make a request to your form's
action attribute value! (that is: NOT coming from YOUR form,
but providing its own custom name=value pairs BASED on your form
but with ROGUE values...)
* don't USE info from the $_POST (and $_GET) without somehow CHECKING
and SANITIZING it first!!
HOW? ...varies, based on the situation and the potential dangers!
* maybe using an if or select statement that CHECKS the value first!
or that only acts if the value is one of a small set of expected
values (and throws an error otherwise)
* maybe using PHP functions to sanitize the user-provided value before
using it -- functions such as those mentioned earlier:
* strip_tags - expects a string, returns that string with <*> </*>
tags removed
* htmlspecialchars, htmlentities - expects a string (and possibly more),
returns that string with possibly-executable characters replaced with
display-only versions
* trim - expects a string, returns that string with any leading or
trailing blanks removed
* info from $_SERVER can even be compromised, and that's why we mentioned
the recommended way of using $_SERVER["PHP_SELF"] in a form's action
attribute -- again, that is:
<form method="post"
action="<?= htmlentities($_SERVER["PHP_SELF"],
ENT_QUOTES) ?>">
=====
our first server-side include function
=====
* server-side include?
...lets you include a file's contents into your result
on the server-side -- on the web server side, in this case!
* PHP actually has FOUR different server-side include functions...!!!
* Mentioning arguably the most useful of these:
PHP function require_once expects a file name,
and outputs the contents of that file into your PHP response!
* require_once will give a FATAL error if it cannot
find and access that file
* require_once will ONLY include that file's contents
ONCE in the PHP's result (even if you accidentally call
require_once more than once for that file...)