If we now change the value of the action attribute to
"destin3.php?snumber=100&spassword=abcdefg&lect=Henry Carter"
the output changes to
We can see that if there are confl icting values for a variable set in $_POST and
$_GET the value stored in $_REQUEST is the one in $_POST.
10.4 Passing Values to PHP Scripts Using Session Variables
Although textbooks on PHP necessarily illustrate the language's facilities using small-scale examples it is important to bear in mind that many large commercial sites will have many pages and as the user proceeds to (say) make a purchase he or she may move from one to another, to a third, back to the second, then to a fi fth and so on.
10.4 Passing Values to PHP Scripts Using Session Variables
Sometimes one PHP generated web page will include a link to another or a web form that will jump to another page when Submit is pressed. Sometimes a page will jump to itself with different values or even invisibly jump to another page using the header function described in Chap. 5 . In order for the site to 'keep track' of what is going on a great deal of information may need to be transmitted from one page to the other, most of it meaningless to the user. This can be done using hidden values in a web form or by values passed in URLs but when the number of variables is at all large these methods can become very cumbersome to use.
Many sites get round this by storing data values, known as cookies on the user's PC. PHP does it by using session variables held on the server. This involves storing just one meaningless value on the user's PC, which many may fi nd a more accept-able approach than using cookies. The fi rst PHP script creates a session and then generally writes some values to a PHP system associative array named $_
SESSION. The next page can then use the values in $_SESSION even though it did not create it. It can also change values, delete them or add new ones. The fi nal page destroys the session. It is all a little more complex than this but not much.
To illustrate the process in detail we have created some small test scripts named sess1.php, sess2.php etc. They are listed below. We will go through a possible sequence of events step by step.
Script sess1.php
The user points his/her web browser to sess1.php. As the script is executed PHP comes to the instruction session_start(). This has to be placed before any HTML and before any output is generated using PHP print statements. This is most important.
The PHP system now checks if there is a session value stored on the user's PC. At this point there is not so it writes one with an obscure value such as
b7cdfg12ab7802dfg. Next the assignment statements in the script place values in the $_SESSION array, just as if it were any other associative array. This and all our later scripts go on to use a foreach statement to display the contents of $_SESSION so we can see exactly what has been stored. (Incidentally, the reason for the test 'if ($_SESSION!="")' is that if nothing is stored PHP treats $_SESSION as an unini-tialised variable not an array, so the foreach instruction will lead to a fatal error.) For sess1.php the output produced is as follows:
171
In practice the script will no doubt perform many other (more valuable) opera-tions, but these are of no concern to us for this example. Eventually it gives the user a link which they press to move to sess2.php. Or perhaps the script simply comes to an end and the user opens a second web browser and points it to sess2.php, it makes no difference which. Script sess2.php now comes into operation.
Script sess2.php
The script comes to the session_start() instruction (which, as always, must be before any HTML or PHP print instructions have been sent to the browser). This time the browser checks and fi nds that there is already a session value such as b7cd-fg12ab7802dfg stored on the user's hard disc. It therefore gives the PHP script access to the values in the $_SESSION array. It now uses two of the values already set: staffage and stafftitle, and sets a new one: compref. The foreach instruction shows the values that are now stored and of course accessible to the script.
Next the user clicks on a link which opens a replacement browser window, point-ing at sess3.php.
Script sess3.php
10.4 Passing Values to PHP Scripts Using Session Variables
The script now sets a further variable staffcode to "Sci387" and unsets stafftitle.
The foreach instruction now gives this output.
After more processing the script displays a web form. The user completes it and presses the Submit button. A new script sess4.php opens in the same browser window.
Script sess4.php
This script shuts the session down. We do this in two steps: fi rst unset all the variables and then destroy the session. (The fi rst of these is not needed in this case, but is included to illustrate how to do it.) The session_destroy() instruction causes the stored value b7cdfg12ab7802dfg to be removed from the user's hard disc.
Finally the foreach statement produces no output, showing that the session has ended.
173
Practical Exercise 10
Write a PHP script to serve as a destination page for the webform shown towards the end of Sect. 10.2 . If all the compulsory fi elds have been completed and the uploaded fi le is in PDF format the script should save the fi le to folder 'projects' with a name that includes the project reference and the student number. (For the purpose of this exercise it is not necessary to check that the password entered matches the student number or that the maximum fi le size restriction has been met.)
Chapter Summary
This chapter describes how to implement a destination page which receives values sent to it by a webform, as described in Chap. 9 . The use of system associative array $_POST is explained. The values sent by a webform if a form element is given no value (and has no default value) are also considered.
It is next shown how to check for compulsory values and to test whether val-ues entered are numbers or integers.
Complications which arise in connection with multiple selections from a webform selection box are described, followed by the potentially diffi cult issue of dealing with an uploaded fi le. This leads to a description of system associative fi le $_FILES, the 'type' values associated with common fi le exten-sions such as doc, docx and xls, and how to establish the fi le type of an uploaded fi le.
Quote symbols in text fi elds and textareas can present security problems and it is shown how these can be handled. The chapter goes on to illustrate another way of sending the values of variables to a destination script, using an extended URL, and the use of the system associative arrays $_GET and $_
REQUEST in the destination page.
The chapter ends with a description of a method of passing variables around PHP scripts that is often used with larger websites: using session variables.
10.4 Passing Values to PHP Scripts Using Session Variables
175
© Springer International Publishing Switzerland 2015 M. Bramer, Web Programming with PHP and MySQL, DOI 10.1007/978-3-319-22659-0_11
PHP in Action: Managing a Members' Area
Chapter Aims
After reading this chapter you should be able to:
• use the material introduced earlier in the book to write useful PHP scripts, especially to deal with information sent from a webform and to create, read and analyse the content of text fi les.
This chapter is designed to reinforce the material in Chaps. 7 and 9 about text fi les and webforms as well as illustrating a number of programming techniques and the use of several of the functions described earlier.
Like many other organisations the Erewhon Society has a members' area on its website. This is a password-protected area containing information about Society events, plus possibly pictures and video clips for downloading, technical or profes-sional advice particularly relevant to Society members etc. Having access to this area is seen as a major benefi t of Society membership. So it needs to be protected from prying eyes.
A members' area is a feature of many organisations' websites but it is desirable not to keep the whole of your website secret (unless you are representing an inter-national criminal organisation or a secret government agency perhaps) as the pub-licly accessible pages are your organisation's 'shop window', a place to attract new members to join, so the members' area should not normally be the whole of the site.
176