Manual talk:Image authorization

IIS 6.1 set up

Hi I'm running IIS version 6.1, and it looks like everything has been changed on that. Could someone instruct on how to make this work here.

see also Project:Support_desk#Zip_Error_when_uploading_12025

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?

how to setup LocalSettings.php / .htaccess to make img_auth.php cooperate with Score ?

the Score extension places its *.png files in image/lilypond, the links should point to img_auth.php/nsfilerepo/lilypond instead of img_auth.php/lilypond

as not speaking fluently mod_rewrite I was not successful with

RewriteRule ^/img_auth\.php/lilypond/(.*)$ /img_auth.php/nsfilerepo/lilypond/$1 

nor with

$wgImgAuthUrlPathMapc['/lilypond/'] = 'mwstore://nsfilerepo-fs/namespace/lilypond/';

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):

1. SpecialUpload into [ns]:[yourfile.jpg]
2. 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:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;

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

Before trying the above check the actual error message by adding $wgImgAuthDetails = true; to Localsettings.php. Only then i got the above message. This check can be turned off by setting $wgImgAuthPublicTest = false; Have a look at Manual:$wgImgAuthPublicTest and Manual:$wgImgAuthDetails. C. Holtermann

No access to /images/thumb (resp. \Images\Thumb) in 1.17 on a Windows 2003 Server machine OR Apache / Linux

After installing 1.17 the wiki did not show downscaled pictures (thumbs), using img_auth.php. All native scaled pictures were fine. "Production" 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. 92.79.145.130 11:54, 16 September 2011 (UTC)

I was able to reproduce this using v1.17 running on Apache 2.2.21/Fedora 15 --173.77.16.94 20:21, 12 March 2012 (UTC)

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)

Since "Deny from All" blocks access totally the contents of the .htaccess provided by the software may be replaced by it. Cheers --[[kgh]] 15:45, 19 September 2011 (UTC)

Can't download CGI-supporting image authorization script

The link to the cgi script is broken. Can someone please make this available?

Same problem. Hard to come by. Used a WebArchiv to grab an old Version of the site. (Hope it's the final one.) [1]

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:

// Check for bug 28235: QUERY_STRING overriding the correct extension
$dotPos = strpos( $path, '.' );
$whitelist = array();
if ( $dotPos !== false ) {
	$whitelist[] = substr( $path, $dotPos + 1 );
}
if ( !$wgRequest->checkUrlExtension( $whitelist ) )
{
	return;
}

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)

See Bug 29531. --Fomafix 13:11, 27 September 2011 (UTC)

Replace line 52 from "$dotPos = strpos( $path, '.' );" to "$dotPos = strrpos( $path, '.' );". This fixed the issue for me —The preceding unsigned comment was added by 24.114.255.99 (talk • contribs) 23:10, 27 September 2012‎

Suggestion: authenticate before calling hook

Hi,

I use the ImgAuthBeforeStream hook to notify me of downloads, and include the logged-in username. If a direct link is used, however, the hook is called before authentication (and thus username is empty). I propose a change to the following code:

        // Run hook for extension authorization plugins
        if ( !wfRunHooks( 'ImgAuthBeforeStream', array( &$title, &$path, &$name, &$result ) ) ) {
                wfForbidden( $result[0], $result[1], array_slice( $result, 2 ) );
                return;
        }

        // Check user authorization for this title
        // Checks Whitelist too
        if ( !$title->userCan( 'read' ) ) {
                wfForbidden( 'img-auth-accessdenied', 'img-auth-noread', $name );
                return;
        }

