Manual talk:Image authorization

For Apache Step 3.2. Edit .htaccess
Should this be the .htaccess file in the root of your public hosted folder? eg, public_html? or should it be the .htaccess in your /images/ folder? Just trying to get this working on a hosted server. Blckdmnd99 19:56, 13 June 2007 (UTC)

Re: For Apache Step 3.2. Edit .htaccess --jdpond 20:04, 13 June 2007 (UTC)

 * I can't test this, but I believe the answer is the images directory as stated in:


 * Apache Step 2. Protect Images Directory from Internet Access
 * If not, could you fix for us?


 * If I can get it working on my setup I'll be happy to tweak anything that's not quite right. So far, no luck though. I'm on a shared hosting acct through lunarpages so I believe I need to use the CGI version of the script... Blckdmnd99 13:21, 14 June 2007 (UTC)


 * I got it to work by editing the .htaccess in my public_html folder. FWIW, I also had to set my $wgUploadPath = "cgi_img_auth.php"; (instead of /wiki/cgi_img_auth.php";) -- 29 January 2008

Apache step 3.2 unnecessary on some installations
I am using a shared server on HostGator (Apache 2.2 and PHP 5.2.8) and using short URLs (I also have a local system running XAMPP 0.7.2 on Mac OS X with Apache 2.2 and PHP 5.2.6). My HostGator installation does not allow httpd.conf modification, only .htaccess modification, and I tried this using the default img_auth.php, NOT cgi_img_auth.php - so I guess this is really a third configuration that is not mentioned in the main article.

In any event, in my case, the .htaccess in my server's document root (on both systems) looks something like this:


 * RewriteRule ^shortpath/?(.*)$ /longer/path/with/lots/of/subdirectories/index.php?title=$1 [PT,L,QSA]

LocalSettings.php has the following variables set:


 * $wgScriptPath = "/longer/path/with/lots/of/subdirectories";
 * $wgArticlePath = "/shortpath/$1";
 * $wgUploadPath = "/longer/path/with/lots/of/subdirectories/img_auth.php";
 * $wgUploadDirectory = "images";

I found the last step of further modifying .htaccess unnecessary on both systems. I didn't try moving the "images" folder, I just did a "Deny from All" in its .htaccess (I have a lot of installations, so I want to keep them relatively compact - I share everything between them except for the "images" folder and LocalSettings.php and AdminSettings.php--and the databases).

YMMV, of course. Hope this helps. --Fungiblename 15:39, 11 February 2009 (UTC)

how does img_auth.php work?
Is there a page discussing it in more detail? An extra paragraph of detail about what it does and how to tweak it would help clarify the first half of this article; especially wrt user groups. Sj 14:28, 14 July 2007 (UTC)

re: how does img_auth.php work? --jdpond 19:13, 4 September 2007 (UTC)
Added info - too confusing?

PHP ISAPI versus CGI --jdpond 19:13, 4 September 2007 (UTC)
Or how to resolve the "CGI Error: The specified CGI application misbehaved by not returning a complete set of HTTP headers".

I spent an entire weekend on this problem so I thought I would try and save the rest of us some time.

There is a great amount of opinion surrounding using the CGI versus the ISAPI technique for IIS, and I strongly suspect that many factors are influential (including an issue with math), but the bottom line I found is that you can't get the img_auth to work with CGI consistently, including playing with all the php.ini parameters (see concise article for one of the dozens I've tried. If anyone else is better than I, please correct and elaborate.

So if you're going to switch to ISAPI, how is it done?

You're going to need 3 areas:


 * 1) Environment Variables
 * 2) IIS Application Configuration
 * 3) IIS Web Services Extensions

I strongly recommend you back up your system before attempting this. Of course, the actual steps you take will vary slightly depending on which version of Windows you are using, but hopefully you'll be able to figure it out. These instructions were done on Windows 2003 Server.

Step 1, Environment Variables
You'll need to add or modify the PHPRC and the PATH system variables.

Right click on My Computer, or go to Start->Control Panel->System->Advanced(tab)->Environment Variables(button), select New (or Edit if exists)(button) in System Variables and add the PHPRC environment equal to the location of your PHP directory, in this case C:\Program Files\PHP\.

