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 site 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 :


echo "Content-Type: text/html"
echo "<body>"
echo "my first example page \o/"
echo "<pre>"
echo "</pre>"
echo "</body>"

Here /bin/bash is the full path to the interpreter that should run the script on the server. It can be Bash, Perl, PHP or anything 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 the lines. CR (Ctrl-M, ^ M) - typically windows programs. Then no program would be sought 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. The script must have a .cgi extension for the web server to recognize that it is a CGI script.

Custom CGI scripts available under / ~ xlogin /

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

chmod u+x ~/public_html/script.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 owner's identity. It also checks some security conditions. The basis is: the script must belong to the user specified in the URL ( xlogin/ ) and the group that this user has as the primary (can be found by the command id ). Neither the script nor the parent directory must be write-enabled for the group and others. Suexec logs its activities to a file /var/log/httpd-user/suexec . In case of unsatisfied safety conditions, you will read here the specific cause of the failure.

CGI scripts stored outside the tree / ~ xlogin /

These CGI scripts must be executable (permissions x ) by apachefi; if it is not a binary program, but a script, you need to have read permission set ( r ) by apaechefi. This can be achieved by a command setfacl -m u:apachefi:r-x script.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 URL

The web server sets several new variables that you can work with in the CGI script. You can find out which ones are by following the example given in section on CGI script debugging . Especially if you pass CGI script parameters (GET method), they will be available in variables QUERY_STRING . In a shell CGI script, the processing of parameters may look like this:

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

echo Content-type: text/plain

HOST=$(param host)

/usr/bin/host $HOST

This program stores in a variable HOST parameter value host . Therefore, if you call the program by URL xlogin/this_script.cgi?host=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 / ~xlogin/ , 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 anticipate that someone may be trying to test the robustness and resilience of your script. This applies in particular to parameter processing.

Also keep in mind that the examples provided on this page are for illustrative purposes only and may not be written safely. 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:

echo "Content-type: text/plain"

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.

Shell script debugging:

  • Right after the opening #!/path/to/interpreter (e.g. #!/bin/bash ) add a line exec 2>/home/ xlogin/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:

  • 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.
  • Try to run the CGI script again manually on Aise from the command line.
  • If the script works on the command line, but not when accessed via 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.