translated by Google

Machine-translated page for increased accessibility for English questioners.

What is a CGI script?

A CGI script is a program created by you 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 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 run on standard output, prints the HTTP header of the page (not to be confused 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 indicating the end of the header. An example of a simple CGI script written in a shell bash :

#!/bin/bash

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

Here /bin/bash is the full path to the interpreter to run the script on the server. It can be Bash, Perl, PHP or something else. However, be careful if you write your pages and scripts in editors or on systems where the character is stored at the end of lines. CR (Ctrl-M, ^ M) - typically Windows programs. Then no program would be searched bash in the directory /bin but some kind of program bash^M which, of course, does not exist.

Content-Type: is in this case text/html , which means for the WWW server that the CGI script generates an HTML page. If the script generated, for example, an image, Content-Type would be, say, image/gif .

The CGI script must be executable on Aise. In order for the WWW server to recognize that it is a CGI script, the script must have a .cgi extension.

Custom CGI scripts available under / ~ user /

The CGI script must be executable by the owner, which you can do with the command:

chmod u+x ~/public_html/skript.cgi

If it is not a binary program, but really a script, you also need to set the read right by the owner.

Scripts are run using a mechanism suexec which allows the script to be executed under the identity of the owner. It also checks some security conditions. The basis is: the script must belong to the user specified in the URL ( https://www.fi.muni.cz/~ uzivatel/ ) and the group that this user has as primary (can be found by the command id ). Neither the script nor the parent directory must be write-enabled 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 the right to read ( r ) by apaechefi. This can be achieved by a command setfacl -m u:apachefi:r-x skript.cgi . Running CGI scripts run under a user identity apachefi , and it is therefore necessary to adapt the behavior of the script. Typically, for example, this user can only write to the directory /tmp .

Special variables in CGI scripts, working with parameters in URLs

The web server sets several new variables that you can work with in the CGI script. You can find out which ones they are by following the example given in section on debugging CGI scripts . Especially if you pass parameters to a CGI script (GET method), they will be available in the variable QUERY_STRING . In a shell CGI script, the processing of parameters may 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

This program stores it in a variable STROJ parameter value stroj . Therefore, if you call the program using a URL https://www.fi.muni.cz/~ uzivatel/tento_skript.cgi?stroj=aisa , its output will be the output of the command host aisa . (More on bashlib at bashlib .)

If you pass parameters by 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 a running CGI script is invoked in a subtree / ~uzivatel/ , runs under your identity . Therefore, if you make a security error in the 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 take into account that someone may try to test the robustness and resilience of your script manually. This applies in particular to parameter processing.

Also keep in mind that the examples provided on this page are illustrative only (though not functional) and may not be written securely. Before you start writing CGI scripts, we recommend that you read something about this issue on the web.

Debugging CGI scripts

We recommend that you first try to run the CGI script from the command line directly on Aise. Here you can catch, for example, artist 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, the following code can find out the current state of variables when running a CGI script:
#!/bin/bash

echo "Content-type: text/plain"
echo
set

Debugging Perl scripts:

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

Debugging shell scripts:

  • Right after the opening #!/cesta/k/interpretu (e.g. #!/bin/bash ) add a line exec 2>/home/ uzivatel/public_html/stderr.log which redirects error output to a file.
  • If you use modules, you need to initialize them first. See page for more details modules .
What to do if it still doesn't work:
  • Please read this page again.
  • Double check that you have the correct access rights on the directory ~/public_html and nested (for details see page about custom HTML pages .
  • Double check that the CGI script has an extension .cgi .
  • Recheck the access rights to the CGI script and its relevant environment.
  • Again, try to run the CGI script manually on Aise from the command line.
  • If the script works on the command line, but not when accessed through the Web, look in the Web server logs for a possible cause. Where are the logs stored?
  • Consult with more experienced colleagues.
  • Consult the administrator.