Manual talk:Image Authorization
From MediaWiki.org
Contents |
[edit] 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)
[edit] 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
-
[edit] 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)
[edit] re: how does img_auth.php work? --jdpond 19:13, 4 September 2007 (UTC)
Added info - too confusing?
[edit] 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:
- Environment Variables
- IIS Application Configuration
- 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.
[edit] 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\; 
[edit] 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). 
[edit] 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). 
[edit] 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.
[edit] 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)
[edit] 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
[edit] 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.
[edit] 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.
[edit] 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]
- 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):
-
- 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:
