translated by Google

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, 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 .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 ( https://www.fi.muni.cz/~uzivatel/ ) and the group that this user has as primary (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 /tmp .

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 https://www.fi.muni.cz/~uzivatel/tento_skript.cgi?stroj=aisa , its output will output the command host aisa . (More about bashlib on bashlib .)

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 /~uzivatel/ , runs under your identity . So if you make a security error 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 Scripts

We 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 apachefi the script will not set some environment variables (typically PATH , 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 your browser.

Debug Shell Scripts:

  • Just behind the introductory #!/cesta/k/interpretu (e.g. #!/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 .
What to do if it still does not work:
  • Read this page again.
  • Recheck if you have the right access rights to the directory ~/public_html and nested (for details see page about user HTML pages .
  • Recheck if the CGI has a suffix script .cgi .
  • 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. Where are the logs stored?
  • Consult with more experienced colleagues.
  • Consult with administrators.