Tag: mediawiki

PSA: Mediawiki doesn’t like . characters in MySQL database names

Or, how I spent about 15 hours debugging our MediaWiki installation at wiki.ucalgary.ca, trying to figure out why file uploads were mysteriously failing.

We’ve got a fair number of active users on the wiki, and a course in our Werklund School of Education’s grad program is using it now for a collaborative project. Which would be awesome, except they were reporting errors when uploading files. I logged in, tried to upload a file, and BOOM, got this:

Could not create directory "mwstore://local-backend/local-public/c/cf"

um. what? smells like a permissions issue. SSH into the server, check the directories, and yup, they’re all owned and writable by apache (this is on RHEL6). Weird. Maybe the drive’s full? df -h. Nope. Uh oh. Maybe PHP or Apache have gone south – better check with another site on the server. Login to ucalgaryblogs.ca and upload a file. Works perfectly. So it’s nothing inherent in the server.

Lots of searching, reading about LocalSettings.php configuration options. Nothing seems to work. I enable Mediawiki logging, check the apache access and error logs, and find nothing. It should be working just fine. The uploaded file shows up in the /tmp directory, then disappears (as expected) but is never written into the images directory. Weird.

So, I try a fresh install of mediawiki elsewhere on the server (in a separate directory, with a new database called ‘mediawikitest’). Works like a charm. Dammit. So it’s really nothing wrong with the server. Or with mediawiki. Maybe there’s some freaky security restriction on the new server1, so I set up a new VirtualHost to spin up the new MediaWiki install in exactly the same way as wiki.ucalgary.ca (using a full hostname running in its own directory, rather than as a subdirectory of the “main” webserver’s public_html directory). And it works like a charm.

Hrm. Searching for the error message turns up mentions of file permission errors, and file repository configs. I mess around with that, but everything looks fine. Except that uploads fail for some reason.

Maybe there’s something funky about the files in the wiki.ucalgary.ca Mediawiki install – it goes back to May 2005, so there’s over 9 years of kruft building up. There’s a chance. So I copy the whole wiki.ucalgary.ca mediawiki directory and use it to host the test instance (still pointing at the mediawikitest database). Works fine. So it’s nothing in the filesystem. It’s not in the Apache or PHP config. Must be in the database.

So, I switch the test instance to use the production mediawiki database (named ‘wiki.ucalgary.ca’). And uploads fail. Dammit. I assume something is out of sync with the latest database schema, so I eyeball the ‘images’ table in both databases. AHAH! Some of the field definitions are out of date – the production database is using int(5) for a few things, while the new test database uses int(11) – maybe the file upload code is trying to insert a value that’s longer than the table is configure to hold. So I manually adjust the field definitions in our production images table. That’ll solve it. Confidence! But no. Uploads still fail. But the problem’s got to be in the database, so I modify my search tactic, and find a blog post from 2013:

Problem solved. Turns out the new database backend thing in mediawiki doesn’t like database names with dots in them, and doesn’t tell you. Thank you Florian Holzhauer for finding it!

Dafuqbrah? Really? That can’t possibly be it… The wiki’s been working fine all along – it’s up and running and people are actively using it. If the database wasn’t working, surely we’d have noticed earlier…

renames database from wiki.ucalgary.ca to wiki_ucalgary

uploads file

Son of a wiki. It works.

So. At least 15 hours of troubleshooting, debugging, trial and error, modifying configurations, installing test instances, and being completely unable to figure it out. And it was a freaking . in the database name that was doing it. With no mention of that in any error message or log file. Awesome. An error message that says “could not create directory” actually means “hey - a portion of my code can't access databases with . characters in the database name - you may want to fix that.“

  1. we moved recently from an old decrepit server onto a shiny new VM server hosted in our IT datacentre, which is awesome but I’m rusty on my RHEL stuff, so there’s a chance I’m missing something important in configuring the server… [↩]

battling spam on the campus wiki

