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.
Questions
- How do I include revision or modification information in my page?
- How can I control access to my pages?
- How do I create/use my own SSIs?
- How do stop email addresses being harvested?
- Why does the validator complain about my link?
- Why do things the way we do, ie CVS and validation?
- I don't have enough Karma!
- Who do I talk to if I still have a problem?
Answers
- 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 129.215.0.0/16 # The University's IPv6 network range Require ip 2001:630:3c1::/48 # Or if the client's IP resolves to an ed.ac.uk address Require host ed.ac.uk
This example would restrict access to all machines within the University's network, ie within .ed.ac.uk. 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/header.inc"--> <!--#include virtual="/research/games/navigation.inc"-->
- 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/header.inc
file above must look something like:<!--START:/research/games/header.inc--> [The content goes here] <!--END:/research/games/header.inc-->
Note that the START and END specify the location of this .inc file.
- You must use the
- 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 SomeAddress@inf.ed.ac.uk" 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 SomeAddress@inf.ed.ac.uk"
Which actually looks like this in HTML:
send mail to <a href="mailto:SomeAddress@inf.ed.ac.uk">SomeAddress@inf.ed.ac.uk</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&
. - Why do things the way we do, ie CVS and validation?
- For reasons of accessibility and manageability. See the why www.inf.ed.ac.uk 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 www.inf.ed.ac.uk. 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 www.inf.ed.ac.uk/systems/support/form/ and your message will make it to the web team.