Je pense effectivement que ce sont les filtres qui sont l'outil dans symfony qui répondrait le mieux à ta problématique. Le filtre pourrait accorder (ou retirer) à l'utilisateur un "credential" qui correspondrait à l'accès à ton intranet ou aux informations qui s'y rapportent. Ainsi, tu pourrais même mettre dans une même page des informations publiques et intranet (ces dernières uniquement accessibles si le filtre a donné le bon droit)...
-----Message d'origine----- De : symfony-fr@googlegroups.com [mailto:symfony...@googlegroups.com] De la part de Stéphane Envoyé : jeudi 25 novembre 2010 11:40 À : symfony-fr@googlegroups.com Objet : Re: [symfony-fr] Symfony 1.4 - Étanchéité de module en fonction de l'adresse IP de l'utilisateur Salut, Je ne sais pas si j'ai tout saisie, m'enfin, j'me lance : Concernant la vérification d'accès par IP, je pense que tu peux le faire dans un preExecute sur les modules en question non ? Voire même étendre sfActions puis utiliser cette classe dans les modules concernés ? Sinon y a peut être les filtres aussi (filters.yml, voir doc sf). Si tu utilises les filtres (si ça convient), peut-être que tu peux adopter une approche "déclarative", par configuration dans un fichier yaml, pour décrire les modules et les accès (via IP, etc) Du genre: //settings.yml dans project/config -si c'est project-wide sinon dans l'app/config) ips: __presta: XXX.XXX.XXX.XXX __client: XXX.XXX.XXX.XXX modules: __news: ____for: ______presta: {connected: false} __fiche: ____for: ______presta: {connected: true} ______client: {connected: true} (Bon je viens de voir que le "connected" ne dépend pas du client, donc modifies si tu veux, genre __fiche: ____for: [presta, client] ____connected: false/true ) Before Printing, Think about Your Environmental Responsibility! Avant d'Imprimer, Pensez à Votre Responsabilitée Environnementale! 2010/11/25 ch4rlyp <dev.cha...@gmail.com> Bonjour, Je travaille actuellement sur un Intranet composé de différents outils utilisés par des prestataires et leur client. Je me heurte à un problème, je souhaite rendre inaccessible des modules en fonction de l'adresse IP de l'utilisateur (client/presta). La solution envisagée était de sécuriser les modules via les crendentials, ce qui est fait, mais l'application présentant des fonctions qui ne doivent pas nécessiter de connexion (contrainte fonctionnelle) on se retrouve avec des modules toujours accessibles. Je vous fait un récapitulatif : Module (Qui doit avoir accès)(Connecté/Non Connecté): - news -> (Presta)(Non Connecté) - fiche -> (Presta/Client)(Connecté) - projets -> (Presta)(Connecté) - composants -> (Presta)(Connecté) Bien entendu, je souhaiterais éviter la duplication de module. (exigeant le gars :D) Je suis ouvert à toutes solutions et j'espère avoir été le plus clair possible. Merci d'avance -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Symfony-fr. Pour envoyer un message à ce groupe, adressez un e-mail à symfony...@googlegroups.com. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse symfony-fr+unsubscr...@googlegroups.com <mailto:symfony-fr%2bunsubscr...@googlegroups.com> . Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/symfony-fr?hl=fr -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Symfony-fr. Pour envoyer un message à ce groupe, adressez un e-mail à symfony...@googlegroups.com. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse symfony-fr+unsubscr...@googlegroups.com. Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/symfony-fr?hl=fr -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Symfony-fr. Pour envoyer un message à ce groupe, adressez un e-mail à symfony...@googlegroups.com. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse symfony-fr+unsubscr...@googlegroups.com. Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/symfony-fr?hl=fr