The University’s campus wiki, wiki.ucalgary.ca, is still run as a semi-stealth pilot project. This seems strange, after running it for 7 and a half years (first edit, December 11, 2004), but it’s something I initially snuck onto a server, and it kind of grew from there. It’s still running on an aging and borrowed/scrounged server, and I’m supporting it in my spare time. Which means, it’s basically self-supporting. Which is fine, because the people that have been doing awesome stuff with it are a pretty self-supporting group. I’m working on getting the wiki adopted by IT so it will be properly managed, but that process takes time.

But. The spam. The wiki was configured to be open, allowing anonymous edits. The idealist in me wanted to provide a way for people to contribute without worrying that their edits would be tracked back to them. I’d even initially allowed anonymous edits, so people could edit without logging in at all. Sounds good in wiki theory. But in practice… The spam. It burns. It didn’t take long before I had to kill anonymous edits. The spam bots were drawn to that like fetid moths to a rancid flame. But I fought the urge to require campus authentication. The spam piled up, but was manageable. Until lately, when I just haven’t had the spare time to devote to pruning the rotting garbage that builds up.

So. I just installed an extension that will restrict new accounts to require a @ucalgary.ca email address. You can still use whatever you want for a username (use a pseudonym, nom de plume, whatever), and it’s not authenticated against the campus directory or anything. But you need to have a @ucalgary.ca email address to edit.

This feels like a decent balance, assuming students still have access to a campus email address. This is debatable. On ucalgaryblogs, less than 1/3 of students use their @ucalgary.ca email addresses. Is this because they haven’t activated them, or because they simply choose to use a hotmail or gmail or whatever.com address? One way to find out…

Blocking Spam In Mediawiki

Too much spam garbage was leaking into wiki.ucalgary.ca so I wanted to beef up the antispam strategy a bit. Currently, the antispam setup is:

  • Bad-Behavior blocks all requests to the webserver from evildoers (but I worry about false positives, so have whitelisted the entire UofC network)
  • users must be logged in to edit (but anyone can create an account)
  • SpamBlackList uses Wikimedia’s blacklist to block edits
  • regex rejects content with sneaky hidden CSS attributes
  • ConfirmEdit adds an extra step if content smells funny, as well as providing a simple match-captcha on account creation
  • SimpleAntiSpam adds an extra (hidden) step to trip up bots

I followed some of the excellent instructions on the UMassWiki on tweaking antispam extensions and config: UMassWiki:Blocking Spam In Mediawiki – UMassWiki. (note there’s a problem with the current version of Bb2ext – the Bad Behavior Extra extension – that is easily fixed by following the instructions on the talk page for that extension)

MediaWiki as a presentation application

I gave a presentation this morning as part of Faculty Technology Days 2007. I was asked a few weeks ago if I'd like to talk about weblogs and wikis, and I couldn't come up a reason why not, so they slotted me in. In the meantime, I've been doing a lot of thinking about weblogs, wikis, academic publishing, and being Open, Connected and Social. So I decided to try to subvert my presentation slightly, into a more open-content-is-good kind of talk (but still based on blogs and wikis for much of it). What better way to do that, than to present directly from a wiki? It's worked very well for Brian Lamb – all of his presentations are wiki-driven.

Yesterday, I came across a link to some Firefox Greasemonkey scripts for use with Mediawiki. (aside: I'd thought I'd seen the link via Twitter, but can't seem to find who said it there – I remembered it being from Scott Leslie, but it could have been through del.icio.us, or via a comment he made on a blog somewhere…)

Anyway, on scanning through the list, one jumped out at me. Not literally, but that would have been cool. The "Wikipedia Presentation" script sounded very cool. I'm a big fan of the wiki-as-presentation style, and this mashed up a Mediawiki page with the awesome S5 html presentation engine. By installing this script, it automatically enables viewing any Mediawiki page as a full-screen slideware presentation.

So, I installed it.

And it failed. The current version of the script has been updated for the current version of Mediawiki. I'm using an older version (because my server doesn't have the latest PHP bits to run the latest MediaWiki). Older Mediawiki pages use div elements to mark sections of a page, while newer versions use spans. After some extremely complicated editing of the Greasemonkey script (changing the 3 instances of "span" to say "div" instead) I was off and running. My modified (i.e., reverted) version of the Greasemonkey script is available here.

