Je lance le concept de créer une section administrative dans le projet CakePHP. (version 2.3.5)
J'ai décompressé la ligne dans config / core.php: p> J'ai ajouté la ligne dans config / routes.php: (juste Comme ils conseillent à faire dans CakePHP Cookbook.) P> public $components = array(
'Session',
'Auth' => array(
'loginRedirect'=>array('controller'=>'pages','action'=>'index', 'admin'=>true),
'logoutRedirect'=>array('controller'=>'pages','action'=>'display','home'),
'authError'=>'you have no access.',
'authorize'=>array('Controller')
)
);
4 Réponses :
Je suppose que vous pouvez définir une connexion dans AppController, puis à l'intérieur de cette action, vous pouvez faire:
$this->redirect(array('controller'=>'someController','action'=>'someAction','admin'=>true));
Essayez ceci pour la connexion utilisateur que vous feriez quelque chose comme ceci: Toutes les méthodes que vous souhaitez vous accéder «D faire la fonction publique admin_index, admin_view admin_settings, etc. de sorte que dans le contrôleur de widgets, la route serait / admin / widgets / index / admin / widgets / index et ainsi de suite. L'astuce pour permettre aux autres pages d'être rendue sans AUTH consiste simplement à mettre le $ ceci-> auth-> permettre à l'avantfilter.
J'ai une autre solution. Le panneau d'administration pour le site Web a un autre graphique, JavaScTPT, etc., donc je fais dans mes dossiers d'applications: Oui admin est dans un autre dossier, je peux donc définir un autre cookie pour vous connecter à la zone d'administration. Seuls les plugins et le modèle sont les mêmes. Cette structure de dossiers nécessite une certaine configuration dans bootstrap.php: peut-être est fou pour vous, mais je préfère cette solution qui utilise des itinéraires d'administration.
Essayez ceci
routeur :: connect ('/', tableau ("contrôleur '=>" Utilisateurs " , 'action' => 'tableau de bord'));
Utilisez-vous une ACL? Parce que dans ce cas, êtes-vous sûr de l'avoir ajouté à la liste de l'ACO? J'ai eu un même genre de problème où il ne serait pas redirigé parce que j'ai simplement oublié de mettre à jour mon facepalm de mon ACO . Si ce n'est pas le cas: êtes-vous redirigé du tout? Que se passe-t-il lorsque vous le faites rediriger vers une page non administrative?
Non, je n'utilise pas ACL .. trop déroutant pour moi.
Non, n'utilisez pas la liste de contrôle d'accès. J'ai réussi à le faire fonctionner en quelque sorte, mais je ne sais pas, c'est une bonne pratique ou tout simplement la chance. J'ai changé ceci: "logoutrederect '=> tableau (" contrôleur' => "pages", "action '=> 'Dis Play', 'Home', 'admin' => Faux) et isauthoriisé () Si ($ this-> Auth-> Utilisateur («Rôle») == 'admin') retourne vrai. Après la connexion, il redirige vers / admin mais dans admin_logout, il redirige vers / users / utilisateur, il serait plus simple si la déconnexion serait rediriger uniquement vers '/' Ceci est désordonné ..
Ah, c'est parce qu'il se souvient du préfixe probablement. J'ai ce problème tout le temps lors de la création d'étiquettes d'ancrage. Il semble que le préfixe soit true automatiquement une fois que vous êtes "sur ce préfixe". C'est pourquoi j'exprime mon HTMLhelper qui définit automatiquement tous les préfixes sur FALSE, à moins que je ne le dise de le définir à vrai. Cela pourrait causer vos problèmes. Cela ressemble-t-il à votre problème? Sinon, nous devons rechercher plus loin :)
J'ai essayé de définir des préfixes false sans chance. Mais je l'ai travaillé plus ou moins. Je reviens dessus plus tard. Merci pour ton aide! Une autre chose s'est produite. Après la déconnexion, il redirige à l'extérieur de ce panneau d'administration, mais lorsque j'appuie précédemment dans la barre d'outils du navigateur, il passe directement à l'intérieur de mon panneau d'administration. Ne devrait pas auth-> déconnecter () détruire les données de la session? J'ai avantfeilter dans AppController qui permet "index". Est-il possible qu'il utilise admin_-préfixe sur cette méthode? J'utilise une mise en page appelée admin_index.ctp sur ma page d'administration.
Il devrait détruire les données de la session, oui. Mais votre navigateur met en cache les vues lorsque vous appuyez sur "Retour" pour empêcher les charges de page inutiles. Vous pouvez simplement vérifier en imprimant simplement une date
('H: i: s'); à l'écran et vérifiez s'il est en même temps lorsque vous appuyez sur la case. Si tel est le cas, la page est mise en cache;) Il ne sera donc pas une violation de sécurité, car la page ne sera pas mise à jour. Puisque le contrôleur aura besoin d'un utilisateur autorisé pour cela. Essayez f5'ing. Vous remarquerez que cela ne fonctionnera pas.Mais, vous avez dit "je l'ai travaillé plus ou moins". N'hésitez pas à mettre à jour votre question (définissez clairement ce que les mises à jour sont et ne retirez pas l'ancien contenu afin que nous puissions y parcourir). Ping me quand vous avez mis à jour la question. Sinon je ne remarquerai pas;)
Tu avais raison. Il a détruit les données de session et l'Admin_index était juste en cache de navigateur. En d'autres termes, si j'essaie de pousser des liens sur Admin_index à d'autres actions liées à l'administration, il redirige pour vous connecter. Donc cela fonctionne parfaitement. Grand merci @jelmer!
Quelqu'un se soucie d'écrire une réponse acceptée à cela? N'oubliez pas le contrôleur :: désablecache (); méthode (avant de commencer à poursuivre les façons de le faire manuellement). Cela m'a été coincé assez à quelques reprises.