MediaWiki was not designed to support per-page or partial-page access restrictions. If you require this level of control, you are strongly advised to use a content management system that supports it natively. Patches or third-party extensions claiming to provide access control may contain security flaws, potentially exposing confidential data. Use them at your own risk. Neither the MediaWiki developers nor the Wikimedia Foundation are responsible for any data leaks that may result. This message is added to all extensions of this nature and may not reflect the actual security status of this extension. For more information, see Problemas de segurança com extensões de autorização .

Este artigo é para os administradores de sistema que desejam restringir o acesso às imagens e ficheiros com base no utilizador e/ou nas permissões do grupo de utilizadores.

Os ficheiros enviados são geralmente servidos diretamente pelo servidor da Web, e não através do MediaWiki. While there is a minimal level of security through obscurity with path obfuscation (e.g. /c/c4/…), the path can be calculated easily from the file name and does not provide true protection.

This is not a recommended configuration. MediaWiki is not designed to be a CMS, or to protect sensitive data. To the contrary, it was designed to be as open as possible. Thus it does not inherently support full featured, air-tight protection of private content. Any administrator wishing to use this functionality should carefully review Problemas de segurança com extensões de autorização .

Sinopse

By default, all uploaded images (and files) are accessible directly by the web server. If you wish to allow access only to authorized users within the MediaWiki framework, two conditions must be met:

The mechanisms for both are dependent on the web server platform. This article gives detailed instructions for two platforms:

Por exemplo, em:

http://wiki.example.org/MyWiki

"/path/to" é "/MyWiki"

Como funciona "img_auth.php"?

Image authorization works by routing requests for uploaded media files through the img_auth.php script, instead of allowing the webserver to send the file to the browser directly. This is done by setting $wgUploadPath to the location of the img_auth.php script ($wgUploadPath = "$wgScriptPath/img_auth.php";), instead of the upload diectory. This causes MediaWiki to generate file URLs that look something like http://wiki.example.org/w/img_auth.php/01/01/Example.png. When the web server receives a request for such a URL, it will know to call the img_auth.php script and pass it the remainder of the URL as PATH_INFO. The script will then check whether the user has access to the file given in the PATH_INFO, based on the normal mechanism used for managing access to wiki pages. If img_auth.php determines that the user has access to the requested file, it reads the file's content and streams it back to the user, just as if the web server was serving the file directly from the disk. If, however, the user does not have access to the file, img_auth.php returns the standard 403 "Access Denied" error.

Configuração dos Envios de Ficheiro

Before attempting this configuration it is very important you understand how to configure file uploads. Please take a few moments to review and understand this article - it will save you a lot of time.

Suporte para PATH_INFO PHO

This requires that your PHP setup support PATH_INFO (many CGI configurations do not) and you need to be in $wgWhitelistRead mode or else, there wouldn't be a point ... unless you just like a more secure MW install. Veja em baixo.

Outro Cenário, Motivado pela Segurança (APENAS Apache/Unix)

Even if you don't want to restrict access to your images you might want to make use of the img_auth.php mechanism: to avoid publicly accessible directories, where the web server has write permissions. Though a web server writable directory is not insecure in itself, it is the first half of a successful attack to your web server. The second half then would be some exploitable (php) script, being MW or, most likely, some other script. If the attacker can exploit the broken script to upload or generate another script intended to help him with further attacks/spamming etc, the attacker still needs a place to store that script in, writable by the web server ... and has it available and well known in the images directory of MW standard installations.

# No php execution in the upload area
php_admin_flag engine off

1. login in to a shell of your web server (similar actions are often possible with your FTP client, if not, ask your provider to assist you)
2. create the unguessable images/upload directory outside of (in parallel to) your document root (note the /.. at the end of the path):

   cd </absolute/path/to/your/doc_root>/..
   mkdir <dir_name_unguessable>
   

3. make it read/writeable for the web server:

   chgrp <your_web_server_group> <dir_name_unguessable>
   chmod 770 <dir_name_unguessable>
   

4. create the .htaccess file as noted above and make it readable only (this is paranoia, because the web server never looks here, only PHP not taking care of .ht* files normally, but just in case this directory ever will be made available to the web server directly):

   cd <dir_name_unguessable>
   echo 'php_admin_flag engine off' > .htaccess
   chmod 444 .htaccess
   

5. altere o seu ficheiro de configuração LocalSettings.php: $wgUploadPath = "$wgScriptPath /img_auth.php"; $wgUploadDirectory = '</absolute/path/to/your/doc_root>/../<dir_name_unguessable>'; $wgEnableUploads = true; # We don't wanna restrict access, just make our MW install more secure $wgWhitelistRead = false;

That should do the job for web servers with PHP running as an Apache module. No further Apache config file changes are necessary. You then will never see the path to your images, img_auth.php intercepts all read accesses. But all of your images are served, including thumbs.

Instruções de Apache

Deny from All

$wgUploadPath = "[/path/to]/img_auth.php";

$wgUploadPath = "/mediawiki/img_auth.php";

$wgUploadPath = "/img_auth.php";

Alias [/path/to]/images/ [/path/to]/img_auth.php/
Alias [/path/to]/images [/path/to]/img_auth.php

Instruções do Apache sem PATH_INFO com mod_rewrite

Deny from All

$wgUploadPath = "[/path/to]/cgi_img_auth.php";

RewriteEngine on
RewriteRule ^/path/to/images(.*)$ /path/to/cgi_img_auth.php/$1 [R]
RewriteRule ^path/to/cgi_img_auth.php/(.*)$ path/to/cgi_img_auth.php?path=/$1

Apache - Compatibilizar com URLs limpos

RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]

Exemplo de .htaccess:

RewriteEngine On
# First condition&rule:
RewriteCond %{REQUEST_URI} /img_auth\.php/
RewriteRule ^ - [L]
# Rest of rules:
RewriteCond ...
RewriteRule ...

Apache - Negar a lista de diretorias

        <Directory /var/www/wiki/images>
                Options -Indexes
        </Directory>

Instruções de IIS

Implementation in IIS is more complex because it lacks the inherent 'pipe' capabilities of Apache or Unix in general. However using a few tricks, IIS can be made to execute the CGI and achieve protection.

Aviso:

The img_auth approach ONLY works with the PHP ISAPI mode on the WIMP (Windows, IIS, MySQL, PHP) platform. If you followed the standard Windows installation instructions, your wiki will be using CGI (php-cgi.exe) and you will have to convert to ISAPI. Instructions for doing so are in the discussion area. There is a bug in the php-cgi approach in parsing PATH_INFO that will show up as "CGI Error: The specified CGI application misbehaved by not returning a complete set of HTTP headers" on some files in the restricted path. This is a PHP/IIS issue, not a MediaWiki problem.

c:\inetpub\wwwroot\MyWikiImg

http://wiki.example.org/MyWiki/img_auth.php

MyWikiImg
  images
    0
    1
    . . .

MyWikiImg
  0
  1
  . . .

$wgUploadPath = "[NewVirtualDirPath]";

$wgUploadPath = "/MyWikiImg";

$wgUploadDirectory = "[NewVirtualDirImages]";

$wgUploadDirectory = "D:\Inetpub\wwwroot\MyWikiImg";