jd a écrit : > Merci. J'avais dans l'idée d'utiliser un before_filter mais je ne > connaissais pas (!) l'existence du HTTP_REFERER. La base… > > Quelques détails, ça pourra peut-être servir à quelqu'un : je me suis > créé un before_filter :access_control dans l'ApplicationControler > (dont dérivent tous les autres contrôleurs). Exécuté avant toute > action, il vérifie entre autre chose qu'un referer = request.referer > existe. Si oui, c'est que l'action courante a été déclenchée « en > interne » et on ne bloque rien. Si non, c'est qu'on a affaire à une > tentative d'accès direct par l'url. À noter qu'ajouter un ? > referer=quelquechose dans l'url ne trompe pas Rails. > > Dans un contrôleur en particulier, > skip_before_filter :access_control, :only => :index permet par exemple > de ne pas appliquer ce filtre pour l'action index. Ainsi, un > utilisateur pourra accéder à l'index en tapant l'url directe, mais ne > pourra pas déclencher directement une action comme add ou remove, par > exemple. Au programme de donner ou refuser l'accès interne vers tel ou > tel action. >
L'ennui, c'est qu'on ne peut que très peu se fier au http_referer Quand tu testes si un referer existe, il me suffit de créer une page avec le lien vers ton site inventory/add/123, tu auras une valeur dans ta variable referer, et ça passera. Même si tu testes le contenu de ce referer, vu que l'information est envoyée par le navigateur, l'utilisateur peut te faire croire que l'action vient bien de ton site en manipulant son navigateur. -- Julien. --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] -~----------~----~----~----~------~----~------~--~---
