2009/7/7 jd <[email protected]> > > 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 ? > > >
si tu veux être sur de bloquer ca, il te faut en effet vérifier si l'user a les bons droits tant pour afficher les liens d'ajout que pour leur réelle execution. Si tu tiens aussi a bloquer les accès 'brutaux' en rentrant l'url dans le navigateur, je te conseille d'aller plutot du côté du forgery protection avec toutes tes opérations effectuant une écriture (création, modification, effacement) passant obligatoirement en post/put/delete. Tu es sûr à ce moment là que la page vient bien légitimement de la page qui précède. -- http://fabien.jakimowicz.com --~--~---------~--~----~------------~-------~--~----~ 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] -~----------~----~----~----~------~----~------~--~---
