=====
CS 328 - Week 13 Lecture 1 - 2026-04-19
=====
=====
TODAY WE WILL
=====
* announcements
* intro to PHP sessions
* prep for next class
=====
* should be working on Homework 10!
* deadline: 11:59 pm on Friday, April 24
* START now, NOT later in the week!
* submit files OFTEN, THROUGHOUT the week!
=====
* IT IS PREREGISTRATION for SUMMER 2026/FALL 2026!
* preregistration for SUMMER 2026 is open NOW for
***EVERYONE***!!!
* preregistration for FALL 2026 begins at your
registration appointment in your student center
(sometime between April 13 - April 24)
=====
REMINDER: HTTP/HTTPS are STATELESS
=====
* Reminder:
* HTTP: HyperText Transfer Protocol
* HTTPS: HyperText Transfer Protocol Secure
* in "plain" HTTP/HTTPS,
a HTTP/HTTPS request/response pair is INDEPENDENT of all others!
* that is,
there is no way to associate a request with a PREVIOUS request!
Browser ---> Web Server # 1st request
Browser <--- Web Server # that 1st request's response
Browser ---> Web Server # 2nd request, INDEPENDENT of 1st request
* BUT -- there are ADD-ONS and KLUGES for attempting to relate
requests -- because user interfaces are more smooth if users
don't have to enter ALL the info they've entered so far for
EACH step in a "logical" task;
* That is, it is USEFUL to be able to somehow save STATE
between requests from client tier to application tier
in a more-than-two-logical-steps application!
* Numerous application-tier languages have devised
ADD-ON means and features for saving
application-state information BETWEEN
request/response pairs,
to KLUGE "adding on" such state to basic STATELESS HTTP/HTTPS
* many of these means involve cookies...
* Yes, PHP provides such support!
* PHP provides features to support cookie-based SESSIONS,
an add-on to save useful state between the logically-related
requests from a multi-state application;
* PHP hides the gruesome details and provides another
superglobal associative array, $_SESSION,
to hold such application-state information
=====
more on the PHP superglobal associative array
$_SESSION
=====
To get ACCESS to $_SESSION:
*********
* IMPORTANT: if you wish for your PHP application to use sessions,
*********
CALL the function:
session_start();
EARLY in your PHP document;
* from the PHP Manual page for session_start(),
https://www.php.net/manual/en/function.session-start.php
"Note:
To use cookie-based sessions, session_start() must be called before output
outputting anything to the browser."
* (because session_start() adds info to the header in the
response)
* remembering that the PHP engine executes the PHP tags before sending the
resulting HTML to the web server to send to the browser,
it IS fine, then, to have a PHP tag calling session_start()
before the HTML's document's document type definition in your
.php document
* If it is the 1st request for a session,
session_start() will create the $_SESSION array and assign
a session id.
The response from that PHP includes the session id along with its
response.
Then, the next request from the browser will include that session
id along with the request.
SO:
* once you have called session_start(), NOW you have access to yet
another PHP superglobal associative array, $_SESSION, for the rest of
that PHP document;
* for most PHP superglobal associative arrays, your PHP
documents are NOT to muck with their contents -- they should
just USE them (e.g., $_POST, $_SERVER)
* $_SESSION is a deliberate EXCEPTION to this --
your PHP document can ADD and REMOVE and CHANGE keys and
their contents in the $_SESSION array!
and it SHOULD do so to help perform desired tasks for
the user!
* want to add a new key to $_SESSION?
just do it!
$_SESSION["moo"] = "cow sound";
* now "moo" is a key in $_SESSION,
and the value of the expression $_SESSION["moo"] is "cow sound"
* and it is fine to CHANGE the value for a particular key:
$_SESSION["moo"] = "sound of cow";
* the value of the expression $_SESSION["moo"] is now "sound of cow"
* and of course you can reference what has been put there;
$desired_variable = $_SESSION["moo"];
* the value of the expression $desired_variable is now "sound of cow"
=====
session_destroy() - when you are DONE with a logical session!
=====
* WHEN the logical session is complete,
your PHP *SHOULD* call:
session_destroy();
^^^^^^^^^^^^^^^^^^
* and this is a CS 328 class style standard...!
* it WILL eventually time out if enough time passes, BUT...
* ...it is considered good practice to explicitly request that the
logical session be destroyed when it reaches its logical end
* IF for some reason you want to get rid of the current session
and immediately begin a new session, you need to REGENERATE
a NEW session ID and restart:
session_destroy();
session_regenerate_id(TRUE);
session_start();
=====
additional NOTES about PHP $_SESSION array!
=====
* BECAUSE of the nature of session attributes and values,
$_SESSION is not intended for long-term value storage!
It is intended for STATE info it is convenient to
know during a multi-step task or logical session
* also note: do not try to save an OCI connection object
in $_SESSION! (doesn't work, and is a bad idea anyway...)
* each call to a PHP postback should close any connections
before it completes its response!
(and this is a CS 328 class style standard!)
=====
WHAT can go in a $_SESSION array?
=====
* info from earlier in a session that you want later
* for example, form info read from $_POST in one state
can be saved in $_SESSION for use in a later state
* info to keep track of the current or next state
(helpful!)
* for example, you might add a $_SESSION key "next_state"
whose value represents what the next state SHOULD be
=====
PHP SESSION-SANITY HELPERS
=====
* draw a FINITE-STATE DIAGRAM to describe your desired web application's
behavior!
* (see posted example for try-quad.php)
* have a helper function for each state in your application
logic
* have the first version of each be a STUB, a little
working version of the function that just
proclaims what you called
* (and including an anchor element to
your PHP to continue is also useful!)
* START the postback PHP for your application with an if-elseif
that just lays out the order these will be called,
setting up the $_SESSION key to keep track of the current state
=====
* try-quad.php - by the end of the Week 13 Lecture 1 class,
this just has such stubs,
and such setting up of a $_SESSION key "next_state",
BUT note that you can try it out and "walk" through the expected
logical session
* we'll REPLACE these stub functions with actual desired behavior
next class!
* a USEFUL pattern we will be practicing as we do so:
* as you are writing the function FOR a state in your application:
* IF this state responds to a submitted form whose method="post",
be sure to GRAB (and SANITIZE!!) what has JUST been submitted
from $_POST
* IF what it has grabbed-and-sanitized from $_POST might be
USEFUL for a later state, ADD that information to $_SESSION
* IF this state needs something from a previous state (besides
the information from the JUST-submitted form), can hopefully
GRAB that from $_SESSION
* IF something this state is doing might be needed in a LATER
state, ADD it or UPDATE it accordingly in $_SESSION