The cool thing, if you're using a Mac (and, really, what ISN'T cooler if you're using a Mac) is that you can install an application called Mira to enable using the Apple Remote to control Firefox. I bound the back/forward buttons on the remote to the left/right arrow keys, and I was navigating through a Mediawiki page as a full-screen presentation, using a wireless remote.

With the script installed, the wiki/presentation page for this presentation should show a "Start Presentation" link right beneath the article title.

There was one minor tweak I needed to make. By default, the content of the slide starts too far down the screen. When using a projector, you may be stuck at 800×600, and a bunch of that was sucked up by empty space at the top. So, I overrode one of the styles to make it start higher up. There are a couple of ways you can do this. If you have the Web Developer extension installed, just add a new User Style Sheet containing the style below. Otherwise, edit your Mediawiki skin (in my case, the file at /skins/monobook/main.css ) to add this: 

#wikipedia_presentation {
     margin-top: 0 !important;
}

I gave a presentation this morning as part of Faculty Technology Days 2007. I was asked a few weeks ago if I'd like to talk about weblogs and wikis, and I couldn't come up a reason why not, so they slotted me in. In the meantime, I've been doing a lot of thinking about weblogs, wikis, academic publishing, and being Open, Connected and Social. So I decided to try to subvert my presentation slightly, into a more open-content-is-good kind of talk (but still based on blogs and wikis for much of it). What better way to do that, than to present directly from a wiki? It's worked very well for Brian Lamb – all of his presentations are wiki-driven.

Yesterday, I came across a link to some Firefox Greasemonkey scripts for use with Mediawiki. (aside: I'd thought I'd seen the link via Twitter, but can't seem to find who said it there – I remembered it being from Scott Leslie, but it could have been through del.icio.us, or via a comment he made on a blog somewhere…)

Anyway, on scanning through the list, one jumped out at me. Not literally, but that would have been cool. The "Wikipedia Presentation" script sounded very cool. I'm a big fan of the wiki-as-presentation style, and this mashed up a Mediawiki page with the awesome S5 html presentation engine. By installing this script, it automatically enables viewing any Mediawiki page as a full-screen slideware presentation.

So, I installed it.

And it failed. The current version of the script has been updated for the current version of Mediawiki. I'm using an older version (because my server doesn't have the latest PHP bits to run the latest MediaWiki). Older Mediawiki pages use div elements to mark sections of a page, while newer versions use spans. After some extremely complicated editing of the Greasemonkey script (changing the 3 instances of "span" to say "div" instead) I was off and running. My modified (i.e., reverted) version of the Greasemonkey script is available here.

The cool thing, if you're using a Mac (and, really, what ISN'T cooler if you're using a Mac) is that you can install an application called Mira to enable using the Apple Remote to control Firefox. I bound the back/forward buttons on the remote to the left/right arrow keys, and I was navigating through a Mediawiki page as a full-screen presentation, using a wireless remote.

With the script installed, the wiki/presentation page for this presentation should show a "Start Presentation" link right beneath the article title.

There was one minor tweak I needed to make. By default, the content of the slide starts too far down the screen. When using a projector, you may be stuck at 800×600, and a bunch of that was sucked up by empty space at the top. So, I overrode one of the styles to make it start higher up. There are a couple of ways you can do this. If you have the Web Developer extension installed, just add a new User Style Sheet containing the style below. Otherwise, edit your Mediawiki skin (in my case, the file at /skins/monobook/main.css ) to add this: 

#wikipedia_presentation {
     margin-top: 0 !important;
}

