Archives du mot-clé htaccess

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

Il y a peu, latapie.name (naked domain) était listable, avec notamment l’accès direct aux logs. Merci à Thomas pour me l’avoir signalé !

Très facile à régler avec une ligne dans le .htacess à la racine :

[[code]]czoyMDpcIk9wdGlvbnMgQWxsIC1JbmRleGVzXCI7e1smKiZdfQ==[[/code]]

(source : http://www.htaccessredirect.net/)

flattr this!

Differences between Redirect and Rewrite

  • Because I am craving for this for months;
  • Because I only found kilometres-long texts about use, performance, advanced manipulation… but no simple thing at all;
  • Because I like (useful) lists.

Here is a short summary of various redirect rules and their uses.

Redirect

(1) Redirect, RedirectTemp, Redirect temporary or Redirect 302
URL 1 is redirected to URL 2; it is visible in the address bar[1].
(2) RedirectPermanent or RedirectPermanent or Redirect 301
Same as (1), but permanent[2].
(3) Redirect Seeother or Redirect 303
Temporary change, do not change the index. Seldom used.
(4) Redirect Gone or Redirect 410
The page has disappeared and nothing will replace it. Think of it as a “voluntary 404″.
(5) Redirect xxx
Redirect with the corresponding code.
(6) RedirectMatch
Same as (1), but with regular expressions[3].
(7) RedirectMatch Permanent
Same as both (2) and (6)[4].

Notice how (6) and (7) differ from the other: they do not just send a code, they change the behaviour of the syntax. Consequenty, it is not possible (AFAIK) to use regexps with other than 301.

Rewrite

Rewrite is different and not necessarily better. But in any case, it is more complex (and I won’t delve into it for now). The main differences between Redirect and Rewrite are:

  • Redirect uses mod_alias; Rewrite uses mod_rewrite — except for old Apache version, where both rules use mod_rewrite. Big deal.
  • Rewrite hides the redirection to the user – this means the address stays the same in the address bar. That is the main difference between Redirect and Rewrite.
  • Rewrite is the only one able to cope with dynamic URL (you know, those damn question marks in QUERY STRING). Not even RedirectMatch can do it (AFAIK).

Redirect is appropriate when you want people to remember the new address; You may be sure they will copy the good address and that will save you some CPU cycles in non redirecting anymore. On the contrary, Rewrite is appropriate when you want the address to stay the same/not to be visible; A good example is hiding the architecture (/wordpress/, /wiki/…). Ultimately, using one or the other is not a technical consideration but more of a human and strategic 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 leading circumflex (^) is for forcing the matching string to be at the begining 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 completely accurate, I must say that Rewrite is able to do most, if not all, of what Redirect may do, thank to the flags. But that would be another topic I prefer 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 parsing requires CPU cycles, even when there is no actual regexp to parse.
  4. That is, the resulting regexp-powered redirections are permanent (error code 301).

Ils en parlent mais ne me le disent pas, les petits cachottiers :

flattr this!

Améliorer son référencement organique

J’en ai assez que mes RSS arrivent en premier dans les résultats de recherche Google.

Google spammé par mes RSS

Une solution simple : robots.txt.

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

Ainsi, cette adresse ne sera plus récupérée par les robots (du moment qu’ils obéissent à la convention 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_»

Cependant, je vois une manière d’améliorer les choses : plutôt que de simplement ignorer le fil, rediriger le robot vers la page HTML correspondante. En revanche, robots.txt ne suffit plus, il faut passer pas .htaccess, 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 commentaires spécifiques à un mot-clé.
  • Pour /feed/rss2/comments/2854, il s’agit de /post/Télé_poubelle : il faut effectuer une redirection identifiant vers titre. Beaucoup plus simple si on décide de jeter à la poubelle les IRI signifiantes (ça peut se faire par about:config, dans l’interface d’administration) ; dans ce cas, l’adresse de redirection devient /post/2854.

J’y pense assez sérieusement : le W3C répète à l’envie que les adresses n’ont pas à être visibles et que la signifiance, c’est assez relatif. Enfin, les adresses avec un identifiant 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 passer de DC1 à DC2, tous les identifiants se sont mélangés, ce qui casse tout…

Côté référencement, je ne suis pas même sûr que j’y perde beaucoup. Bon, il faut encore que je trouve comment rediriger un robot de cette manière. Une idée ? C’est vrai que ça fait beaucoup pour pas grand-chose.

Pour ce que j’en vois, il faut remplacer /feed/ par /post/ et supprimer rss2|atom(/comments). En code, ça donne quoi ?

Que pensez-vous de tout ceci ?

flattr this!

Le blocage par IP est-il efficace ?

Question

Le blocage par IP est-il efficace ?

Traitement

Langage humain

Fais la liste des ordinateurs refusés et de ce qu’ils faisaient à ce moment-là. Notes-moi tout ça dans un fichier bien rangé et tenu à jour.

Procédure

Le fichier de log obtenu sur le serveur (je n’explique pas ici comment obtenir un tel fichier) doit se trouver dans votre répertoire utilisateur (~) et s’appeller main.log.

Isoler toutes les adresses qui se sont prises un deny from IP (erreur 403) (grep '" 403 ') depuis le fichier de log (le journal de bord) (~/main.log). Conserver également 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 premier fichier temporaire (> ~/main-onlyrejected.log)

Ce fichier ne contient que la dernière moisson. Nous voulons l’ajouter aux moissons 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 (;) combiner (cat) le contenu du nouveau fichiers ( ~/main-onlyrejected) et du fichier existant, liste_refus.log (~/liste_refus.log) (s’il y en a un). Une fois les fichiers combinés (;), nous allons faire un peu de ménage : tri par ordre numérique (12 avant 109, alors qu’en alphabétique ce serait le contraire) (| sort -n) et suppression des doublons (| uniq) et tout cela, nous allons l’écrire (>) dans un second dossier temporaire, liste_refus-new.log (~/liste_refus-new.log)

Maintenant, faisons un peu de ménage : nous n’avons plus besoin du fichier de nouvelles IP interdites, nous le supprimons donc (rm ~/main-onlyrejected). Quant au fichier liste_refus-new.log, il peut désormais remplacer l’ancienne version (mv ~/liste_refus-new.log ~/liste_refus.log).

Code

  1. Filtrer les rejetés (attention, il y a des rejetés pas par moi) :
    grep '" 403 ' ~/main.log | sed 's/- blog.empyree.org \[.*\] "//' | sed 's/ [^-A-Z].*//' > ~/main-onlyrejected.log
  2. Concaténer les fichiers journaliers :
    touch ~/liste_refus.log; cat ~/main-onlyrejected ~/liste_refus.log | sort -n | uniq > ~/liste_refus-new.log
  3. Nettoyer les tris concaténés :
    rm ~/main-onlyrejected
  4. Ne garder que le nouveau :
    mv ~/liste_refus-new.log ~/liste_refus.log
Code concaténé

Tout ceci d’un coup d’un seul grâce à la commande de séparation de commandes, ; :

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éation de ce suivi, ma liste de refus m’affiche 2251 machines refusées. C’est surprenant, car je n’ai pas 2251 adresses interdites dans mon .htaccess, mais il est vrai que je partage l’ordinateur avec d’autres personnes ; c’est peut-être la raison (mais ça ne devrait pas). De plus, certaines des personnes qui sont interdits de séjour sur le territoire empyréen sont peut-être de parfaits innoncents (les spammeurs viennent pour poster, ce qui est plutôt du POST, mais j’ai beaucoup de GET, qui ne devraient pas avoir été piégés par mon .htaccess). La présence du qu’est-ce que vous faisiez quand on vous a arrêté ? et dont la réponse est soit GET ou POST, permettra peut-être d’y voir plus clair.

Quoiqu’il en soit, 2308 adresses refusées, c’est beaucoup. À la réponse Le blocage par IP est-il efficace ?, ma réponse est oui.

Merci à Arnaud pour le log et à Laura pour le code. Fine équipe que nous trois (enfin, surtout eux deux, moi, mon rôle, c’est surtout de ronchonner et de quémander ;-) )

flattr this!