|
|
6. PHP Examples
|
| |
These examples do represent a range of issues involved
in CGI programming using php and codewrap. I'm not
very knowledgable with php, but I hope they are
useful in getting started.
They are in no sense
complete, and make no effort to deal with issues of
php that do not relate somehow to CGI. Caveat Emptor
|
|
| | | |
| |
|
| |
|
|
|
Example 1 -- Trivial Case
|
| |
This script simply prints out 'hi'. Note:
- The url. This url corresponds to a file on tigger, whose full path is
/usr/local/etc/httpd/htdocs/depts/accc/webpub/cgi/cgi-bin/example1.php
|
|
| |
|
|
|
Example 2 -- Authentication
|
| |
This script shows how to force the user to use bluestem authentication.
Important points:
- The authenticated netid appears in the
$_ENV['REMOTE_USER']
- The url must start with https, and
you must use codewrap-auth.
- If the user tries to circumvent authentication, then
$_ENV['REMOTE_USER'] will not contain a value.
The script can take appropriate action, either by issuing
an error message or by issuing a redirection.
- Using the variables
$_ENV['SERVER_NAME'] and
$_ENV['SCRIPT_NAME'] to reconstruct the url
is good programming. Every now and then, you may copy
a script or move it to a new location. This code is nicely portable.
|
|
| |
|
|
|
Example 3 -- Debugging
|
| |
PHP is easier to debug on the web, because it will send its error messages
to the browser. But on occasion, you may want to use the codewrap-d
debugging to see some info about the codewrap environment. This example
shows what happens if you refer to a php script that doesn't exist.
(See Example 4 for a better debugging example.)
|
|
| |
|
|
|
Example 4 -- Reading/Writing Files and Debugging
|
| |
PHP is configured to allow local i/o of files, ONLY if the
files are below the last cgi-bin directory.
This example shows the error if you try to read or write a file
you should be leaving alone.
This example tries to violate the restrictions.
BTW, writing files from a CGI script is no different than from
any other program. However, file locking is more important.
It's quite possible for a CGI script to be
invoked several times simultaneously, and for each of
these invocations to write to the same file. However,
if you are careful to lock and unlock the file properly,
this is not a major problem.
- Use the full path, for both commands and files.
- Check return codes. Don't assume that everything works all the time.
- Keep the output file locked as little as possible.
|
|
| |
|
