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. C'est un peu plus sévère que le scoping, qui consiste essentiellement à vérifier qu'un utilisateur a le droit de réaliser une action (typiquement une requête bdd). Par exemple, la version "scoped" de @parametres = User.find(params[:id]) serait @truc = @user.parametres.find(params[:id]) avec un contrôle sur @user (identifié ou non etc.) Dans mon cas, en effet, je voulais de façon plus générale contrôler l'accès via url directe, sans nécessairement considérer l'aspect authentification. Mais couplé à l'authentification et, par exemple, à un plugin d'autorisation (gestion de rôles), ça permet de contraindre assez finement les accès. Par exemple, vous pouvez avoir écrit une application dans laquelle un utilisateur donné possède un inventaire, mais ne doit pas pouvoir y ajouter n'importe quel objet en gruikant avec l'url (« tiens, si j'essayais inventory/add/123 » alors qu'il n'a pas le droit à l'objet d'id 123, que ce soit en général ou dans un contexte particulier lié à l'exécution courante du code). Le contrôleur d'inventaire se charge de savoir, via le model utilisateur par exemple, quels objets sont susceptibles d'être manipulés librement par cet utilisateur à cet instant t donné, et la view n'affiche les actions add que pour ces objets. Le reste devient inaccessible, en accès direct ou interne. Si une meilleure façon de faire existe sur ce genre de problème, je suis preneur :) Merci pour le coup de pouce en tout cas ! On 7 juil, 10:21, "ook? ook!" <[email protected]> wrote: > Before_filter est ton ami: tu définis dedans tes règles d'accès (ici ce sera > l'existante d'une referrer) puis tu renvoies true pour autorisé, false pour > recalé. > > 2009/7/7 jd <[email protected]> > > > > > Bonjour. > > > Je souhaiterais pouvoir empêcher l'accès direct à toutes ou partie des > > actions de mes contrôleurs. Par exemple, s'il existe un contrôleur > > Item, proposant une méthode/action publique add, je voudrais qu'il > > soit impossible pour un utilisateur de déclencher cette action en > > validant « à la main » une url du type ../item/add/1234 dans son > > navigateur. Seul l'accès interne serait autorisé (par déclenché en > > interne, je veux dire, que ce soit en réponse à un clic ou par une > > autre méthode, etc.) > > > L'idée brutale de passer de proche en proche une clé de vérification > > me semble assez mauvais, aussi je viens quémander des suggestions :) > > Peut-être existe t-il un plugin pour ce genre de chose ? > > > Merci bien. > > --~--~---------~--~----~------------~-------~--~----~ 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] -~----------~----~----~----~------~----~------~--~---
