What is a CGI script?
The CGI script is a program created by you that allows you to generate dynamic WWW pages, that is, pages that may appear differently each time you open them. The content may depend on the current time, the content of the different files, the address of the computer from which the page is visited,
How to Create a CGI Script
The CGI script is any executable file (usually a script - hence the naming), which when executed on the standard output lists the HTTP header of the page (do not confuse with the HTML header) and then its own content . It can be classic text in HTML, but also any other type of data.
The script should generate at least a header
Content-Type: followed by a blank line denoting the end of the header. Example of a simple shell CGI script:
#!/bin/bash # echo "Content-Type: text/html" echo echo "<body>" echo "prvni pokusna stranka" echo "<pre>" date echo "</pre>" echo "</body>"
/bin/bash is the entire path to the interpreter to run the script on the server. It can be Bash, Perl, PHP or another. Be careful, however, if you write your pages and scripts in editors or on systems where a character is stored at the end of the lines
CR (Ctrl-M, ^ M) - typically windows programs. Then there would be no program
bash in the directory
/bin , but some sort of program
bash^M , which of course does not exist.
Content-Type: is in this case
text/html , which for the WWW server means that the CGI script generates an HTML page. If the script generated a picture,
Content-Type would be, say,
The CGI script must be executable on Aise. In order for a WWW server to recognize that it is a CGI script, the
.cgi extension must have the script. Programmers in Perl will certainly welcome the module
CGI.pm , which makes it easier to create and parse forms.
User CGI scripts available under / ~ user /
The CGI script must be executable by the owner. If this is not a binary program but a script itself, it is also necessary to set the right for the owner to read it.
Scripts are triggered by the mechanism
suexec , which allows the script to run under the identity of the owner. It also checks certain security conditions. The basis is: The script must belong to the user, which is listed in the URL (
uzivatel/ ) and the group that this user has as the primary one (can be identified by the command
id ). Script or parent directory must not be allowed to write to group and others.
CGI scripts stored outside the tree / ~ user /
These CGI scripts must be executable (permissions
x ) by apachefi; if this is not a binary program but a script, you need to have the right to read (
r ) by apaechefi. This can be accomplished by a command
setfacl -m u:apachefi:r-x skript.cgi . Running CGI scripts run under user identity
apachefi , so it is also necessary to customize the behavior of the script. Typically, for example, this user can only write to the directory
Special variables in CGI scripts, working with URL parameters
The Web server sets several new variables you can work with in the CGI script. Whichever you are, you can find out by following the example in
CGI Scripting Debugging Section . Especially, if you pass the CGI script parameters (GET method), they will be available in the variable
QUERY_STRING . In a shell CGI script, parsing can look like this:
#!/bin/bash . /packages/run.64/bashlib-0.4/bin echo Content-type: text/plain echo STROJ=$(param stroj) /usr/bin/host $STROJ
It saves this program into a variable
STROJ parameter value
stroj . So, if you call the program, use the URL
uzivatel/tento_skript.cgi?stroj=aisa , its output will output the command
host aisa . (More about bashlib on
If you pass parameters through the method
POST , the data is passed to the standard input of the CGI script.
CGI scripts and security
It is important to note that if the CGI triggered script is invoked in the subtree
runs under your identity . So if you make a security bug in the script, you may lose / modify your server data or misuse your identity. So always check the script before reviewing it, and be aware that somebody might try to test the robustness and resilience of your script manually. This concerns in particular the processing of parameters.
Please also keep in mind that the examples given on this page are for illustration only (to be functional) and may not be written in a safe manner. Before writing CGI scripts, we recommend that you read something on the web about this issue.
Debugging CGI ScriptsWe recommend that you first run the CGI script from the command line directly on Aise. Here, you can capture, for example, interpreter error messages. It is very likely that after launching under the user
apachefithe script will not set some environment variables (typically
LD_LIBRARY_PATH, ...). For example, the current state of the variables when running a CGI script will tell you this code:
#!/bin/bash echo "Content-type: text/plain" echo set
Debug Perl scripts:
- Use it
use CGI, allowing you to debug scripts on the command line, including parameters.
- Use it
use CGI::Carp qw(fatalsToBrowser), which will display error messages in the browser.
Debug Shell Scripts:
- Just behind the introductory
#!/bin/bash) add a line
exec 2>/home/ uzivatel/public_html/stderr.log, which redirects the error output to a file.
- If you are using modules, you need to initialize them first. For more details, go to o modules .
- Read this page again.
- Recheck if you have the right access rights to the directory
~/public_htmland nested (for details see page about user HTML pages .
- Recheck if the CGI has a suffix script
- Re-review access rights to the CGI script and its relevant environment.
- Try again to run the CGI script manually on Aise from the command line.
- If the script works on a command line, but not when accessing the WWW, look at the WWW server logs for a possible cause. Logs can be found in the directory
- Consult with more experienced colleagues.
- Consult with administrators.