action of the form$_GET and $_POST<form method="post">
get, the browser discards the already attached parameters from action and then adds all the fields of the form to it
/assets/09/examples/1.pizzapalace/v1-querystring →
On each page, extract the form parameters from $_POST, and add it to the action of the form. Remember to urlencode() them!
On the following pages, extract the values to persist from $_GET and re-add them to the form
On the final page, all parameters can be found in a combination of $_GET and $_POST
?loggedin=true parameter to the querystring is not secure$_GET or $_POST, depending on the method used
/assets/09/examples/1.pizzapalace/v2-hiddenfields →
On each page, extract the form parameters from $_GET or $_POST, and add it as a hidden field in the form.
On the following pages, extract the values to persist from $_GET or $_POST and re-add them to the form
On the final page, all parameters can be found in either $_GET or $_POST, depending on the form method used.
$_GET: limit of querystring$_POST: limit set by server
echo ini_get('post_max_size');
loggedin=true hidden field is not securename=value pairsnamevalueexpirespathdomainsecurename and value
expires
time() + 60*60*24*7time() - 1
time() - 60*60*24*7path
/admin can't be read from /
domain
www.ikdoeict.be instructs a cookie to be created for ikdoeict.be, then that cookie can also be read from student.ikdoeict.be
secure
falsesetcookie()
name and value are mandatorysetcookie('color', $theValue, time() + 24*60*60*7);
$_COOKIE
$_GET and $_POST, but for cookies$color = (string) isset($_COOKIE['color']) ? $_COOKIE['color'] : '#FFFFFF';
/assets/09/examples/2.sitecolor/v1-delay →
Although the code looks OK, someting odd is happening: the color changes indeed, but with a one-page delay. Refreshing the page in the browser seems to fix this too
The problem relies in the fact that setcookie() doesn't create a cookie, but sends an instruction to create one. At the time the page is being rendered, the cookie hasn't change yet (as the browser creates the cookie when the HTML's already been rendered)
/assets/09/examples/2.sitecolor/v2-forcedrefresh →
By using a header('location: ...'); we can enforce a refresh from within our PHP code. That way, when the page reloads, the cookie will be present.
PHPSESSID
$_SESSION with themsession_start();
PHPSESSID in $_COOKIE, $_GET, or $_POST
$_SESSION is populatedsession_start();
$_SESSION['name'] = 'Bramus!';
session_start();
$name = isset($_SESSION['name']) ? $_SESSION['name'] : 'stranger';
session_start();
unset($_SESSION['name']);
session_start();
// Best practice: unset all session vars before stopping the session
foreach ($_SESSION as $key => $value) unset($_SESSION[$key]);
session_destroy();
session_start();
echo '<a href="nextpage.php?PHPSESSID=' . session_id() . '" title="to next page">to next page</a>';
php.ini setting
session.use_cookies = 1
// path where sessions are saved on the server
session.save_path = /tmp
// name of the session id variable
session.name = PHPSESSID
// use cookies for storing the session id?
session.use_cookies = 1
// exipiry time of the cookie. Default value: when the browser closes
session.cookie_lifetime = 0
// expiry time of session variables
session.gc_maxlifetime = 1440
/assets/09/examples/4.login/v1 →
The login page is very simple for this proof-of-concept: any login where the username equals the password is accepted
If the login validates, a user object typically the result of a database query is stored in the session, along with the name
The content pages use a simple if to display the $_SESSION['user']['username'] or a request to log in
The logout page simply destroys the session and redirects to the index
A code-only summary of this chapter is available at 09.persistence.summary.html