Manual:Image authorization/fr

Cet article concerne les administrateurs système qui souhaitent restreindre l'accès aux images et aux fichiers en se basant sur les utilisateurs et (ou) les droits des groupes d'utilisateurs.

Les fichiers téléversés sont généralement distribués directement par le serveur web, et non pas via MediaWiki. Alors qu'il existe un niveau minimal de sécurité masqué par l'encodage des chemins (comme /c/c4/...), le chemin peut être calculé facilement à partir du nom de fichier ce qui ne fournit pas de réelle protection.

Ce n'est pas une configuration recommandée. MediaWiki n'est pas conçu pour être un système de gestion de contenu (CMS - Content management system), ni pour protéger les données sensibles. Au contraire, il a été conçu pour être le plus ouvert 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 Security issues with authorization extensions.

Présentation
Par défaut, toutes les images et les fichiers téléversés sont accessibles directement par le serveur web. Si vous souhaitez donner accès uniquement aux utilisateurs autorisés de l'environnement MediaWiki, il faut réunir deux conditions :


 * 1) Le répertoire actuel doit être protégé contre l'accès direct et,
 * 1) MediaWiki Authorization must be invoked when an Image/File access occurs by executing a script when any url containing that directory is requested.

L'implémentation fondamentale nécessite :


 * 1) The images directory  should be moved outside the web root on the file system or otherwise protected
 * 1) Le chemin de téléversement  doit pointer vers.

Dans les deux cas, les mécanismes dépendent de la plateforme du serveur web. Cet article fournit des instructions détaillées pour les deux plateformes :


 * 1) Apache (la plupart des versions)
 * 2) Microsoft Internet Information Server (IIS), version 6.0 et supérieure

Dans toutes les instructions, on suppose que MediaWiki est installé dans.

Par exemple dans :

http://wiki.yourwiki.org/MyWiki

/path/to vaut /MyWiki

Comment fonctionne img_auth.php ?
Image authorisation works by "intercepting" the URL and checking to see if the remainder (PATH_INFO) is in an area where the user has access based on the standard User ID and any Namespace, etc. protections you've assigned. When you've set up the upload path, to point to a directory that automatically redirects to include a script in the path, the script is executed and determines whether or not the file should be accessed.

Voila ce qui se passe réellement. If your pointer to the image/file is set up to, this is translated to    by MW and the server actually executes img_auth.php passing it   in the PATH_INFO server variable.

img_auth.php vérifie ensuite si l'utilisateur a accès à ce fichier particulier et si c'est le cas, il le renvoie. Si ce n'est pas le cas, l'erreur standard 403 est affichée.

Configurer le téléversement des fichiers
Before attempting this configuration it is very important you understand how to configure file uploads. Veuillez prendre quelques instants pour relire et comprendre cet article - cela vous épargnera beaucoup de temps.

Prise en charge du PATH_INFO PHP
This requires that your PHP setup support PATH_INFO (many CGI configurations do not) and you need to be in mode or else, there wouldn't be a point ... unless you just like a more secure MW install; see below.

Un autre scénario dirigé par la sécurité (uniquement pour 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, be it 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.

Une toute première mesure de sécurité pour cela, est de mettre un fichier .htaccess dans le répertoire 'images' avec le contenu suivant :

And that .htaccess must not be writable by the web server! It is a pity, that MW doesn't come with this by default (at least not in 1.6.10).

But even better will be to also move the web server writable 'images' directory outside of the document root, renaming it to something unguessable (e.g. the MD5 hash of &lt;whatever&gt;) and streaming the images via 'img_auth.php', so that the real directory name never ever shows up.

Pour faire cela, suivez les étapes ci-après :

  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)   create the unguessable images/upload directory outside of (in parallel to) your document root (note the  at the end of the path):  déclarez-le accessible en lecture et écriture par le serveur web :   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) :   change your LocalSettings.php config file:  

qui devrait faire ce qu'on attend sans configuration supplémentaire.

That should do the job for web servers with PHP running as an Apache module. Il n'y a pas d'autre modification des fichiers de configuration Apache à faire. Par conséquent vous ne verrez jamais le chemin vers vos images, car img_auth.php intercepte tous les accès en lecture. Mais toutes vos images sont disponibles, y compris les vignettes.

If you use CGI or IIS your milage may vary.

Instructions Apache
Most administrators have found implementation in an Apache Environment straightforward and fairly simple.

 If you are using a GoDaddy shared hosting account, you may need to reference this thread if you are having problems viewing uploaded images with img_auth.php: 

Apache étape 1. Protéger le répertoire Images de l'accès Internet
In your [/path/to]/images directory, create an .htaccess containing one line:

