Archives du mot-clef htaccess

Empêcher la lecture d’un répertoire avec .htaccess

Laisser une réponse

Il y a peu, latapie.name (naked domain) était lis­table, avec notam­ment l’accès direct aux logs. Merci à Tho­mas pour me l’avoir signalé ! Très facile à régler avec une ligne dans le .hta­cess à la racine : 
[[code]]czoyMDpcIk9wdGlvbnMgQWxsIC1JbmRleGVzXCI7e1smKiZdfQ==[[/code]]
(source : http://www.htaccessredirect.net/)

Differences between Redirect and Rewrite

2 réponses

  • Because I am cra­ving for this for months;
  • Because I only found kilometres-long texts about use, per­for­mance, advan­ced mani­pu­la­tion… but no simple thing at all;
  • Because I like (use­ful) lists.
Here is a short sum­mary of various redi­rect rules and their uses.

Redirect

(1) Redirect, RedirectTemp, Redirect temporary or Redirect 302
URL 1 is redi­rec­ted to URL 2; it is visible in the address bar[1].
(2) RedirectPermanent or RedirectPermanent or Redirect 301
Same as (1), but per­ma­nent[2].
(3) Redirect Seeother or Redirect 303
Tem­po­rary change, do not change the index. Sel­dom used.
(4) Redirect Gone or Redirect 410
The page has disap­pea­red and nothing will replace it. Think of it as a « volun­tary 404″.
(5) Redirect xxx
Redi­rect with the cor­res­pon­ding code.
(6) RedirectMatch
Same as (1), but with regu­lar expres­sions[3].
(7) RedirectMatch Permanent
Same as both (2) and (6)[4].
Notice how (6) and (7) dif­fer from the other: they do not just send a code, they change the beha­viour of the syn­tax. Conse­quenty, it is not pos­sible (AFAIK) to use regexps with other than 301.

Rewrite

Rewrite is dif­ferent and not neces­sa­rily bet­ter. But in any case, it is more com­plex (and I won’t delve into it for now). The main dif­fe­rences bet­ween Redirect and Rewrite are:
  • Redirect uses mod_alias; Rewrite uses mod_rewrite — except for old Apache ver­sion, where both rules use mod_rewrite. Big deal.
  • Rewrite hides the redi­rec­tion to the user — this means the address stays the same in the address bar. That is the main dif­fe­rence bet­ween Redi­rect and Rewrite.
  • Rewrite is the only one able to cope with dyna­mic URL (you know, those damn ques­tion marks in QUERY STRING). Not even Redi­rect­Match can do it (AFAIK).
Redirect is appro­priate when you want people to remem­ber the new address; You may be sure they will copy the good address and that will save you some CPU cycles in non redi­rec­ting any­more. On the contrary, Rewrite is appro­priate when you want the address to stay the same/not to be visible; A good example is hiding the archi­tec­ture (/wordpress/, /wiki/…). Ulti­ma­tely, using one or the other is not a tech­ni­cal consi­de­ra­tion but more of a human and stra­te­gic one.

Examples

Below are examples I use to change domain.tld/images/foo to domain.tld/dotclear/public/images/foo (I actually only use the fourth one). The lea­ding cir­cum­flex (^) is for for­cing the mat­ching string to be at the begi­ning of the address.
  • Redirect ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
  • RedirectPermanent ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
  • RedirectMatch ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
  • RedirectMatch Permanent ^/images/(.*)$ http://blog.empyree.orghttp://david.latapie.name/wordpress/wp-content/uploads/$1
To be com­ple­tely accu­rate, I must say that Rewrite is able to do most, if not all, of what Redi­rect may do, thank to the flags. But that would be ano­ther topic I pre­fer not to speak of here.
  1. Which is a good idea in some contexts; Error code 302.
  2. Error code 301; search engine should update their index (but Google does not).
  3. Don’t use it if you don’t need it: regexp par­sing requires CPU cycles, even when there is no actual regexp to parse.
  4. That is, the resul­ting regexp-powered redi­rec­tions are per­ma­nent (error code 301).
Ils en parlent mais ne me le disent pas, les petits cachot­tiers :

Améliorer son référencement organique

Laisser une réponse

J’en ai assez que mes RSS arrivent en pre­mier dans les résul­tats de recherche Google.

Google spammé par mes RSS

Une solu­tion simple : robots.txt.

User-agent: * Disallow: /feed/
  1. Cette règle concerne tous les robots (*)
  2. Ne pas lire les IRI conte­nant le mot /feed/ juste après le tld

Ainsi, cette adresse ne sera plus récu­pé­rée par les robots (du moment qu’ils obéissent à la conven­tion robots.txt, bien sûr) :

http://blog.empyree.org/feed/tag/DotClear/rss2/comments

Celle-ci, en revanche, le sera :

http://david.latapie.name/blog/Une_traduction_adéquate_pour_«_feed_»

Cepen­dant, je vois une manière d’améliorer les choses : plu­tôt que de sim­ple­ment igno­rer le fil, redi­ri­ger le robot vers la page HTML cor­res­pon­dante. En revanche, robots.txt ne suf­fit plus, il faut pas­ser pas .htac­cess, PHP…

  • Pour /feed/atom, il s’agit de / : soit la page d’accueil.
  • Pour /feed/tag/DotClear/rss2/comments, il s’agit de /tag/DotClear/ : pas de page HTML pour les com­men­taires spé­ci­fiques à un mot-clé.
  • Pour /feed/rss2/comments/2854, il s’agit de /post/Télé_poubelle : il faut effec­tuer une redi­rec­tion iden­ti­fiant vers titre. Beau­coup plus simple si on décide de jeter à la pou­belle les IRI signi­fiantes (ça peut se faire par about:config, dans l’interface d’administration) ; dans ce cas, l’adresse de redi­rec­tion devient /post/2854.

J’y pense assez sérieu­se­ment : le W3C répète à l’envie que les adresses n’ont pas à être visibles et que la signi­fiance, c’est assez rela­tif. Enfin, les adresses avec un iden­ti­fiant sont plus faciles à noter sur un papier (/post/1234, c’est plus facile à noter que /Bloc-note_de_code : bloc_note, blocnote, bloc-notes, bloc-note_de,…. D’un autre côté, lors du flat_export pour pas­ser de DC1 à DC2, tous les iden­ti­fiants se sont mélan­gés, ce qui casse tout…

Côté réfé­ren­ce­ment, je ne suis pas même sûr que j’y perde beau­coup. Bon, il faut encore que je trouve com­ment redi­ri­ger un robot de cette manière. Une idée ? C’est vrai que ça fait beau­coup pour pas grand-chose.

Pour ce que j’en vois, il faut rem­pla­cer /feed/ par /post/ et sup­pri­mer rss2|atom(/comments). En code, ça donne quoi ?

Que pensez-vous de tout ceci ?

Le blocage par IP est-il efficace ?

Laisser une réponse

Ques­tion

Le blo­cage par IP est-il efficace ?

Trai­te­ment

Lan­gage humain

Fais la liste des ordi­na­teurs refu­sés et de ce qu’ils fai­saient à ce moment-là. Notes-moi tout ça dans un fichier bien rangé et tenu à jour.

Pro­cé­dure

Le fichier de log obtenu sur le ser­veur (je n’explique pas ici com­ment obte­nir un tel fichier) doit se trou­ver dans votre réper­toire uti­li­sa­teur (~) et s’appeller main.log.

Iso­ler toutes les adresses qui se sont prises un deny from IP (erreur 403) (grep '" 403 ') depuis le fichier de log (le jour­nal de bord) (~/main.log). Conser­ver éga­le­ment ce qu’ils étaient en train de faire sur cette machine (du GET ou du POST) (sed 's/- blog.empyree.org \[.*\] "//' | sed 's/ [^-A-Z].*//). Écrire le tout sur un pre­mier fichier tem­po­raire (> ~/main-onlyrejected.log)

Ce fichier ne contient que la der­nière mois­son. Nous vou­lons l’ajouter aux mois­sons pré­cé­dentes. S’il n’existe pas, nous créons (touch) le fichier liste_refus.log (~/liste_refus.log), qui sera notre fichier final. Nous allons ensuite (;) com­bi­ner (cat) le contenu du nou­veau fichiers ( ~/main-onlyrejected) et du fichier exis­tant, liste_refus.log (~/liste_refus.log) (s’il y en a un). Une fois les fichiers com­bi­nés (;), nous allons faire un peu de ménage : tri par ordre numé­rique (12 avant 109, alors qu’en alpha­bé­tique ce serait le contraire) (| sort -n) et sup­pres­sion des dou­blons (| uniq) et tout cela, nous allons l’écrire (>) dans un second dos­sier tem­po­raire, liste_refus-new.log (~/liste_refus-new.log)

Main­te­nant, fai­sons un peu de ménage : nous n’avons plus besoin du fichier de nou­velles IP inter­dites, nous le sup­pri­mons donc (rm ~/main-onlyrejected). Quant au fichier liste_refus-new.log, il peut désor­mais rem­pla­cer l’ancienne ver­sion (mv ~/liste_refus-new.log ~/liste_refus.log).

Code

  1. Fil­trer les reje­tés (atten­tion, il y a des reje­tés pas par moi) : 
    grep '" 403 ' ~/main.log | sed 's/- blog.empyree.org \[.*\] "//' | sed 's/ [^-A-Z].*//' > ~/main-onlyrejected.log
  2. Conca­té­ner les fichiers journaliers : 
    touch ~/liste_refus.log; cat ~/main-onlyrejected ~/liste_refus.log | sort -n | uniq > ~/liste_refus-new.log
  3. Net­toyer les tris concaténés : 
    rm ~/main-onlyrejected
  4. Ne gar­der que le nouveau : 
    mv ~/liste_refus-new.log ~/liste_refus.log
Code conca­téné

Tout ceci d’un coup d’un seul grâce à la com­mande de sépa­ra­tion de com­mandes, ; :

grep '" 403 ' ~/main.log | sed 's/- blog.empyree.org \[.*\] "//' | sed 's/ [^-A-Z].*//' > ~/main-onlyrejected.log;touch ~/liste_refus.log; cat ~/main-onlyrejected.log ~/liste_refus.log | sort -n | uniq > ~/liste_refus-new.log;rm ~/main-onlyrejected.log;mv ~/liste_refus-new.log ~/liste_refus.log

Réponse

À peine une semaine après la créa­tion de ce suivi, ma liste de refus m’affiche 2251 machines refu­sées. C’est sur­pre­nant, car je n’ai pas 2251 adresses inter­dites dans mon .htac­cess, mais il est vrai que je par­tage l’ordinateur avec d’autres per­sonnes ; c’est peut-être la rai­son (mais ça ne devrait pas). De plus, cer­taines des per­sonnes qui sont inter­dits de séjour sur le ter­ri­toire empy­réen sont peut-être de par­faits innon­cents (les spam­meurs viennent pour pos­ter, ce qui est plu­tôt du POST, mais j’ai beau­coup de GET, qui ne devraient pas avoir été pié­gés par mon .htac­cess). La pré­sence du qu’est-ce que vous fai­siez quand on vous a arrêté ? et dont la réponse est soit GET ou POST, per­met­tra peut-être d’y voir plus clair.

Quoiqu’il en soit, 2308 adresses refu­sées, c’est beau­coup. À la réponse Le blo­cage par IP est-il effi­cace ?, ma réponse est oui.

Merci à Arnaud pour le log et à Laura pour le code. Fine équipe que nous trois (enfin, sur­tout eux deux, moi, mon rôle, c’est sur­tout de ron­chon­ner et de qué­man­der ;-) )