Jump to content

Manuel:Cloudflare

From mediawiki.org
This page is a translated version of the page Manual:Cloudflare and the translation is 100% complete.
Languages:

Cloudflare (cloudflare.com) est un réseau qui fournit du contenu commercial avec une défense intégrée contre le déni de service (DdoS). Comme il travaille en tant que proxy inverse et serveur de noms de domaines pour votre site web, il peut fournir un mécanisme utile de transition IPv6 si votre fournisseur d'hébergement ne fournit pas IPv6 en natif.

Comme avec les autres proxy inverse (voir le proxy du cache), il existe des problèmes de configuration avec tout serveur qui se place en ligne entre l'utilisateur et Mediawiki. Cloudflare doit être informé de ce qu'il faut mettre en cache (et quand supprimer le contenu obsolète). De la même manière MediaWiki (ou Apache) ont besoin de connaître tout proxy de confiance dans le circuit pour s'assurer que l'adresse IP de l'utilisateur (et non pas celle des serveurs Cloudflare) est listée dans Special:RecentChanges ou tracée par Extension:CheckUser .

Avantages et limites

Cloudflare ne facture pas actuellement par mégaoctet par seconde ni par gigaoctet ou téraoctet de données transférées; (à partir de 2025) le service de base, avec certaines limitations, est gratuit. Pour les sites qui reçoivent des demandes de volume élevé pour le même contenu inchangé (comme les images, qui représentent généralement plus de 80% des coûts de bande passante), placer un domaine occupé derrière un service comme Cloudflare peut réduire considérablement ses coûts d'exploitation. Comme les demandes sont moins nombreuses aux serveurs d'origine, le site peut parfois fonctionner plus rapidement.

Les compteurs de pages vues individuelles sont cassés sous Cloudflare, car la plupart des requêtes n'atteignent jamais les serveurs d'origine et le propriétaire du site wiki individuel n'a pas accès aux journaux de Cloudflare. Cloudflare vous fournit des statistiques pour dire combien de personnes visitent votre site, mais pas par page.

Le contenu du site est décrypté et réencrypté sur les serveurs Cloudflare - une vulnérabilité potentielle l'homme au milieu.

Cloudflare prend le contrôle du DNS pour l'ensemble de votre domaine; cela peut être un problème si vous utilisez des domaines dans lesquels les sous-domaines individuels sont partagés entre les utilisateurs avec un service comme freedns.afraid.org, ou si vous utilisez d'autres services qui s'attendent à être votre fournisseur de DNS. Cloudflare offre une protection contre les attaques DDoS pour le Web, mais pas pour le courrier électronique ou d'autres services; à moins que vous ne supprimiez les enregistrements MX pointant sur votre propre domaine, les adresses de ces enregistrements peuvent toujours être utilisées pour trouver votre serveur d'origine sous-jacent et le cibler pour DDoS ou les abus.

Cloudflare place votre site derrière différents serveurs anycast dans plusieurs pays. Cela peut être un avantage si le fait d'être géographiquement plus proche de vos utilisateurs rend votre site visible plus rapidement, mais peut être un inconvénient juridique pour les sites qui sont visés par le tourisme de calomnie ou qui traitent de questions politiquement sensibles. Bien que la censure du contenu par Cloudflare soit rare, elle n'est pas complètement isolée du climat politique de son pays d'origine; les incidents dans lesquels Cloudflare a supprimé des sites en raison de leur contenu incluent Switter (un site de microblogging pour les travailleurs du sexe) et Daily Stormer (un site politique d'extrême droite). De même, un site comme Wikileaks ne voudrait peut-être pas d'un serveur américain dans le chemin des données s'il discute des informations sensibles sur les agences de renseignement américaines; à mesure que Cloudflare étend l'infrastructure dans d'autres pays (y compris en Russie) le nombre de gouvernements auxquels il est potentiellement exposé ne fait que croître. Un site qui discute des activités légales dans son propre pays mais illégales dans un ou plusieurs des serveurs Cloudflare pourrait vouloir éviter d'utiliser le service et garder son réseau de distribution de contenu chez lui.

Cloudflare ne fonctionne pas parfaitement en Chine car le Grand Firewall de Chine bloque souvent le trafic des serveurs Cloudflare.