OpenAcademic.org – blending Moodle, Drupal, Mediawiki, Elgg

I must have blinked when this was announced, but OpenAcademic.org sounds like a perfect scenario. Development efforts to integrate some of the biggest open source tools used in online education. It sounds like the goal is to come up with a way for Drupal, Elgg, Mediawiki and Moodle to all play nicely together, in such a way as to be easily deployable and maintainable by even the smallest school. Rather than attempting to build The One True LMS, they’re taking the approach of playing to the strengths of the available tools, and putting the effort into integration.

The really cool thing is a documented commitment by the OpenAcademic.org team to not fork projects, and to contribute any code to the relevant communities. So, they’ll be hacking on each of these applications directly, with all improvements freely available to everyone.

Personally, I think this is one of the biggest and coolest developments in online education for the year. I’m ashamed that I missed the announcement almost a month ago.

I’ve been spending almost all of my time lately in Drupal, with some time in Moodle. It’s pretty obvious that each has its own strengths (and weaknesses), and that spending effort to duplicate each package’s feature set would be wasteful and counterproductive. Having an effective way to integrate these various tools would be amazingly powerful, especially as more applications, platforms and tools are brought into the mix.

Imagine an elearning ecosystem that ties in Drupal, Mediawiki, Elgg, Moodle, Blackboard, WebCT, Flickr, del.icio.us, Facebook, YouTube, etc… in a flexible system that can adapt to any pedagogical needs. Sweet.

I must have blinked when this was announced, but OpenAcademic.org sounds like a perfect scenario. Development efforts to integrate some of the biggest open source tools used in online education. It sounds like the goal is to come up with a way for Drupal, Elgg, Mediawiki and Moodle to all play nicely together, in such a way as to be easily deployable and maintainable by even the smallest school. Rather than attempting to build The One True LMS, they’re taking the approach of playing to the strengths of the available tools, and putting the effort into integration.

The really cool thing is a documented commitment by the OpenAcademic.org team to not fork projects, and to contribute any code to the relevant communities. So, they’ll be hacking on each of these applications directly, with all improvements freely available to everyone.

Personally, I think this is one of the biggest and coolest developments in online education for the year. I’m ashamed that I missed the announcement almost a month ago.

I’ve been spending almost all of my time lately in Drupal, with some time in Moodle. It’s pretty obvious that each has its own strengths (and weaknesses), and that spending effort to duplicate each package’s feature set would be wasteful and counterproductive. Having an effective way to integrate these various tools would be amazingly powerful, especially as more applications, platforms and tools are brought into the mix.

Imagine an elearning ecosystem that ties in Drupal, Mediawiki, Elgg, Moodle, Blackboard, WebCT, Flickr, del.icio.us, Facebook, YouTube, etc… in a flexible system that can adapt to any pedagogical needs. Sweet.

Mediawiki Spambot Blocking

Our little experiment at wiki.ucalgary.ca has been having some rough times. It’s gotten so frustrating that I’d had to temporarily disable new account creation in a desparate attempt to thwart the automated spambots (which automatically create a new account for each edit so it’s harder to roll them back).

I’ve just updated the wiki to the latest and greatest Mediawiki 1.6.1, and one of the new extensions that work with this version is one called ConfirmEdit. It can be configured to challenge “users” with a captcha upon account creation, as well as on each page edit (even only on page edits containing a URL).

For now, I’ve set the wiki up so that all edits require an account (no anonymous edits – I can live with that), and all account creations must provide a correct simple captcha response. Once you’ve created an account, you should never see the captcha again.

I’m settling for the “SimpleCaptcha” implementation – it’s a math question rather than a nasty wordimage. As much as I hate captchas is general, I figure it’s easy enough to fire up Calculator.app when you create an account, and shouldn’t block anyone with visual challenges.

Mediawiki ConfirmEdit Account Creation Captcha

Our little experiment at wiki.ucalgary.ca has been having some rough times. It’s gotten so frustrating that I’d had to temporarily disable new account creation in a desparate attempt to thwart the automated spambots (which automatically create a new account for each edit so it’s harder to roll them back).