If these two checks are switched, img_auth.php does what I need. If this could be done in the core file, it would be appreciated (so I don't have to modify on each update).

Thanks. —The preceding unsigned comment was added by 82.20.123.138 (talk • contribs) 13:43, 29 September 2012‎

I've removed some extra newlines from this code. --Krenair ^{(talk • contribs)} 13:24, 29 September 2012 (UTC)

On Mediawiki 1.20.2, these steps help avoid public listing of the directory contents but images don't appear on any of the pages

I have the latest version of Mediawiki (1.20.2) installed on a bluehost shared server. I did what was given at Manual:Image_Authorization#Apache_Instructions_without_PATH_INFO_with_mod_rewrite:

Tried all the alternatives suggested on this page. Images are being uploaded to the images directory and 500 Server error is thrown when images directory is accessed through browser but images don't appear on any of the pages. Really strange that such an important functionality is not there as an extension. Pardhu (talk) 04:06, 12 January 2013 (UTC)

Details for Execute Script img_auth.php for all Accesses

I'm looking for more information about this instruction. Running it (with details set to 'true') returns a message that access is forbidden. Can you add some more detail or a working example? CWinDC (talk)

IIS 8 and 8.5 with PHP 5.5 supports PATH_INFO

As of PHP 5.5 and IIS 8, the PATH_INFO tricks required in the instructions no longer appear to be required when using FastCGI. Ensure that cgi.fix_pathinfo is 1, then use IP Address Restrictions to set Deny 0.0.0.0/0.0.0.0 on the images directory. You can then just set $wgUploadPath as with Apache. This vastly simplifies the configuration, which is basically the same as the Apache configuration at this point.

Note that IIS doesn't set PATH_INFO correctly when doing a URL rewrite, so if you want to redirect existing links, you'll need to rewrite to the CGI-compatible script or patch img_auth.php to set $path to the value of the path query string parameter around line 67. (You'll also need to skip the wfForbidden call if that variable is set.) --69.174.87.60 19:43, 14 April 2014 (UTC)

Disrupting section(s)

Can we please move these out of the way of the img_auth.php flow?

• 3 Configuring File Uploads
• 4 PHP PATH_INFO Support
• 5 Another Scenario, Security Motivated (Apache/Unix ONLY)

Thanks 51.6.194.34 06:30, 5 September 2016 (UTC)

nginx configuration?

Is it possible that there isn't any solution/configuration for nginx webserver to restrict the access (as there are configs for Apache)?

Thanks!

That works:

location /images {
	sendfile on;
	auth_request /img_auth.php;
}

Neuteron (talk) 06:50, 3 February 2023 (UTC)

Is IIS Step 2.2 still valid for IIS 8.5?

For IIS 8.5, should HTTP Redirect be used instead of modifying the properties of the added virtual directory? Right-click on the virtual directory, there is no "Properties". Tommy H (talk) 23:45, 1 July 2019 (UTC)

Allowing custom folders

Extension:SocialProfile requires adding the folders "/avatars" and '/awards" to the upload directory in order to provide those features, however it seems that this feature is not possible when using "img_auth.php". Is it possible to configure img_auth.php to ignore these non-standard upload directories?

Thanks!

/Rich

Restricting access to certain files?

How do you use this to restrict access to specific files? I can't see that explained anywhere. InnerCitadel (talk) 11:00, 26 April 2022 (UTC)

apache htaccess only work if AllowOverride is enabled

if your htaccess file doesn't take affect check AllowOverride in /etc/apache2/apache2.conf

default Ubuntu 20.04 seems

AllowOverride None

Also vote that this page could use a re-org.

tx TiloWiki (talk) 19:09, 7 August 2023 (UTC)

img_auth and short-urls

I use short urls like explained on https://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory . The uploaded images are served through img_auth.php by using this Apache2 configuration (excerpt).

Images are served by (unchanged) urls like https://mywikiserver/images/a/a1/image.png but now "invisble" through img_auth.php. The direct access to directory /images is forbidden by the Directory directive .

Apache2 httpd.conf:

# we need to serve i) /images/ through img_auth.php
# ii) small images like buttons from /extensions are served directly as usually
RewriteCond %{REQUEST_URI} "^/images/.*"
RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/img_auth.php [L]

RewriteCond %{REQUEST_URI} "^/images/.*"
RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/img_auth.php [L]

# https://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !img_auth.php
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteRule ^(.*)$ %{DOCUMENT_ROOT}/index.php [L]

<Directory /srv/wiki/images>
        # Options Indexes FollowSymLinks
        # AllowOverride All
        Require all denied
</Directory>

LocalSettings.php:

(no change, especially, I did not set up or changed the $wgUploadPath.) Wikinaut (talk) 17:00, 12 December 2023 (UTC)