Deny from All

Apache étape 2.1. modifier dans LocalSettings.php. Pas utile si l'étape 2.2 Apache a été faite
is the URL path, not the file system path, so if img_auth.php is in  but is accessed as , the line would read:

Be sure to add a leading slash  if   is actually in your root-directory. Les images ne seront pas affichées du tout si vous oubliez de faire ainsi :

Apache étape 2.2. créer des alias pour exécuter img_auth.php
Mettez à jour le fichier httpd.conf en ajoutant les deux alias suivants :

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

The second [/path/to] on each line should be the absolute path on the file system, and it may be necessary to add a trailing frontslash to img_auth.php (i.e., use [/path/to]/img_auth.php/).

Apache étape 1. télécharger le script cgi de prise en charge d'autorisation d'image
Si PATH_INFO n'existe pas, téléchargez le script CGI de prise en charge des droits des images. Enregistrez le script sous le nom  dans votre répertoire MediaWiki.

Apache étape 2. Protéger le répertoire Images de l'accès Internet
Dans votre répertoire [/path/to]/images, créez un fichier .htaccess contenant une seule ligne :

Deny from All

Apache étape 3.2. modifier .htaccess
Mettez à jour le fichier .htaccess pour qu'il ressemble à

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

Notez par ailleurs que cette étape n'est pas nécessaire avec certaines installations.

Apache - assurez la compatibilité en utilisant des URLs à jour
If your website is rewriting URLs through .htaccess, then you will need an exception before the custom rewrites:

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

(This means: in case of img_auth called, stop rules)

Exemple de fichier .htaccess :

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

Apache - masquer la liste des répertoires
If you don't want user to list your images folder set this up on your Apache configuration:

 Options -Indexes 

Instructions 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.

IIS étape 1. Protéger le répertoire Images de l'accès Internet anonyme
With IIS it is important that users cannot access images or files by using alternative URL paths to the bypass the virtual directory redirect. C'est pourquoi il faut créer un nouveau répertoire hors de la racine de MediaWiki.

IIS étape 1.1 créer un nouveau répertoire physique
Créez un nouveau répertoire physique. This directory should not be inside any other existing web directories or virtual web directories:

Example:

c:\inetpub\wwwroot\MyWikiImg

IIS étape 1.2 vérifiez ou configurez la sécurité des répertoires
The Directory security must allow read, write, modify for the Internet Guest Account (usually IUSR_[server name]). Don't worry, you're going to regulate this in subsequent steps.

IIS étape 2. exécuter le script img_auth.php pour tous les accès au répertoire Image
In IIS this is done by creating a virtual directory with the same name as the physical directory (if your directory is off the root web).

IIS étape 2.1 créer le répertoire virtuel de même nom que le répertoire physique
Create a new virtual directory using Start->Administrative Tools->Internet Information Services (IIS) Manager in the web service you are using for MediaWiki.

Right click on the web service->New Virtual Directory...

In the wizard, create a new virtual directory with the same name as the physical directory and point it to that directory.

IIS étape 2.2 rediriger le nouveau répertoire virtuel vers img_auth.php
Still in IIS Manager, right click on the new virtual directory->Properties select the 'Virtual Directory' tab and change the 'The content for this resource should come from:' to 'A redirection to a URL'. Fill in the 'Redirect To:' with the URL to img_auth in your MediaWiki.

Exemple :

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

N'oubliez pas de cliquer sur Apply pour exécuter.

IIS étape 3 copier l'ancien répertoire image dans le nouveau
Copy the contents of the old images directory ($ip/image) and subdirectories into the new directory you created. Note: The 'image' directory will not exist in the new directory. Le nouveau répertoire ne devrait pas apparaître comme :

Mauvais :

MyWikiImg images 0   1    . ..

Bon :

MyWikiImg 0 1  . ..

IIS étape 4.1 modifier  dans LocalSettings.php
Exemple :

IIS étape 4.2 modifier  dans LocalSettings.php
Example:

IIS étape 4.4 PATH_INFO IIS problématique
If your installation is not working, it may be because img_auth.php requires the server to return PATH_INFO to know exactly which file you wish to access (e.g., everything in the URL after the virtual directory).

There have been several articles and hints that some versions of IIS may disallow the server variables PATH_INFO and PATH_TRANSLATE 'for security reasons'. While we did not have this problem on the current server and patch level (IIS 6.0) it is a noted issue for IIS 4.0 (and possibly prior), you may want to investigate if img_auth.php is not working for you.

The full knowledgebase article may be found at Using PATH_INFO and PATH_TRANSLATED from CGI Applications. The article instructs you on how to run a program written in MS Visual Basic (you may need to load CScript).