Comme tout service gratuit ou tiers payant, il y a aussi le risque que ce qui est gratuit aujourd'hui devienne un service payant et cher demain, et qu'il devenienne lent ou instable, ou simplement qu'il disparaîsse. Soyez prêt à revenir aux entrées DNS de votre enregistrement de domaines de votre service d'origine (ou à un autre fournisseur) si le service Cloudflare freemium venait à disparaître.

Intégration à MediaWiki

La stratégie de mise en cache de MediaWiki est conçue pour fonctionner avec avec des serveurs proxy inverses et à source libre (voir Proxy de cache). Dans une configuration à un seul serveur, cela ressemble à :

monde extérieur ⇔
serveur

accélérateur Squid ou Varnish
w.x.y.z:80

⇔

serveur web Apache
127.0.0.1:80

Lorsqu'un utilisateur anonyme a demandé une page, Squid ou Varnish a vérifié si une copie était déjà stockée. Si une telle page était disponible, elle était servie directement sans même interroger le serveur d'origine. Sinon, la demande serait transmise à Apache et à MediaWiki.

Cela a permis d'économiser des quantités significatives de temps de traitement (puisque MediaWiki ne régénérait plus systématiquement le même code HTML pour les pages fréquemment consultées), mais a eu diverses conséquences sur la configuration du serveur MediaWiki :

  • L'adresse du proxy Squid ou Varnish devait être maintenue hors de Special:RecentChanges, à la place en utilisant l'adresse IP de l'utilisateur dans l'entête X-Forwarded-For.
  • Les serveurs proxy devaient être informés lorsqu'une page était modifiée, afin qu'ils puissent supprimer la version obsolète. Ceci a été réalisé de LocalSettings.php avec les entrées telles que :
    $wgUseCdn = true;