I’ve just updated the wiki to the latest and greatest Mediawiki 1.6.1, and one of the new extensions that work with this version is one called ConfirmEdit. It can be configured to challenge “users” with a captcha upon account creation, as well as on each page edit (even only on page edits containing a URL).

For now, I’ve set the wiki up so that all edits require an account (no anonymous edits – I can live with that), and all account creations must provide a correct simple captcha response. Once you’ve created an account, you should never see the captcha again.

I’m settling for the “SimpleCaptcha” implementation – it’s a math question rather than a nasty wordimage. As much as I hate captchas is general, I figure it’s easy enough to fire up Calculator.app when you create an account, and shouldn’t block anyone with visual challenges.

Mediawiki ConfirmEdit Account Creation Captcha

Sustained Wiki Spam Attack

wiki.ucalgary.ca has been under a sustained spam attack all day. What started out as a minor irritation has grown into something that is impossible to ignore. The spammer is somehow getting around both Bad Behavior and Spam Blacklist extensions (I’ve blacklisted their URLs, but they keep getting edits into the system). This is one of the more frustrating aspects of trying to do things in an open manner. If there is the slightest possibility that something will be subverted for spamilicious purposes, it will be. And most likely it will happen before more than a handful of legitimate users are able to take advantage of a service.

These cretins are being rather clever (or, they’ve gotten some good Script Kiddie l337 tools) because they’re coming from many different (and changing) IP addresses, and each edit is accompanied by its very own account creation. So I can’t just block IPs, or roll back all edits by a user. So, I’ve had to disable account creation for now until I can figure out wtf to do about this.

To the spammer(s): may you rot in the most insidious inner circle of hell, reserved for parasites like yourself who find it necessary to suck energy and resources from (otherwise) free and open educational resources.

wiki.ucalgary.ca has been under a sustained spam attack all day. What started out as a minor irritation has grown into something that is impossible to ignore. The spammer is somehow getting around both Bad Behavior and Spam Blacklist extensions (I’ve blacklisted their URLs, but they keep getting edits into the system). This is one of the more frustrating aspects of trying to do things in an open manner. If there is the slightest possibility that something will be subverted for spamilicious purposes, it will be. And most likely it will happen before more than a handful of legitimate users are able to take advantage of a service.

These cretins are being rather clever (or, they’ve gotten some good Script Kiddie l337 tools) because they’re coming from many different (and changing) IP addresses, and each edit is accompanied by its very own account creation. So I can’t just block IPs, or roll back all edits by a user. So, I’ve had to disable account creation for now until I can figure out wtf to do about this.

To the spammer(s): may you rot in the most insidious inner circle of hell, reserved for parasites like yourself who find it necessary to suck energy and resources from (otherwise) free and open educational resources.

Tikiwiki as a “secure” wiki?

One of the biggest questions I get from people who want to use wiki.ucalgary.ca is “How do I protect or lock a page?” I’ve had to respond with a gentle suggestion that the wiki is an open resource by design, but that doesn’t go very far. There are valid reasons for locking down a wiki – ranging from sensitive information that shouldn’t be In The Wild, to protecting privacy (K-12 collaborations can’t have info about kids leaking onto the ‘net for obvious reasons).

It really felt counterproductive to just refer folks to other external tools like Writely. They’re great tools, but if wiki is to be a valued resource on campus, it should serve all core requirements. I’m struggling with the possibility of migrating away from MediaWiki (which doesn’t handle security, by design), or possibly adding a second “secure” wiki as an option.

I spent an hour or so this evening playing around with TikiWiki – some pretty fully-featured stuff (if a little “busy” as a result) that should solve any/all issues. I’ll keep playing with Tiki to get a better feel for it.

