You are here

Frequently asked questions about publishing

Listed below are an assortment of frequently, and not so frequently, asked questions about the CVS web publishing system.

If the question you wanted to ask isn't covered here, then please check the other documentation as well. In particular, the rough guide covers most of the basic elements of the publishing service.



How do I include revision or modification information?
You can include assorted information in your web page by using the following tags:

Tag Description Example
$Date$ The version's date 2009/01/29 13:09:03
$Revision$ The revision of the file 1.31

These tags work because the web server is implemented on top of CVS. In fact, you can use any keyword which is supported by CVS in your documents. However, only those listed above are likely to produce meaningful results.

How can I control access to my pages?
At present, you can only do this if you are using CVS to manage your web pages on www.inf. If you're not, contact the webadmin who'll help.

To control access you need to create a file called .htaccess (note the leading dot) in the directory that you want to restrict. This will impose restrictions on this directory, and all of the levels below it.

To restrict users based on the IP address that they're connecting from, you need to use something like:

# Apache 2.4 syntax - the default is one must match for access to be granted, otherwise denied
Require ip
# The University's IPv6 network range
Require ip 2001:630:3c1::/48
# Or if the client's IP resolves to an address
Require host

This example would restrict access to all machines within the University's network, ie within However, it would exclude eduroam wireless connections or student accommodation connections.

Remember that IP address based restrictions are by no means 100% secure, especially as the number of machines you allow access to increases. Also, any IP restricted area of the site is still visible to those with an Informatics Publishing account.

If you wish to protect your documents so that a username and password are required to view them, then use these lines as an example:

CosignProtected on
AuthType Cosign
Require user tinkywinky lala

AuthGroupFile /liveroot/conf/access/group.capabilities
Require group web/wwwinf/staffonly
The first 3 lines would be enough to restrict the pages to the DICE users "tinkywinky" and "lala". With the addition of the last two lines, then any DICE user with the "web/wwwinf/staffonly" capability would also have access. Contact support if more complicated restrictions are required. Note these only work as expected via HTTPS URLs.
How do I create/use my own SSIs?
Creating and using your own Server Side Includes (SSIs) is complicated by the fact that pages that use SSIs are also subject to HTML validation. To accommodate this, certain requirements need to be adhered to for SSIs to work. These are:
  • You must use the #include virtual form of SSI eg:
    <!--#include virtual="/research/games/"-->
    <!--#include virtual="/research/games/"-->
  • You must use an absolute (from the document root of the server) path (see above).
  • The included file must start and end with certain comments, eg the /research/games/ file above must look something like:
    [The content goes here]
    Note that the START and END specify the location of this .inc file.
If you follow the above requirements, then you'll be able to use your own SSIs.
How do stop email addresses being harvested?
It's a sad fact of life that certain individuals trawl the web looking for web pages with email addresses on them. These addresses are then harvested and sold on to spammers (people who send unsolicited junk email), that then clog mailboxes up with junk.

This means that if you have a web page containing an email address (useful when telling someone how to get in contact), then its likely that the address will start receiving junk mail.

When including an email address on a web page, try to disguise the fact that it's an email address. Humans should still be able to recognise it, but programs that go around looking for them will probably not. So rather than putting "send mail to" on your web page, do "send mail to SomeAddress (at) inf . ed . ac . uk", it looks a little clumsy, but people should know what you mean, and it should throw most automated harvesters off the scent.

You can go further by using convoluted HTML to obfuscate things, eg "send mail to"

Which actually looks like this in HTML:

send mail to <a

This example also use the mailto: URL in the <A> tag. This is usually an even more sure fire way of the harvesting programs finding real email addresses, however if you must use it (but its recommended that you don't), you can still try to confuse things by using numerical entities as in the above example.

None of this tricks will guarantee that the address won't be harvested, but they should help.

Why does the validator complain about my link?
This is probably because your link is a link to a CGI program and contains the & character. The & character is special in HTML and marks the beginning of an entity. You need to replace any occurrence of & with the string &amp;.
Why do things the way we do, ie CVS and validation?
For reasons of accessibility and manageability. See the why is the way it is document.
I don't have enough Karma!
Mainly to protect users from themselves, not everyone has permission to edit every page on If you find you don't have enough permission to edit a page you think you should ("Access denied: Insufficient Karma", is the error message you get). Then contact the web team via the support form, stating the pages you are trying to change, and why.
Who do I talk to if I still have a problem?
If you are still having problems, use the support form and your message will make it to the web team.
Last reviewed: 

System Status

Home dirs (AFS)
Other services
University services
Scheduled downtime

Choose a topic