Also add the search path (if it doesn't already exist) to your PATH variable by using the Edit(button), and add your path to the PHP directory AND the extensions directory (I did it to the front). In this case, it was C:\Program Files\PHP\;C:\Program Files\PHP\ext\;

Step 2, IIS Application Configuration
Either to each virtual web you have set up, or to the top level web, you'll need to add the .php application handler by going into the IIS Manager (Start->Administrative Tools->Internet Information Services (IIS) Manager)->Web Sites(right click)->Permissions->Home Directory(tab)->Configuration(button), then scroll down to where .php is (or should be). This has to be changed to the ISAPI handler (in this case C:\Program Files\PHP\php5isapi.dll ).

Step 3, IIS Web Services Extensions
You now have to change the web services extension, which probably means add a new one, then remove the old one. I know this is slightly different between the versions of Windows, but here's how it's done on Windows 2003 Server. While you are still in IIS Manager from above, instead of right clicking on "Web Sites", right click on "Web Services Extensions", select the existing PHP extension and click on Properties button. Add the file location and name (in this case C:\Program Files\PHP\php5isapi.dll ), then remove the old file (in this case C:\Program Files\PHP\php-cgi.exe ).

Step 4, Restart the Web Services
Stop and restart the web services. Because you've changed the system environment variables, you may also need to restart your server, but this is dependent on the verion of Windows you are running.

Limitations
Despite the promises made in the article, I don't see anything in the img_auth.php script that checks for user or user group permissions. The only check made is whether the user is logged on, or whether the file is in a whitelist. Barrylb 20:57, 20 June 2008 (UTC)

re:Limitations --jdpond 10:19, 21 June 2008 (UTC)

 * Barry, you are correct. In order to use access restrictions you will need to  use an authorization extension.  If you do so, please note:  there are security issues

re:Limitations Barrylb 06:39, 22 June 2008 (UTC)

 * Looks like the only thing missing is a userCan 'read' hook called from the img_auth.php script. That would be consistent with how it is handled in other parts of the system.

re:Limitations --Charlener 14:23, 21 August 2008 (UTC)

 * What I was really interested in was the idea of namespace restrictions. Though, if I read this correctly, it's based on physical path?  And no matter where you actually display pictures/files/etc., they all ultimately belong part of the Images: namespace, right?  So to me it seems that if you want access to openly available image files, but want others restricted due to being linked/uploaded to a protected namespace, you would somehow have to have multiple Image:-style namespaces, then you could write whatever code necessary to check for namespace ownership and authentication, blah blah blah. Or is there another way to do this? I'm using Lockdown but don't see any way to make some uploaded images protected and some not, even if (cgi_)img_auth.php supported restriction by namespace.

re:Limitations --jdpond 15:50, 21 August 2008 (UTC)

 * OK, I wasn't going to go there on this one, but I have modified all of my wikis to use namespace based access restrictions.


 * I only did this for versions 1_10_0 and 1_9_3 because the whole repo section was being rewritten by Tim Starling. He made some major mods to 1_11_0 and I believe even more to subsequent versions.  Rather than try and keep up (you'll see the patches were not insignificant), I decided to wait until stabilized before re-implementing, possibly by using hooks vs patching, but more likely through class extensions.


 * I wrote an extension to the lockdown extension and I'm using it extensively on several wikis. The concept is this (where [ns] is your protected namespace ):
 * SpecialUpload into [ns]:[yourfile.jpg]
 * Reference as Image:[ns]:[yourfile.jpg] or Media:[ns]:[yourfile.jpg]


 * For example, given the protected namespace 'TEST', you would upload into TEST:Somefile.jpg and access as [[Image:TEST:Somefile.jpg]]


 * This enhancement was submitted as a bugfix, but given a wontfix status by the MediaWiki powers that be. The alternative is to use the new file classes, which I think are available in the new release 1.11.  If this is the case, I haven't spent the time yet to extend the classes instead of using this awkward syntax.  Wish me luck and I'll post here if successful.


 * If you want to try this out, go to NS Test Wiki and self-register. I'll grant access for testing to Testing Namespace-Based Protection.


 * If you need (or want) these patches, you can download them, but they are only available for MW 1.9.3 and 10.0.0:


 * Image NS Protection (Windows Zip)
 * Image NS Protection (TAR)

img_auth-Links wrong (%2F instead of /) 15:25, 11 February 2009 (GMT)
Hi, i configured my wiki with img_auth, but now all links went wrong :-( when i link to /blafasel/test.jpg the source code looks like img_auth.php/%2Fblafasel%2Ftest.jpg and there is no picture to show...

Image Authorization Total Problem
Hi! I set up Image Authorization with img_auth.php and uploading images is OK. Images placed in directory. But I can't access these images, every time I try to view images I get an error: "Access Denied The function of img_auth.php is to output files from a private wiki. This wiki is configured as a public wiki. For optimal security, img_auth.php is disabled in this case".

I don't understand what happens. All config is right and I changed it thousands times in different ways but always got the same error. Can anybody help me?


 * I met the same problem; solution: in your LocalSettings.php add the following:

or edit the img_out.php to eradicate all the security checks.--Fpiraneo 17:31, 23 June 2009 (UTC)

No access to /images/thumb (resp. \Images\Thumb) in 1.17 on a Windows 2003 Server machine
After installing 1.17 the wiki did not show downscaled pictures (thumbs), using img_auth.php. All native scaled pictures were fine. "Produktion" of the thumbs even worked. I found that replacing the img_auth.php and img_auth.php5 file from 1.16.5 works fine. Well, I dont speak php but there are some changes in 1.17 with the lines 40 -60 that somehow effect the "path"-variables - perhaps they forgot the backslash (\) as path-separator on windows.

Just to avoid mixing up of code and contents: How to?
Yes, I'm trying to separate the code of MediaWiki from uploaded files (images and so on) but I was compelled to create a private wiki; it's normal or I can use other workarounds? --Fpiraneo 17:45, 23 June 2009 (UTC)

Re:Just to avoid mixing up of code and contents: How to? --jdpond 02:35, 12 July 2009 (UTC)

 * Just released Extension:NSFileRepo

File type problem with MS Ofice 2007 files (and how to fix it)
When using img_auth for serving Microsoft office 2007 files such as pptx, docx, etc., the script reports a wrong mimetype so that users of the Windows operating system may have problems saving and opening the files. This is not caused by server settings, but can be fixed by adding the appropriate mimetypes to MediaWiki's file ./includes/mime.types as described in Bug 23688. --Markus Krötzsch 08:04, 28 May 2010 (UTC)

Works with Fast CGI on IIS 7 / Win Server 2008 - 27 April 2011
I was able to secure the images folder using Fast CGI on IIS 7, but it works a little differently. Instead of creating a virtual directory, open an elevated command prompt on your server and use the following command:

%windir%\system32\inetsrv\appcmd set config "nameofsite/virtualdirectoryname" -section:system.webServer/httpRedirect -enabled:true -destination:"destinationofredirect" -commitpath:apphost

Replace "nameofsite/virtualdirectoryname" with your site's name in IIS / path to the default images folder. For example: "Main Site/wiki/images/".

Also replace destinationofredirect" with the relative path to img_auth.php. For example: "wiki/img_auth.php".

This should add a re-direct rule to the site's config file. Follow the rest of the instructions given on media wiki's configuration page. So far it's working for me.

Conflict with Mediawiki 1.16.3+ ?
Starting with Mediawiki 1.16.3 a .htaccess file comes with the distribution in the /images directory. This was added due to a bug fix to prevent XSS problems. However the (cgi_)img_auth.php instructions say to set a .htaccess in the /images directory with one line: "Deny from All".

The new /images/.htaccess file prevents the XSS error, but with (cgi_)img_auth.php the user is routed away from the /images/.htaccess and sent through (cgi_)img_auth.php, which accesses the files. Doesn't this essentially work around what prevents the XSS problem and thus would allow XSS attacks?

1.16.3+ comes with a new modified img_auth.php but cgi_img_auth.php has not been updated since 2007. And in both cases the instructions say to set /images/.htaccess to "Deny from All".

Can someone update this page to reflect the changes made in 1.16.3+ ? 128.231.77.53 15:08, 13 May 2011 (UTC)

Can't download CGI-supporting image authorization script
The link to the cgi script is broken. Can someone please make this available?

Filenames with extra periods return 403 error
A user reported this issue trying to access an uploaded file that had an extra period as a separator in the filename. I couldn't find a way to prevent users from uploading these filenames so I had to find the cause.. After much digging I worked out that the problem was caused by the following code in img_auth.php:

This code is checking for a period and if there is one, then it is defining everything after the period (the first one) as the file extension to check against the whitelist. Hence the error occuring only when people tried to access the file but no issue when uploading it.

I googled the bug and found this gossamer thread which indicates it is a workaround for a security issue (potential exploit) found only in IE6 and earlier.

Our wiki is on a closed network and we obviously don't use IE6 at this point so I commented out the offending code and this resolved the problem.

Hope this info is useful to anyone else that encounters this issue. I think this should be reported as a bug as well as the code above should be amended to grab only the text after the LAST period.

--142.31.70.50 18:22, 12 September 2011 (UTC)