One of the biggest questions I get from people who want to use wiki.ucalgary.ca is “How do I protect or lock a page?” I’ve had to respond with a gentle suggestion that the wiki is an open resource by design, but that doesn’t go very far. There are valid reasons for locking down a wiki – ranging from sensitive information that shouldn’t be In The Wild, to protecting privacy (K-12 collaborations can’t have info about kids leaking onto the ‘net for obvious reasons).

It really felt counterproductive to just refer folks to other external tools like Writely. They’re great tools, but if wiki is to be a valued resource on campus, it should serve all core requirements. I’m struggling with the possibility of migrating away from MediaWiki (which doesn’t handle security, by design), or possibly adding a second “secure” wiki as an option.

I spent an hour or so this evening playing around with TikiWiki – some pretty fully-featured stuff (if a little “busy” as a result) that should solve any/all issues. I’ll keep playing with Tiki to get a better feel for it.

MediaWiki Spam_blacklist Extension

I’d installed Spam_blacklist back in October, but we’d been getting the occasional spam attack since then, lately every single weekend. So I just dug into the Mediawiki config, and realized that Spam_blacklist never got properly configured on my server, meaning it was essentially running wide open. Crap. What a waste of time that was. Paul and I have removed dozens/hundreds of spams over the last few weeks, and I was assuming Spam_blacklist was enabled properly. Oops.

So, if you’re running Mediawiki, be sure to carefully (re)follow the instructions, especially Morbus Iff’s patch for 1.5 compatibility (I had to manually patch the file, since patch was barfing on an unmatched }).

The wiki is now configured to pull the blacklist from meta.wikimedia.org every hour, and will check edits against both that blacklist and the one we’re growing ourselves.

Things to watch out for:

  • If you’re running the latest MediaWiki (1.5.x), be sure you’ve applied Morbus Iff’s patch.
  • Also, be sure you’ve moved your local Spam_blacklist page to Mediawiki:Spam_blacklist so the plugin can see it. It apparently must be in the Mediawiki: namespace.
  • Fix your copy of load_lists.sh to use the proper URL for updating the blacklist – bots have to use http://meta.wikimedia.org/w/index.php?title=Spam_blacklist&action=raw
  • If you want, add the load_lists.sh file to your crontab so it runs automatically. I think the plugin tries to do that, but better safe than sorry 😉
  • Test your wiki’s now-hopefully-working antispam measures. Try to edit a page with a URL from the shared blacklist, then one from your own. Hopefully both attempts fail.
  • (hopefully) relax a bit, and with luck the spammers will move on to greener pastures…

Why on earth isn’t this plugin included with the core Mediawiki distro? And why hasn’t the download been updated for 1.5 compatibility yet? It would be great to keep it up to date, and to make it easier to get it running properly. There are likely a LOT of Mediawiki instances that aren’t configured properly, making all Mediawiki instances nice, juicy targets.

I’d installed Spam_blacklist back in October, but we’d been getting the occasional spam attack since then, lately every single weekend. So I just dug into the Mediawiki config, and realized that Spam_blacklist never got properly configured on my server, meaning it was essentially running wide open. Crap. What a waste of time that was. Paul and I have removed dozens/hundreds of spams over the last few weeks, and I was assuming Spam_blacklist was enabled properly. Oops.

So, if you’re running Mediawiki, be sure to carefully (re)follow the instructions, especially Morbus Iff’s patch for 1.5 compatibility (I had to manually patch the file, since patch was barfing on an unmatched }).

The wiki is now configured to pull the blacklist from meta.wikimedia.org every hour, and will check edits against both that blacklist and the one we’re growing ourselves.

