Lhridley

My name is Lisa Ridley; I usually go by the login Lhridley; in the past I have used Hoggwild or Hoggwild5. I work as a web applications developer, primarily utilizing PHP/MySQL with a little jQuery thrown in for good measure.

I currently work as a web developer for a company that develops solutions using Drupal; although I have a fair amount of past experience with MediaWiki as well.

Extensions/hacks:

ProjectWiki - currently under development
MWForms - currently under development

Calendar Class for MediaWiki -- if you write extensions that utilize date fields, you may find this class useful. This is a PHP Class written as a wrapper for a javascript popup calendar that can be used to insert dates and/or times into data entry fields in MediaWiki. The class structures a function call that gets inserted into your forms script to trigger a pop-up calendar. The popup calendar itself is available at www.rainforestnet.com, although I made a few modifications to the original javascript file to facilitate its incorporation into MediaWiki. While this has only been tested on MediaWiki version 1.12, English version, the calendar month and day names pull from the MediaWiki content language files (stored in global $wgContLang), so this should work with other languages supported by MediaWiki with no problems.

Create Article - a modified version of the InputBox extension that is just for creating articles. Allows you to specify a prefix (good for namespace) or subpage for an article without the user being made aware of the argument; the user simply needs to supply the article name, and the extension automatically adds the specified prefix and/or subpage to the article name.

UserPageEditProtection - this extension, which has currently been tested on MediaWiki versions 1.6.x through 1.16alpha, provides restricted edit access to user pages to the user that "owns" the page and to sysops.

NamespaceProtection - this extension provides the namespace protection capabilities introduced in MediaWiki version 1.10 for prior versions of MediaWiki. This extension is currently in beta test, and has been tested on version 1.6.10.
ExtraNamespaces - this extension provides the capability to add custom namespaces through the MediaWiki interface rather than declaring them in the LocalSettings.php file using $wgExtraNamespaces.
Extra Sidebar - this is not an extension, but an additional function that can be added to any Monobook or Monobook derived skin that will add an additional menu to the sidebar that can be hidden from anonymous users, but displayed for users who are logged into the wiki. The second navigation menu can be created in a new article in the MediaWiki namespace called MediaWiki:sidebar-internal. This sidebar functions just like the navigation bar, only it is hidden from users who are not logged into the wiki.
InternalWhitelist - this extensions provides the capability of maintaining the "whitelisted" pages for anonymous users in the MediaWiki namespace.
WhitelistedNamespaces -- this extension provides the capability of whitelisting an entire namespace or array of namespaces. Whitelisted namespaces are added to any specific pages that have been whitelisted using $wgWhitelistRead.

Image Authorization - a way to prevent external links to files and images on your site

I've been playing with utilizing the img_auth.php script to prevent "hotlinking" to uploaded images on my wiki. I don't necessarily want to restrict anonymous users from browsing images that have been uploaded, but I would like to restrict external sites from linking to images on my site (a practice called "hotlinking"). I've come up with a method that works on my site; however there may be circumstances where it may not work for all sites. My wikis run on Apache web servers.

Perhaps this will be of some use to others.

If you have comments or questions, please leave them on my talk page; don't edit my user page. However, please note: if you're running IIS, I don't do Windows. Thanks!

Basic Functionality

The functionality depends on the presence of two Server Variables:

HTTP_REFERER
HTTP_HOST

In my circumstance, my web server sets valid values for both.

If you're not sure whether or not your web server sets valid values for these, create a phpinfo() script on your server, and create an external link to the script from a page in your wiki. Click on the link from your wiki to the script and skim through the output, looking specifically for "HTTP_REFERER" and "HTTP_HOST" under the heading "Apache Environment". If the value stored in HTTP_HOST is your domain name and the value stored in HTTP_REFERER is the wiki page with the link to the script, then you're in good shape. Read on.

Modifying img_auth.php

First things first, get img_auth.php working on your wiki, including the rewrites, so that images are served up properly using the img_auth.php script. Instructions for setting up img_auth.php can be found here.

Once you get img_auth working, then you need to make a simple modification to the img_auth.php script to make sure that it's your wiki requesting the images and/or files and not an external site.

Edit your img_auth.php file and find the following code (near the top):

define( 'MW_NO_OUTPUT_COMPRESSION', 1 );
require_once( dirname( __FILE__ ) . '/includes/WebStart.php' );
wfProfileIn( 'img_auth.php' );
require_once( dirname( __FILE__ ) . '/includes/StreamFile.php' );

Right after this insert the following snippet of code:

if(strpos($_SERVER['HTTP_REFERER'], $_SERVER['HTTP_HOST']) === false) {
	wfForbidden('img-auth-accessdenied','img-auth-public'); 
}

Basically this checks to make sure that the referring website is the same as the server host site. For uploaded images that are displayed on your wiki, this will be the case.

Some notes and comments on this method

Note: this will not work properly if you are using an external source for images, such as commons.wikimedia.com. This is only applicable for images that have been uploaded to your wiki using the Special:Upload page (or a modified version).

Note: this is not 100% foolproof; the values passed in the server headers can be spoofed. But, also note, the "spoofer" would need to know you were using this method to begin with, so I'm fairly confident it will be effective the vast majority of the time.