directory tree

For each of the web services the information is organised in two separate document "trees". One document tree is to contain the information that is accessible to the public without access controls. The second document tree will contain all other information to which access needs to be restricted.
The web servers will be configured to prevent per default all accesses to the information stored under the "/restricted" directory. The access control lists will then be configured to re-open access explicitely where needed.

• "public" information will be located under:

  /public

• "restricted" information will be located under:

  /restricted

Within each of these two document trees we will have the actual web server document tree (htdocs), the directory where the CGI scripts will need to be located (cgi-bin), and the directory tree where (temporary) data can be stored (work):

• now the "public" document tree extends to this:
  

  /public/htdocs
/public/cgi-bin
/public/work

• and the "restricted" document tree extends to:
  

  /restricted/htdocs
/restricted/cgi-bin
/restricted/work

The "htdocs" directories will contain all the HTML pages, CFML pages, PDF files, images, and other 'static' files that are to be served through the web server.
The "cgi-bin" directories will contain CGI scripts.
The "work" directories will contain data that is stored by CGI scripts, ColdFusion applications and other related programs. These directories will not be made directly accessible through the HTTP servers or FTP servers. If your web application requires write-access within one of the work sub-directories, please contact the webdesk to formally request the access permissions. Write access permission will be attributed to the userid that runs ColdFusion or to the userid that runs the web server (for CGI scripts).

important remark: please note that the real file paths are always preceded with the server name. For example, public EUROPA documents are stored under "/europa/public/htdocs". For IntraComm replace "europa" with "intracomm".
FTP users, however, will see this path as "/public/htdocs" instead.
This is especially important for CGI scripts and ColdFusion pages that refer to the work space. For example, the work space for a generally accessible ColdFusion application will be under "/europa/public/work".

The same directory structure exists both on the "staging" server, and the "dissemination" server.

dissemination servers and staging servers

The "dissemination" server is the actual web service that is used to make the information available to the public. Access to this information always goes through a reverse proxy server, as explained in the chapter on "working with reverse proxy servers".
In order to guarantee maximal data integrity and security we do not allow write access to the "dissemination" servers. The purpose is to enforce the rule that all informations that are made available to the public should be verified before they are being published.
This does not exclude the possibility for data entry through the dissemination servers. There are valid cases where members of the public should be able to enter information (e.g. surveys, questions, registering, ...). In these cases, the web site developers and maintainers should make sure that the entered data is not made available to the public without any form of validation.

The purpose of the "staging" server is to allow information providers to upload new and updated information, and to allow for the verification and validation of the information before the actual publication. Web browsers access the "staging" servers through reverse proxy servers as well.
Information providers can upload the information using FTP and their Central User ID (CUID), as described in the chapter on "uploading data". For security reasons, only information under the "htdocs" directories can be directly updated by information providers. New and updated CGI scripts can only be uploaded by the Data Centre webteam. 'Work' data can be accessed through CGI scripts and/or ColdFusion pages that have been created for that purpose.

for example, publishing on EUROPA

We'll use the EUROPA environment to clarify what is described above. The environment for IntraComm is identical.

The "staging" version of the EUROPA web service can be accessed using a web browser at "http://europa.eu.int:8082/". Behind this address hides a "reverse proxy server" that forwards all incoming HTTP requests to the appropriate (staging) web servers, and that returns the corresponding responses from those web servers to the requesting browsers.
The FTP server that is to be used to update information on the EUROPA staging server is located at "europa.staging.cc.cec.eu.int". This FTP server is configured with detailed access control definitions for each information provider.

A hypothetical Mr Grimm of an equally hypothetical DG responsible for fairy affairs has been assigned the task of maintaining the web pages under "http://europa.eu.int:8082/comm/fairy_affairs/".
Since these pages are to be made accessible to the public without any access controls, the DG Press' EUROPA team has configured the FTP server at "europa.staging.cc.cec.eu.int" to grant Mr Grimm's userid "grimmwi" write permission to the directory "/public/htdocs/comm/fairy_affairs" and its' contents.

Because Mr Grimm's web pages were found to comply with the rules laid down in the information providers guide, the EUROPA team (DG Press) has granted him the right to directly request updates to the production version of his pages under "http://europa.eu.int/comm/fairy_affairs/". He does so by uploading a ".request.update" file in the directory "/public/htdocs/comm/fairy_affairs" on the staging server, or through the functionalities offered by the staging manager web interface.
At the appropriate time the automatic update procedure will copy the listed files and/or sub-directories from "/public/htdocs/comm/fairy_affairs" on the "staging" server to "/public/htdocs/comm/fairy_affairs" on the "dissemination" server. The results of this action will be written into a file "/public/htdocs/comm/fairy_affairs/.request.output".

Now, Mr Grimm asks his brother to maintain the sub-site "/comm/fairy_affairs/myths_legends/". Upon his request DG Press' EUROPA team grants the userid 'grimmja' write permission to the directory "/public/htdocs/comm/fairy_affairs/myths_legends/". Upon explicit demand, the user "grimmwi" continues to have write permission on this sub-directory as well.
One of the sub-directories "/comm/fairy_affairs/myths_legends/bloodandgore/" is to contain sensitive information that may only be accessed by a limited number of people. This information will be put under "/restricted/htdocs/comm/fairy_affairs/myths_legends/bloodandgore/" and userid "grimmja", per default, will have exclusive write and read permission.
The both EUROPA "staging" and "dissemination" web servers will be configured to map the URL "/comm/fairy_affairs/myths_legends/bloodandgore/" to the file path "/restricted/htdocs/comm/fairy_affairs/myths_legends/bloodandgore/", while adding the appropriate access controls.

Here is a schematic overview of the directory structure of the described example.

/public	/htdocs/comm/fairy_affairs			grimmwi
		/myths_legends		grimmja
/restricted	/htdocs/comm/fairy_affairs	/myths_legends	/bloodandgore	grimmja