2007-08-30
Using reverse proxies to unify web sites
At least around here, it's common for a department to have a number of different administrative groups inside of it, all of them providing services (whether internal or external). Generally this produces a profusion of group websites, partly because each group has different needs and partly so that no single group is stuck with the job of being responsible for a web server that contains everything, including peculiar applications that they don't understand and can't touch.
It's recently struck me that one of the things you can do with reverse proxies is stitch together all of these websites and web services under one 'public' namespace and website. This gives users a single place to go to and, more importantly, a single place to remember, especially if you create some sort of top level index to all of the services (which you should have anyways).
(It also makes it easier to change who is responsible for services, because their URLs don't have to change if they move between groups or the like.)
The one drawback to this rosy picture is that the authentication for everyone's services is now going through a central place, because all of the HTTP traffic has to pass through the reverse proxy machine. Since a compromise of that machine puts the passwords for each group's services at risk, all of the groups have to have a decent degree of trust in the central website and the people who run it.
Note that each group can keep on doing its own authentication for the services it provides; you don't have to try to build a single sign on system for this apparently unified website. (Your users will probably thank you if you do, though. And if you do it right, groups will find it much more attractive to use your authentication instead of building and managing their own.)
2007-08-21
The dilemma of website facing
Broadly speaking, websites can be inward facing, aimed at providing services to people in your organization, or outwards facing, aimed at providing information (and sometimes services) to outsiders. The difference is not just a matter of keeping sensitive information from outside people, it is that the two groups generally want completely separate sorts of information; the procedures for arranging workstation support are probably as uninteresting to outsiders as the press releases are to insiders.
I think that this gets especially confusing in universities, because groups in a university have at least two unusual pressures pushing them back and forth: our websites and subdomain structure are generally public and we have lots of new people showing up all the time. The first means that there are no good places to hide websites that are going to be obvious to internal people but invisible to outsiders; the second means that you need obvious websites because people generally don't get taught where all the resources are in a way that sticks.
(For example, I don't know what sort of orientation packets our new graduate students get but I suspect it doesn't include very much about how to get computer support, if only because no one has asked us what should be in that sort of overview.)
Thus, one of the dilemmas of building a website at a university is trying to figure out which way it should face, or if you should try to make it face both ways at once, Janus-like. Around here, it is not always clear which website is (or should be) which.
(The other fun game is trying to pick a name for your internal website or support area that is obvious and memorable but not so obvious that external people will try to visit it and get confused.)
2007-08-19
A realization about breadcrumbs
Our internal user support web pages don't currently have breadcrumbs, those little bits that show a web page's location in some hierarchy and let you pop up to higher levels. This makes a lot more sense than for most websites, because hopefully we don't have our users landing on random pages through search engines; in theory they come into our support pages at the top and then navigate down from there, so they always have the Back button available.
Then, recently, someone had a question that was best answered by one web page, except that the answer could be expanded by a parent page and a sibling. And I got a sinking feeling.
Although it should have been obvious to me earlier, clearly search engines aren't the only way that our users can wind up on random support pages instead of the top of the tree. And it's not just the URLs we give them to answer their questions; users may well be passing URLs around without involving us, as one grad student asks another for help.
(I tend to assume that this happens a lot, but that's another entry.)
Or in the short version: breadcrumbs mean you can give out any of your URLs, knowing that people can navigate outwards from there to whatever else they need.