$wgCdnServers = [ '<your IPv4 address>' ];
$wgCdnServersNoPurge = [ '127.0.0.1' ];
  • Pour les configurations avec MediaWiki 1.33 ou plus ancien, remplacer Cdn par Squid.
  • Le proxy devait éviter de mettre en cache les contenus dynamiques qui changent fréquemment ou de manière pseudo aléatoire, comme des pages spéciales ou la sortie de certaines extensions telles que Extension:DynamicPageList ou Extension:RandomSelection .
  • Les pages qui affichent une bannière You have new messages pour indiquer qu'il y a des messages ou des drapeaux similaires, ne peuvent pas être mises en cache
  • Les pages pour les utilisateurs connectés (car elles contiennent des noms de connexion ou des informations d'identification) ne peuvent pas être mises en cache
  • La protection contre les liens directs (hotlinks) vers les images a dû être sortie de Apache et déportée sur tout serveur que l'utilisateur pouvait rencontrer
  • Le support IPv6 et HTTPS a également été déplacé vers le serveur que l'utilisateur rencontrait.

MediaWiki envoie des entêtes HTTP (comme cache-control: private si un élément ne doit pas être mis en cache, ou un délai d'expiration si l'élément se retrouver dans le cache pendant un temps limité) qui sont reconnues par Squid ou Varnish. Squid ou Varnish envoie X-forwarded-for: pour indiquer l'adresse IP de l'utilisateur à une installation MediaWiki qui se trouve derrière un proxy Squid / Varnish. MediaWiki envoie également des requêtes HTTP PURGE pour notifier Squid ou Varnish qu'un élément a été changé et doit être supprimé.

Comme MediaWiki a été conçu pour travailler avec Squid ou Varnish, son installation et le cache sont intimement liés.

Dans certains cas Cloudflare fournit une fonction qui pourrait jouer un rôle similaire, mais il l'implémente de manière non standard ou incompatible. MediaWiki peut fonctionner derrière Cloudflare, mais il y a quelques problèmes de configuration à résoudre.

Identification des adresses d'utilisateurs anonymes

Si un utilisateur se connecte directement à une installation MediaWiki (sur Apache), l'adresse IP de l'utilisateur est signalée par PHP dans $_SERVER['REMOTE_ADDR'] et aucune configuration supplémentaire n'est requise pour obtenir les informations dans Special:RecentChanges

Comme MediaWiki bloque typiquement les adresses IP abusées, en utilisant Cloudflare comme adresse dans Special:Recentchanges on rend moins efficace les efforts pour bloquer sélectivement le spam et le vandalisme.

Apache : mod_remoteip

Cloudflare recommande l'utilisation de mod_remoteip pour configurer Apache afin qu'il signale correctement les adresses IP originales des requêtes entrantes. Voir les instructions détaillées sur la reconfiguration d'Apache avec différents systèmes d'exploitation. Notez que Cloudflare ne recommande plus l'utilisation de mod_cloudflare à cet effet.

MediaWiki: $wgUseCdn et $wgCdnServersNoPurge

Depuis la version 1.23, MediaWiki prend en charge la fourniture de la liste des proxy de confiance en notation CIDR, de sorte que la liste des intervalles d'adresses IP Cloudflare peut être transmise directement à MediaWiki pour validation. Voir Cloudflare : intervalles d'adresses IP. 

$wgUseCdn = true;
$wgCdnServersNoPurge = [ <list of Cloudflare ranges> ];

Comme Cloudflare fournit l'adresse IP du client dans l'entête X-Forwarded-For, en remplissant ces valeurs on permet simplement à MediaWiki de les reconnaître correctement. Voir les Entêtes HTTP Cloudflare.

Ceci est la configuration recommandée pour MediaWiki 1.34+ (certainement pour ceux qui ne peuvent pas utiliser mod_remoteip, qui se suffit à lui-même). Dans les anciennes versions, les variables équivalentes sont $wgUseSquid et $wgSquidServersNoPurge.

Comme la liste des intervalles d'adresses IP Cloudflare évolue dans le temps, vous devrez la vérifier périodiquement pour mettre à jour cette valeur.

Squid ou Varnish

Si une installation MediaWiki se trouve derrière Squid ou Varnish, MediaWiki doit être configuré pour utiliser l'entête X-Forwarded-For avec une liste de proxy de confiance configurés dans $wgCdnServers ou $wgCdnServersNoPurge.

Tout serveur de cache local existant (tel que Squid ou Varnish) devra être supprimé si on utilise mod_cloudflare; sinon mod_cloudflare verra l'adresse de Squid (qui ne sera pas reconnue comme un proxy de confiance) et il transmettra la requête non modifiée, et MediaWiki remplacera l'adresse de Squid par la nouvelle adresse reçue de l'amont ... c'est à dire Cloudflare. Vous pouvez aussi essayer d'ajouter Squid à la liste des proxy de confiance en utilisant la directive CloudflareRemoteIPTrustedProxy.

Contrôle du cache

Principes de base

Par défaut, MediaWiki initialise certaines entêtes HTTP (telles que Cache-Control: private pour les utilisateurs connectés, ou Expires pour les pages mises en cache) pour contrôler si le contenu généré automatiquement est mis en cache et pendant combien de temps. Pour le contenu purement statique, tel que les fichiers d'images, les entêtes sont générées par le serveur web.

Cloudflare respecte cela par défaut; voir ici.

Vous pouvez vérifier si une page donnée est mise en cache par Cloudflare en regardant les entêtes renvoyées du serveur (utiliser le mode développeur de votre navigateur) et en recherchant l'entête CF-Cache-Status; CF-Cache-Status: DYNAMIC signifie "votre serveur web m'a dit de ne pas mettre cela en cache".

Les valeurs par défaut de MediaWiki à ce sujet sont cependant extrêmement conservatrices. Par défaut, il dit principalement "ne rien mettre en cache sauf les images et les fichiers CSS" pour les fournisseurs de cache amont. Si vous souhaitez utiliser le cache Cloudflare pour servir votre site dans le cas où votre serveur se bloque, ceci ne vous aidera pas.

Pour que MediaWiki permette à Cloudflare de mettre en cache la plupart des pages (c'est-à-dire la plupart des éléments qui ne sont pas *complètement* dynamiques), vous devez définir ce qui suit dans LocalSettings.php : 

$wgUseCdn = true;  // anciennement $wgUseSquid = true;

Si vous faites cela, alors la règle de page Cloudflare "Cache Everything" mettra en cache la plupart des éléments; sans cette modification de LocalSettings, il sera simplement ignoré à moins que vous n'annulliez également le contrôle du cache d'origine, ce qui n'est pas une bonne idée car vous stockerez beaucoup trop d'éléments.

Redéfinir le contrôle du cache Cloudflare

A partir de Mes sites web → paramètres → Règles de page , il est possible de créer trois règles par domaine (davantage pour les utilisateurs payants). Chacun correspond à un motif (comme *example.org/wiki/* pour toutes les pages wiki de example.org et de ses sous-domaines, en vue standard) et permet la configuration de :

  • Custom caching - permet de redéfinir les entêtes de contrôle de cache, "Cache everything" est le plus agressif et peut convenir pour les fichiers d'image statiques mais n'est certainement pas souhaité pour autre chose. Special:Recentchanges ou les autres contenus dynamiques doivent utiliser les paramètres les moins agressifs.
  • Edge cache expire TTL - dans le mode tout mettre en cache, il redéfinit le temps au bout duquel Cloudflare demande au serveur d'origine une nouvelle copie de la page ou du fichier. Si l'utilisation se fait avec un contenu autre que statique (images), la mise en cache d'éléments qui ne doivent pas être mis en cache peut annuler les directives de contrôle de cache du serveur d'origine.[1]
  • Browser cache expire TTL - indique le temps après lequel le navigateur de l'utilisateur doit demander une nouvelle copie de la page à partir de Cloudflare

Il y a aussi Always Online pour rester toujours en ligne (qui fait que Cloudflare fournit les copies des pages à partir du cache si le serveur d'origine est hors service) et Origin Cache Control (qui indique à Cloudflare de répondre aux entêtes de contrôle du cache envoyées par le serveur d'origine, comme no-cache pour les pages fournies aux utilisateurs connectés).

Il est préférable de mettre en cache les fichiers d'images statiques de manière agressive (cache everything serait valable pour les images, s'il y avait un moyen de les purger lorsqu'une nouvelle version est téléversée). Les pages wiki ordinaires doivent utiliser des paramètres qui respectent les entêtes de contrôle du cache (standard, origin cache control on convient, cache everything pose problème) et les pages de l'espace de noms special: ne doivent pas être mises en cache même brièvement (pour rester actuelles).

Par exemple, ces déclarations :

  1. /load.php?*
    Toujours en ligne : On, Niveau de cache : Tout mettre en cache, TTL du cache navigateur : un an, TTL du cache Edge TTL: un mois
  2. /wiki/*:*
    Niveau de cache : transit
  3. /wiki/*
    Toujours en ligne : On, Niveau de cache : Standard, Contrôle du cache d'origine : On

produirait :

  1. load.php doit toujours être mis en cache (ce qui pourrait facilement réduire la charge sur le serveur d'origine de 25 à 50%, car load.php sert le CSS et le JS qui sont constamment chargés sur chaque page). Les paramètres par défaut sont redéfinis pour garder à tout prix ces pages dans le cache pendant le temps maximal attribué.
  2. pages wiki hors espace de noms principal (telles que Special: Talk: Project:) à ne jamais mettre en cache, si bien que Special:RecentChanges et similaires afficheront toujours les données à jour
  3. enfin, les pages wiki de l'espace principal (qui n'ont pas été détectées par la règle précédente) sont mises en cache comme indiqué par le serveur origine (MediaWiki leur attribue une durée de vie assez longue avec un état "must-revalidate"; les pages fournies aux utilisateurs connectés ou qui affichent des bannières "you have new messages" doivent être "no-cache" pour ne pas être fournies aux visiteurs suivants).

Ces paramètres supposent que le comportement standard ou par défaut pour Cloudflare mettra en cache les fichiers statiques évidents (.jpg .png .gif) mais qu'il faut indiquer explicitement à Cloudflare de mettre en cache la sortie de load.php (qui, autrement, aurait été confondue avec un contenu très dynamique et variable).

Ils sont assez agressifs et peuvent présenter quelques défauts :

  • Les utilisateurs connectés peuvent aussi recevoir les pages de l'espace Main: et venant du cache dans la vue standard comme si ils étaient déconnectés. Alors que Cloudflare mentionne le paramètre Bypass Cache on Cookie pouvant détecter les cookies de connexion de MediaWiki et fournir une page rafraîchie à tous les utilisateurs connectés, ce paramètre n'est disponible que pour les plans payés les plus chers, qui (à quelques centaines de dollars mensuels par domaine) ne sont pas une alternative raisonnable pour la plupart des petits sites. Si vous avez le plan nécessaire, assurez-vous de définir $wgULSAnonCanChangeLanguage et $wgULSLanguageDetection à false si Extension:UniversalLanguageSelector est installé, ceci pour empêcher Cloudflare de mettre en cache les interfaces traduites.
  • Les téléversements qui remplacent une image en la réécrasant par une autre de même nom ne seront pas détectés; Cloudflare suppose qu'il s'agit de contenu statique et met en cache de manière agressive. La configuration standard MediaWiki+proxy de cache lui permet d'envoyer un message HTTP PURGE pour supprimer le contenu obsolète; les extensions telles que Extension:CloudflarePurge lui permettent d'envoyer un message de purge équivalent vers l'API propriétaire de Cloudflare.

Effectivement, il est possible de réduire la charge sur les serveurs d'origine jusqu'à 75% en mettant en cache le contenu avec Cloudflare, mais cela comporte le risque de servir des pages ou des images obsolètes.

Segmenter votre site

Si vous souhaitez réellement que Cloudflare mette en cache presque tout (en utilisant sur la fonction Always Online de Cloudflare, ce qui signifie que vous mettez en cache agressivement car Cloudflare ne peut pas montrer une page au public tant qu'elle n'est pas dans le cache), mais que vous voulez aussi que les éditeurs puissent travailler, une option quelque peu extravagante est de créer un deuxième site web qui utilise les serveurs de la même base de données en lui donnant une URL différente, et de laisser Cloudflare mettre en cache uniquement le site principal.

Vous pouvez ensuite rediriger les éditeurs vers la site actif, celui que Cloudflare met en cache. Avec Apache, ceci fonctionne assez bien :

Sur le site normal : 

# diriger les éditeurs et les personnes qui recherchent des pages spéciales sur le site actif
RewriteCond %{QUERY_STRING}           Special:
RewriteRule .*                        https://live.mysite.com$0 [R=302,L]

Sur la site actif : 

# diriger les non-éditeurs vers le site en cache; ne pas renvoyer les utilisateurs sur
# les pages Special: car ils sont dirigés ici à partir
# de l'autre site sur les pages spéciales pour éviter le bouclage.
RewriteCond %{HTTP_COOKIE}            !mediawiki_session
RewriteCond %{QUERY_STRING}           !Special:
RewriteRule .*                        https://www.mysite.com$0 [R=302,L]

Exemple de règles de page sur le côté Cloudflare pour aller avec une telle configuration : 

*mysite.com/*Special:*
Cache Level: Bypass

*mysite.com/*Talk:*
Cache Level: Bypass

*mysite.com/*
Always Online: On, Cache Level: Cache Everything

Purger HTTP

Lorsqu'un nouveau contenu est téléversé dans MediaWiki, le logiciel du wiki demande que chaque serveur (de la configuration dans $wgCdnServers ) supprime la version obsolète de la page ou de l'image. Cette notification n'est pas envoyée aux proxies web tiers (comme ceux listés dans Extension:TrustedXFF ) et semble codée en dur dans SquidPurgeClient.php dans le code du noyau MediaWiki sans accroche qui permettrait à une extension de modifier ce comportement.

Le message tel qu'il est envoyé par MediaWiki est similaire à : PURGE http://wiki.example.org/images/0/01/Some_image_recently_replaced.jpg

Squid honorera cette requête si elle provient d'adresses IP fiables. Ce qui n'est pas toujours le cas de Cloudflare.

Il existe un moyen de demander manuellement à ce qu'un fichier obsolète soit supprimé (à partir de Mes sites web pour un domaine faire → Paramètres Cloudflare → Purge du cache, cliquer sur purger un fichier unique et entrer l'URL du fichier à purger) mais c'est encombrant et l'utilisation de jokers n'est pas prise en charge. [2]

L'API de Cloudflare fournit la fonction zone-purge-individual-files pour purger un fichier donné mais actuellement rien n'est disponible pour appeler cette API automatiquemt à partir de MediaWiki. En conséquence, un wiki derrière Cloudflare continuera à afficher des versions obsolètes du contenu jusqu'à ce que les données expirent normalement dans le cache. Voir bugzilla:62356.

Cloudflare n'offre pas d'équivalent direct au paramètre negative_ttl de Squid, qui contrôle le temps pendant lequel un code d'erreur renvoyé pour une URL à partir d'un serveur d'origine reste en cache (mise en cache négative) jusqu'à ce que la requête soit réitérée. Si Cloudflare doit tout mettre en cache avec une longue durée de vie, il peut être nécessaire de supprimer manuellement les URL où Cloudflare a stocké un message d'erreur pour lequel l'erreur a depuis été corrigée en amont.

Pages pour mobile via l'extension MobileFrontend

Extension:MobileFrontend fournit une configuration dans laquelle les navigateurs pour mobile sont détectés automatiquement. Cela peut causer des ravages aux systèmes de mise en cache externes; alors que Varnish peut être configuré pour détecter automatiquement un navigateur mobile et servir une version différente de la page, le cache Cloudflare ne peut pas le savoir – et même servir une version incorrecte. Il est préférable de désactiver la détection automatique et de fournir la version pour mobile depuis un sous-domaine différent (par exemple : mobile.www.example.org pour la version mobile si le site pour bureau est www.example.org).

Pour désactiver la détection automatique de Mediawiki des navigateurs sur mobile, essayer : 

$wgServer = "//www.example.org";
$wgCanonicalServer = "https://www.example.org";
$wgMobileUrlCallback = fn ( $domain ) => "mobile.$domain";
$wgMFAutodetectMobileView = false;

Ceci place les versions mobile et bureau dans des sous-domaines séparés.

Cloudflare peut ensuite être configuré pour fournir l'autodétection du navigateur sur mobile pour leurs serveurs. Malheureusement, Cloudflare ne fournit cette détection automatique que pour le domaine de base (example.org) et le sous-domaine www. (www.example.org); tous les appareils mobiles gérés qui visitent les deux parties du site seront automatiquement redirigés vers un autre sous-domaine (tels que mobile.www.example.org) du même domaine. Tout autre sous-domaine (tel que wiki.example.org ou en.wiki.example.org) peut recevoir la version pour mobile (m.wiki.example.org ou m.en.wiki.example.org) mais les navigateurs pour mobile seront détectés automatiquement par Cloudflare que sur le domaine de base ou le sous-domaine www. Les visiteurs de en.wiki.example.org devront à la place cliquer sur les liens Version mobile ou Version de bureau en bas de chaque page web pour sélectionner la version souhaitée (une limitation gênante si vous servez des wikis, ou une Manuel:Famille de wikis entière, en plusieurs langues comme étant des sous-domaines d'un domaine principal).

A partir de l'onglet de performance (Speed) sur le tableau de bord web de Cloudflare pour chaque site individuel, allez à Mobile Redirect pour rediriger sur mobile, sélectionnez un sous-domaine qui contient la version pour mobile (par exemple, mobile.www.example.org), sélectionner Keep path pour garder le chemin et activez la fonctionnalité.

Dans les configurations du DNS et du serveur web Apache, les sites pour bureau et pour mobile pointent vers la même installation MediaWiki; MediaWiki examine alors l'URL pour déterminer si Cloudflare demande la version mobile.

Si MediaWiki ne force pas correctement le sous-domaine du mobile en mode toujours mobile, modifier ./extensions/MobileFrontend/includes/MobileContext.php pour insérer ce contrôle supplémentaire au début de la fonction usingMobileDomain() peut vous aider : 

        public function usingMobileDomain() {
                if (isset($_SERVER['SERVER_NAME']))
                   if ((substr($_SERVER['SERVER_NAME'],0,2)=='m.') || (substr($_SERVER['SERVER_NAME'],0,7)=='mobile.'))
                        return true;

... avec le reste du code inchangé. Ceci n'est nécessaire que si m. ou le sous-domaine mobile. reçoivent du trafic de clients qui n'ont pas été detectés comme des navigateurs sur mobile.

Si les utilisateurs sur mobile ne peuvent plus afficher la vue normale pour bureau via le lien de la vue pour bureau en bas de la page, modifier ./extensions/MobileFrontend/includes/MobileContext.php en changeant le nom et la valeur des cookies peut aider :

Au début de la classe MobileContext : 

public const STOP_MOBILE_REDIRECT_COOKIE_NAME = '__cf_mob_redir';

Au milieu de la fonction setStopMobileRedirectCookie() : 

		$this->getRequest()->response()->setCookie(
			self::STOP_MOBILE_REDIRECT_COOKIE_NAME, '0', $expiry,
			[
				'domain' => $this->getStopMobileRedirectCookieDomain(),
				'prefix' => '',
				'secure' => (bool)$stopMobileRedirectCookieSecureValue,
			]
		);

Au milieu de la fonction shouldDisplayMobileViewInternal() : 

		$stopMobileRedirect = $this->getStopMobileRedirectCookie();
		if ( $stopMobileRedirect == '0' ) {
			return false;
		}

Cette méthode vous oblige à cliquer deux fois sur le lien pour rediriger vers la vue de bureau.

Lien direct vers les images

De nombreux forums basés sur le web sont réputés pour encourager les utilisateurs à lier directement les images hébergées sur d'autres sites. Leur site semble afficher l'image, mais utilise la bande passante que les opérateurs du site cible pointé par ces liens, doivent payer. Une défense commune pour les webmasters Apache est de déployer mod_rewrite pour regarder la ligne de Referer (sic) de chaque demande et rejeter celles qui ont un accès direct (.jpg, .png, .gif et al.) pour être utilisées sur les pages d'un autre site.

Quelque soit le serveur de cache, les serveurs d'origine n'ont plus d'interface directe avec l'utilisateur. Tout code qui ajoute des liens directs doit être retiré du serveur web d'origine (comme Apache); cette protection est disponible sur Cloudflare si nécessaire.

Commentaires des documents HTML

MediaWiki ajoutera normalement des commentaires tels que &lt; Served by wonky-server.example.org in 666 seconds --> à la sortie HTML pour dépanner; si un site contient plusieurs serveurs Apache qui fournissent le même contenu, il est impossible de déterminer quel serveur a causé un problème spécifique. Cloudflare tente d'optimiser les pages web livrées en supprimant ces commentaires; cette fonction peut être désactivée pour déboguer.

HTTPS

Cloudflare peut être utilisé comme un mécanisme de transition pour passer de http: (non sécurisé) à https: (sécurisé) – bien que cela ne fournit pas un encodage de bout en bout (car il laisse le serveur Cloudflare dans un état de service intermédaire); cela vaut mieux que de ne pas avoir https: du tout.

Toutes les versions de MediaWiki 1.18+ prennent en charge les URLs relatives au protocole, donc il est tout à fait fonctionnel en HTTP et HTTPS, de remplacer un lien tel que http://wiki.example.org with merely //wiki.example.org lorsque vous chargez des images et des ressources. Cette modification n'est pas spécifique à Cloudflare, mais elle impacte tout site MediaWiki disponible à la fois pour HTTP et HTTPS.

IPv6

Toutes les versions actuelles de MediaWiki peuvent enregistrer une adresse utilisateur IPV6 dans Special:RecentChanges quand elle est fournie. Aucune modification n'est requise dans LocalSettings.php de MediaWiki, bien que MediaWiki (et toutes les extensions qui dépendent des adresses IP des utilisateurs, comme CheckUser) doit être une version actuellement prise en charge car certaines versions plus anciennes (MW1.19-) étaient boguées pour enregistrer les adresses des utilisateurs IPv6 dans Special:RecentChanges

Le support IPv6 est activé quelque soit le serveur rencontré par l'utilisateur; Apache pour une installation autonome, Squid/Varnish pour les sites utilisant ces derniers comme proxy inverse, le serveur de Cloudflare pour les sites où Cloudflare est l'interface utilisateur. Il n'est pas nécessaire que la communication du serveur d'interfrace avec l'utilisateur vers Apache supporte à la fois IPv4 et IPv6 et il n'y a aucun avantage à permettre les deux pour les liens vers les serveurs d'arrière plan.

« Mes sites Web → paramètres → paramèters Cloudflare → IPv6 automatique » peut être mis à « full » pour chaque domaine afin d'activer IPv6 sur votre site.

Aucun autre paramètre n'est nécessaire pour IPV6.

Empêcher la création de compte et le vandalisme d'édition via Cloudflare

La formule Cloudflare suivante semble fonctionner pour une petite installation MediaWiki au moment où ces lignes sont écrites, pour empêcher les robots personnalisés de créer des comptes ou vandaliser MediaWiki.

Dans la version gratuite de Cloudflare, allez dans « Règles / règles de configuration » du domaine d'hébergement et ajoutez la règle : 

(http.request.uri contains "action=edit") or (http.request.uri contains "Special:") or (http.request.uri contains "User:") or (http.request.uri contains "diff=")

Avec l'action corresppondante « Security Level: I'm Under Attack » du niveau de sécurité. Cela laisse entendre à Cloudflare que les robots qui attaquent les URL contenant ces phrases ont besoin d'être contrôlés en plus avant le transfert vers le site actif. Votre distance en miles varie; bien tester cette formule avant de déployer.

Extensions

Voir aussi

General
External
Retrieved from "https://www.mediawiki.org/w/index.php?title=Manual:Cloudflare/fr&oldid=8591642"