Je travaille sur un site Web (développé dans ASP.NET avec C #) qui m'a été transmis. Comme je travaille sur le site, j'empêche une grande partie du site contient ce type de code:
EmailLabel.Visible = false; WhateverButton.Visible = false; AnotherControl.Visible = false; ...
3 Réponses :
Il existe un composant loginView qui est un panneau qui possède une vue anonyme, une vue authentifiée et des vues pour des rôles spécifiques. Cela facilite la tâche.
http: //www.creativeii. COM / 2007/10/05 / NET-Membership-Part-II-LoginView /
En fait, j'ai appris à ce sujet dans une question ultérieure que j'ai posée. Merci d'avoir souligné cela!
Ce serait beaucoup, de nombreuses ordres de grandeur plus coûteux de délivrer une redirection que de définir les indicateurs visibles sur plusieurs contrôles.
Si votre page permet à la fois d'accéder anonyme et d'un accès connecté, la redirection nécessiterait également de vous permettre d'accéder anonyme d'une autre manière, probablement en construisant une deuxième version de la page.
La question des dépenses est vraiment juste à côté, cela n'a probablement pas d'importance du tout. Pour répondre à votre question principale, sans savoir plus sur l'architecture de votre application, je considérerais ces deux choses comme indésirables. Les avantages de simplement définir les commandes visibles = Faux sont que rien n'est rendu au flux de sortie pour les contrôles invisibles, mais ils peuvent toujours interagir avec les demandes de serveur.
Sans en savoir plus sur les exigences de votre page, il est difficile de suggérer des alternatives. Comme l'a mentionné quelqu'un d'autre, une vision login peut répondre à vos besoins si les contrôles invisibles ne participent pas du tout avec des utilisateurs anonymes.
Bonne réponse (+1), mais je suis curieux de savoir pourquoi une redirection est "de nombreuses ordres de grandeur plus chères". Particulièrement parce que, il y a peu de chance qu'un utilisateur non connecté soit en mesure de "sortir" de la page d'accueil de toute façon (sauf si elle mémorise l'adresse à une page aléatoire). Donc, cela ne devrait pas être quelque chose qui devrait arriver souvent.
Considérez que le réglage des drapeaux visibles prend quelques cycles de processeur, alors que la génération d'une redirection nécessite un aller-retour sur le navigateur, avec toutes les latences de réseau, les ressources du serveur pour gérer une nouvelle demande et compléter la vie à la page de vie.
Nous faisons beaucoup cela à mon travail.
La façon dont nous accomplissons cela consiste à créer une classe de base de base qui hérite de System.Web.UI.Page. Ensuite, vous remplacez Oninit, appelez la base.onInit et ajoutez du code pour rechercher un utilisateur connecté. Si l'utilisateur n'est pas connecté, redirectez-les sur une page de connexion (qui n'hériterait pas du basepage.)
Puis, sur chaque page qui doit être protégée, changez simplement la page pour hériter du basepage.
et contrairement à la WOMP dit ci-dessus, si vous écrivez une réponse.end (); Après la redirection, il est beaucoup plus rapide que même continuer à traiter le reste de la page!
espère que cela aide.
Bien que cette approche soit définitivement recommandée pour la plupart des situations, il est impossible d'être plus rapide. Comment définir des variables booléennes peut-elle être n'importe où près des frais généraux de l'émission de 301 rounds au navigateur? Vous parlez des nanosecondes de temps de processeur contre des centaines de millisecondes de latence de réseau et du serveur chargé de plusieurs demandes de navigateur. Et réponse.end () jette une exception threadabortex, qui génère ses propres frais généraux.
Juste pour clarifier cependant - protéger les pages qui nécessitent seulement l'accès authentifié doit certainement être fait de cette façon. Je ne suis pas clair comme si l'op exige cela ou non.
La raison pour laquelle cela est plus rapide est qu'aucune des méthodes de cycle de page après avoir été appelée de cette façon. Économiser beaucoup de temps de processeur. Et à toutes fins utiles, une étape supplémentaire et le temps associé à celui-ci sont attendus par l'utilisateur dans le cas où ils ne sont pas connectés.