translated by Google

Machine-translated page for increased accessibility for English questioners.

What is a CGI script?

A CGI script is a program you create that allows you to generate dynamic web pages, ie pages that may look different each time they are opened. The content may depend on the current time, the content of the various files, the address of the computer from which the page is visited, etc.

How to Create a CGI Script

A CGI script is any (server-side) executable file (usually a script - hence the name) that, when executed on standard output, writes the HTTP header of the page (not to be confused with the HTML header) and then its own content . This can be classic HTML text, but also any other type of data.

The script should generate at least a header Content-Type: followed by a blank line that denotes the end of the header. Example of a simple shell CGI script:

echo "Content-Type: text/html"
echo "<body>"
echo "prvni pokusna stranka"
echo "<pre>"
echo "</pre>"
echo "</body>"

/bin/bash is the entire path to the interpreter that should run the script on the server. It can be Bash, Perl, PHP or anything else. Be careful, however, if you write your pages and scripts in editors or systems where you also store a character at the end of the lines CR (Ctrl-M, ^ M) - typically Windows programs. Then a program would not be sought bash in the directory /bin but a kind of program bash^M which, of course, does not exist.

Content-Type: is in this case text/html , which means that the CGI script generates an HTML page. For example, if a script generates an image, Content-Type would be, say, image/gif .

The CGI script must be executable on Aise. For a Web server to recognize that it is a CGI script, the script must have a .cgi extension. Perl programmers will certainly welcome the module , which makes creating and parsing forms more enjoyable.

Custom CGI scripts available under / ~ user /

The CGI script must be executable by the owner. If it is not a binary program but a script, you must also set the owner's read right.

Scripts are triggered by a mechanism suexec , which allows the script to be run under the owner's identity. It also checks some safety conditions. The basis is: the script must belong to the user specified in the URL ( uzivatel/ ) and the group that this user has as primary (can be identified by the id ). The script or parent directory must not have write permission for the group and others.

CGI scripts stored outside the tree / ~ user /

These CGI scripts must be executable (permissions x ) by apachefi; if it is not a binary program but a script, it is necessary to have set the read right ( r ) by apaechefi. This can be achieved with the command setfacl -m u:apachefi:r-x skript.cgi . Running CGI scripts run under the user identity apachefi , and the script's behavior needs to be adapted accordingly. Typically, for example, this user can only write to the directory /tmp .

Special variables in CGI scripts, working with URL parameters

The web server sets several new variables that you can work with in the CGI script. You can find out what these are by using the example in section about debugging CGI scripts . Specifically, if you pass CGI script parameters (by GET method), they will be available in variables QUERY_STRING . In a shell CGI script, parameter processing might look like this:

. /packages/run.64/bashlib-0.4/bin

echo Content-type: text/plain

STROJ=$(param stroj)

/usr/bin/host $STROJ

This program saves the variable STROJ parameter value stroj . So if you call the program using URL uzivatel/tento_skript.cgi?stroj=aisa , it will output the command output host aisa . (More on bashlib at bashlib .)

If you pass parameters by method POST , the data is passed to the standard CGI script input.

CGI scripts and security

It is important to note that when a CGI script is executed in a subtree / ~uzivatel/ running under your identity . Therefore, if you make a security vulnerability in your script, your data on the server may be lost / changed, or your identity may be misused. Therefore, always check the script carefully before publishing, and be aware that someone may try to verify the robustness and resilience of your script yourself. This applies in particular to parameter processing.

Also, be aware that the examples on this page are for illustration only (although functional) and may not be written safely. Before you start writing CGI scripts, we recommend reading something on the web about this.

Debugging CGI scripts

We recommend that you first try running the CGI script from the command line directly on Aise. Here you can catch eg interpreter error messages. It is very likely that after running under the user apachefi the script will not have some environment variables set (typically PATH , LD_LIBRARY_PATH , ...). For example, you can find out the current status of variables while running a CGI script:

echo "Content-type: text/plain"

Debugging Perl Scripts:

  • Use it use CGI , which allows you to debug scripts on the command line, including parameters.
  • Use it use CGI::Carp qw(fatalsToBrowser) , which displays error messages to the browser.

Debug shell scripts:

  • Right after the opening #!/cesta/k/interpretu (e.g. #!/bin/bash ) to add a row exec 2>/home/ uzivatel/public_html/stderr.log that redirects error output to a file.
  • If you are using modules, you must initialize them first. For more details, see About modules .
What to do if it still doesn't work:
  • Read this page again.
  • Re-check that you have correctly set the directory access rights ~/public_html and nested (for details see a page about user HTML pages .
  • Recheck if the CGI script has an extension .cgi .
  • Re-check the 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 the command line, but not when accessing the Web, look in the Web server logs for a possible cause. Where are the logs stored?
  • Consult with more experienced colleagues.
  • Consult with administrators.