jusqu'à maintenant j'utilise une zone Ceci est devenu un problème car dans un projet récent, je souhaitais définir les cookies authentiques ne pas expirer pour les utilisateurs, mais je ne manque pas cela pour les utilisateurs d'administration. Je ne veux pas non plus que la page de connexion de l'utilisateur soit utilisée pour accéder aux outils d'administration.
merci.
4 Réponses :
J'utilise toujours un site Web séparé pour l'administration. Mais c'est principalement parce que l'administration de mes sites est totalement différente de l'utilisation et nécessite donc une mise en page différente.
Une autre chose positive est que vous n'avez pas à vous demander si les utilisateurs pourraient être en mesure de modifier des choses qu'ils ne devraient pas être en mesure de modifier car ces pièces ne sont pas intégrées au site Web de l'utilisateur.
Je veux dire la mise en page avec Razor ou Masterpage avec le moteur de vue WebForms.
Nous utilisons http://admin.domainname.com et http://www.domainname.com pour séparer les sites. Assez facile à configurer.
séparation des sites rend également les contrôleurs et les vues beaucoup plus propres car ils ne traitent que des tâches pour les administrateurs ou les utilisateurs. Pas besoin de beaucoup d'IFS (qui peut être très facile à ajouter si vous êtes comme moi = un codeur paresseux :)
Merci. quelle plateforme utilisez-vous? Par mise en page Vous voulez dire la page de la page / design?
Nous utilisons simplement différentes pages de maître pour la nôtre - une disposition complètement différente. De cette façon, l'utilisateur n'a pas à configurer deux sites et avoir deux ports (ou noms d'hôte) différents, etc.
J'utilise mvc3 avec moteur d'étincelle
D'accord avec @Michael Shimmins - Différente mise en page / contenu n'est pas une raison pour utiliser un site Web séparé. C'est ce que font les pages principales. Vous pouvez spécifier programmatimatiquement la page maître lors du retour de la vue: Vue de retour ("index", modèle, "adminmaster")
J'ai précisé plus de raisons que la mise en page / Masterpage.
Je préfère avoir des applications MVC distinctes plutôt que des zones. Ils peuvent toujours partager des ressources dont ils ont besoin en commun, mais aussi que chaque application représente une préoccupation très spécifique (plutôt qu'une application massive qui fait), il est en réalité plus facile à gérer dans l'environnement de construction que je travaille.
Le S'ils sont un administrateur, définissez ceci sur voir http://msdn.microsoft.com/en-us/library /twk5762b.aspx pour plus d'informations (le deuxième paramètre En termes d'une page de connexion différente pour différentes classes d'utilisateur, vous pouvez renvoyer FALSE de la méthode d'authentification s'il s'agit de la mauvaise classe d'utilisateur et d'accéder à la mauvaise page de connexion.
Toutes cette logique devraient se produire avant de définir le jeton d'authentification. formesAuthentication.settauthcookie vous permet de contrôler s'il persiste sur des sessions ou non.
false , sinon sur vrai .
CreateEppersistentCookie contrôle ceci).
Mais lorsqu'un utilisateur tente d'accéder aux pages d'administration, je les souhaiterais redirigé vers une zone de connexion différente de la page de connexion principale de l'utilisateur. Autant que je sache, il n'y a aucun moyen de le faire avec une authentification des formulaires.
Nous faisons la même chose. Nous vérifions la présnce d'une variable de session. Si ce n'est pas là, nous redirigeons à la page d'administration (ce qui les oblige à entrer dans leur mot de passe). Une fois qu'ils ont authentifié avec succès, nous définissons la variable de session pour dire «Yep, ils ont des droits d'administration». Les droits de l'administrateur sont perdus lorsque le navigateur est fermé ou si l'utilisateur choisit, en cliquant sur un lien pour déposer les droits de l'administrateur.
Je préfère garder le site d'administration séparément pour un certain nombre de raisons:
Séparation des préoccupations entre les couches (Service / Data, etc.) signifie qu'il devrait être relativement simple de filer votre site d'administration pour accéder aux fonctionnalités disponibles sur votre site principal.
Autorizeattribute , ce qui signifie que toutes les actions (sauf Connexion !) ne sont pas accessibles par des utilisateurs externes sans les informations d'identification appropriées. Les actions individuelles sont ensuite remplacées avec les informations d'identification pertinentes, mais en général, c'est une approche «définie et oublie». Bien que vous puissiez avoir deux contrôleurs de base dans une approche à un site unique, je pense qu'il serait légèrement moins gérable.
Le cookie des formulaires pourrait être un chemin restreint pour la zone d'administration, mais cela vous donnerait des maux de tête lorsque vous traitez avec l'authentification, mais pourrait être possible d'atteindre.
Une autre option au lieu d'utiliser admin.hostname.com ou quoi que ce soit comme celui-ci, est d'utiliser une subapplication sur / admin, cependant, cela ne résoudrait pas nécessairement votre problème.
Nous avons développé notre application Web comme deux sites différents, principalement parce que nous voulions que l'option ait la possibilité de scinder l'administration du site actuel, ainsi que des raisons d'évolutivité. Nous voulions pouvoir accabler le site Web actuel en question et non la partie administrative.
Nous avons rencontré les problèmes suivants:
Je pense que pour des raisons d'évolutivité, vous devriez envisager de séparer les préoccupations, mais tout cela réside dans la conception de votre application si cela est possible ou non. Nous construisons un cadre pour un certain type de sites Web, ce qui signifie que la mise en œuvre effective de la conception diffère de chaque client, mais nous voulions une manière standardisée d'administrer le site, de sorte que c'était le choix logique pour nous.