Things to watch out for:

  • If you’re running the latest MediaWiki (1.5.x), be sure you’ve applied Morbus Iff’s patch.
  • Also, be sure you’ve moved your local Spam_blacklist page to Mediawiki:Spam_blacklist so the plugin can see it. It apparently must be in the Mediawiki: namespace.
  • Fix your copy of load_lists.sh to use the proper URL for updating the blacklist – bots have to use http://meta.wikimedia.org/w/index.php?title=Spam_blacklist&action=raw
  • If you want, add the load_lists.sh file to your crontab so it runs automatically. I think the plugin tries to do that, but better safe than sorry 😉
  • Test your wiki’s now-hopefully-working antispam measures. Try to edit a page with a URL from the shared blacklist, then one from your own. Hopefully both attempts fail.
  • (hopefully) relax a bit, and with luck the spammers will move on to greener pastures…

Why on earth isn’t this plugin included with the core Mediawiki distro? And why hasn’t the download been updated for 1.5 compatibility yet? It would be great to keep it up to date, and to make it easier to get it running properly. There are likely a LOT of Mediawiki instances that aren’t configured properly, making all Mediawiki instances nice, juicy targets.

MediaWiki and Access Control

I’ve been asked by a couple of people about ways to restrict access to pages in wiki.ucalgary.ca. My initial response was often something like “wha? that’s just wrong. you don’t lock down wikis…”

Then, they explained more about what they wanted to do, and why they couldn’t just leave the pages out In The Wild and trust that it was private through obscurity. Things like collaborative student experimental writing, where it would be a Bad Thingâ„¢ if things like the Wayback Machine kept eternal snapshots of not-fully-baked writing, which could come back to haunt someone later. Shouldn’t have to throw the baby out with the bathwater – restricting access to pages within the wiki would let them play, without exposing them more than they’re comfortable with.

So I did some Googling over the last few months, and still haven’t come up with a solution I’m completely happy with. The closest I came to a workable solution is the Access Control extension – but that needed some tweaking before it would run as expected (my modified file), and I fear it exposes some pretty scary security risks. What happens if Joe Spamass edits Main_Page and adds a fake access control list to the page? I’ve installed it, but will be keeping a close eye on it, and maintaining nightly MySQL dumps of the wiki databases Just In Caseâ„¢.

I also found this patch to enable a “restrict” feature, but it really just creates a “penalty box” where pages can be sent, and only people who are allowed to see the “penalty box” can see the pages – but there’s no fine granularity, it’s an all-or-nothing thing.

I really don’t know why this isn’t part of the core feature set of Mediawiki. Sure, the Wikipedia wouldn’t use it, but how many gazillion corporate/institutional wikis could benefit (or require) this feature? There are a lot of folks who are interested in this, but no real solutions that I’ve found…

I’ve been asked by a couple of people about ways to restrict access to pages in wiki.ucalgary.ca. My initial response was often something like “wha? that’s just wrong. you don’t lock down wikis…”

Then, they explained more about what they wanted to do, and why they couldn’t just leave the pages out In The Wild and trust that it was private through obscurity. Things like collaborative student experimental writing, where it would be a Bad Thingâ„¢ if things like the Wayback Machine kept eternal snapshots of not-fully-baked writing, which could come back to haunt someone later. Shouldn’t have to throw the baby out with the bathwater – restricting access to pages within the wiki would let them play, without exposing them more than they’re comfortable with.

So I did some Googling over the last few months, and still haven’t come up with a solution I’m completely happy with. The closest I came to a workable solution is the Access Control extension – but that needed some tweaking before it would run as expected (my modified file), and I fear it exposes some pretty scary security risks. What happens if Joe Spamass edits Main_Page and adds a fake access control list to the page? I’ve installed it, but will be keeping a close eye on it, and maintaining nightly MySQL dumps of the wiki databases Just In Caseâ„¢.

I also found this patch to enable a “restrict” feature, but it really just creates a “penalty box” where pages can be sent, and only people who are allowed to see the “penalty box” can see the pages – but there’s no fine granularity, it’s an all-or-nothing thing.

I really don’t know why this isn’t part of the core feature set of Mediawiki. Sure, the Wikipedia wouldn’t use it, but how many gazillion corporate/institutional wikis could benefit (or require) this feature? There are a lot of folks who are interested in this, but no real solutions that I’ve found…