We offer DGs the possibility to run a "local" web server on the IntraComm platform. The same IntraComm web server will be used, but the starting point will be different. For example, the user will enter an URL "http://www.cc.cec/DGXY/" to access the home page for dgxy's local web data. All the corresponding web pages can be uploaded on the "intracomm.staging.cc.cec.eu.int" FTP server under "/local_sites/htdocs/DGXY", as described in the chapter on uploading data.

Note: We write the DGs' name in UPPERcase for "local" data, and in lowercase for "public" data.

One advantage of using the IntraComm environment to host "local" web sites is that, one way or another, IntraComm is accessible from anywhere. The pages under "http://www.cc.cec/DGXY/" can be accessed from elsewhere through "https://intracomm.cec.eu.int/DGXY/", provided that the CUID, which is required to access "https://intracomm.cec.eu.int", is allowed to access the 'local' web site.

Locating the dissemination version of the 'local' web site

The production version of the 'local' web site can be located either on the IntraComm production platform, or on the staging server.
Using the IntraComm production platform implies that the IntraComm architecture will be followed: updates to the web site will be uploaded on the staging server and transferred for publication using the updating procedures described in the corresponding chapter.
You can also choose to have your information providers upload their updates immediately on the 'live' server. In that case the data will remain on the staging server.

Access restrictions

"Local" web services are per definition ... "local", and access to these services has to be restricted. If access to this information would not be restricted, then it would need to be considered as being part of the public IntraComm web server, which contents are managed by the Internal Communications team of DG Admin.
Access restrictions can be applied based upon IP addresses and/or userids/groups.
Using IP addresses, or IP sub nets, to restrict the access is transparent to the end user, but has turned out to be difficult to manage. Especially the dynamic allocation of IP addresses is causing problems.
We therefore recommend to use basic authentication instead. When using basic authentication (userid/password) then the "central userid" (CUID) that is kept in the "central user database" (CUD) will be used. For accesses from outside the Commission's Intranet only basic authentication can be used.
All that needs to be done is to create a new "service" in the CUD and define who has access to that service.
Both types of access restrictions can be combined: requests coming from IP addresses that are not listed as being allowed access, will then be returned with a request for userid and password.

CGI scripts and programs

The scripts and programs that are used for local web servers running on our system, should reside in the central cgi-bin sub directory: scripts and programs created for IntraComm can also be used for the "local" web servers.
CGI scripts and programs that are specific to a local service will be kept in a sub directory of the central cgi-bin sub directory (giving some thing like: /cgi-bin/DGXY/a_script.pl). Access to this sub directory can then be restricted using the same rules as for the corresponding web pages.

The CGI scripts and programs can only be loaded and updated by members of the web team.

More information about CGI scripts on our web server can be found in the corresponding chapter.