Refuser à un utilisateur l'autorisation de cliquer sur une URL
On m'a demandé de travailler sur un message système sur un intranet où se trouvent diverses URL (liens vers des listes de contenu) auxquelles des droits d'autorisation sont attachés, de sorte que seuls certains utilisateurs ont accès au contenu.
Actuellement, il est spécifié de sorte que si un utilisateur sans autorisation clique sur l'une de ces URL, un message s'affiche indiquant "Vous n'êtes pas autorisé à afficher ce contenu".
Je me demande s'il y a une meilleure façon de gérer cela?
Je pensais peut-être désactiver complètement les liens (l'utilisateur n'a aucune autorisation).
Il y a des avantages/inconvénients ici.
Pro:
Cela empêchera les utilisateurs de cliquer sur ledit lien et de recevoir un message qui peut les laisser se sentir stupides et peut-être ennuyés de ne pas avoir l'autorisation.
Con:
Peut-être que l'utilisateur doit/aimerait savoir que ce contenu existe (doit donc être reconnaissable en tant qu'URL) même s'il ne peut pas le voir.
Quelqu'un a-t-il des idées à ce sujet/vu des modèles similaires en cours d'utilisation?
- Si un utilisateur n'a pas la permission d'accéder à un élément de contenu particulier, je suggère ne pas l'afficher du tout.
Si l'utilisateur a besoin de savoir que le contenu auquel il n'a pas accès existe - montrez-lui le contenu sous une forme différente et fournissez-lui un moyen de se renseigner sur la façon d'y accéder si nécessaire.
- Par exemple. sous forme de liste de contenu (plutôt que de liens semi-fonctionnels), avec une suggestion sur la personne à contacter en cas de besoin d'accès.
Je voudrais prendre suggestion de @ lazer un peu plus loin.
Pourquoi ne pas ajouter une petite icône de cadenas après chacun des liens auxquels l'utilisateur n'a pas l'autorisation?
![3 links, followed by an inactive 4th which has a padlock icon]()
- Ensuite, si l'utilisateur survolait le lien, je lui montrerais une info-bulle expliquant qu'il n'a pas l'autorisation d'afficher le contenu de la page.
J'ai travaillé sur un projet très similaire au vôtre où les utilisateurs ne pouvaient voir le contenu qu'en fonction de leurs autorisations d'accès. Bien que la réaction initiale des parties prenantes ait été de simplement montrer le contenu auquel les utilisateurs avaient accès, il y a également eu des commentaires selon lesquels les utilisateurs auraient pu vouloir accéder à un contenu spécifique. Ainsi, masquer du contenu non autorisé aurait donné l'impression qu'il n'existait pas. Dans notre projet, le contenu était censé faire surface sous forme de liens de résultats de recherche, comme indiqué ci-dessous:
Cependant, pour mettre en évidence le contenu, qui était là mais auquel les utilisateurs n'avaient pas accès, nous avons simplement remplacé le lien Aperçu | Afficher dans le navigateur par un lien demande d'accès, qui lancerait un formulaire de demande. Ensuite, l'utilisateur devrait spécifier son besoin professionnel et des informations seraient envoyées au propriétaire du contenu par e-mail.
L'avantage de ce processus est que vous autorisez l'accès aux parties prenantes potentielles tant qu'elles peuvent fournir une justification. Cependant, l'inconvénient apparent est que le propriétaire du contenu peut se retrouver avec beaucoup de demandes si le contenu est très souhaitable.
En général, je voudrais:
- afficher/masquer le contenu en fonction des droits des utilisateurs
- activer/désactiver le contenu en fonction de la disponibilité dépend de tout le reste.
Si un utilisateur n'a pas le droit de voir quelque chose, la sécurité exige qu'il ne soit même pas informé de son existence.
Si un utilisateur a le droit de voir quelque chose, il doit toujours le voir, mais il peut être désactivé si les circonstances l'exigent. Par exemple, un service/imprimante/tout ce qui n'est pas disponible; ou un formulaire qui n'est toujours pas valide pour l'envoi.
Mise à jour
J'ai mis à jour ma réponse (a) parce que je me suis rendu compte que la suggestion du PO ("désactiver" plutôt que "masquer" les liens) était très différente de la règle à laquelle nous étions confrontés; et (b) dire que le gros problème auquel nous avons été confrontés n'était pas parce qu'on nous avait dit que les liens devaient être cachés dans certaines situations, mais à cause d'une règle générale aveugle.
Nous avons rencontré un problème connexe avec notre intranet il y a plusieurs années. Nous avions un leader qui était vendu sur le concept "pas d'accès, pas de lien", et il a été adopté (sans trop réfléchir aux implications) comme principe pour nos applications Web intranet. Cette variante incluait le cas où l'élément lié n'avait aucune donnée (par exemple un lien vers un utilisateur par ID qui n'est plus dans le système), ainsi que les cas où l'utilisateur connecté ne devrait pas avoir accès aux données. En d'autres termes, dans la conception de ce leader, le lien ne devrait jamais apparaître s'il ne conduit pas à des données existantes et accessibles.
Je peux voir à quel point cette pratique plairait à certaines personnes qui n'aiment tout simplement pas qu'on leur dise "non". Mais en règle générale, c'était une très mauvaise idée.
Le plus gros problème, dont d'autres ont déjà mentionné qu'il altère sérieusement le principe UX de découvrabilité .
Supposons qu'une page d'aide me dise de cliquer sur tel ou tel lien. Je vais sur la page mais je ne trouve pas le lien. Comment gérer cette situation?
- Ai-je mal compris l'aide et je suis sur la mauvaise page?
- N'ai-je pas la permission d'accéder au lien? (Connaître cette option nécessite que je sois déjà éduqué sur le principe "pas d'accès, pas de lien", qui impose une exigence de formation à la population d'utilisateurs.) Si oui, est-ce parce que je ne devrais vraiment pas avoir l'autorisation? ou parce que la base de données de certains rôles n'a pas encore été correctement mise à jour pour moi?
- Ce lien n'est-il pas applicable pour une raison qui n'apparaît pas clairement dans l'aide et a donc été "utilement" supprimée de la vue?
- La page d'aide fait-elle référence à une version plus ancienne (ou plus récente) de l'application et doit-elle être mise à jour?
- Suis-je confronté à une sorte de problème d'incompatibilité de navigateur?
Vous pouvez voir comment la confusion et l'incapacité à diagnostiquer le problème peuvent conduire à toutes sortes de frustrations. Et c'est juste du côté de l'utilisateur. (Sans parler du fardeau imposé aux responsables de la documentation pour essayer d'expliquer aux utilisateurs que chaque lien peut ne pas apparaître, et comment savoir pourquoi et quoi faire à ce sujet.)
Côté développeur, le respect de cette règle impose une nouvelle charge.
Pour chaque lien que j'émets, je dois considérer:
- Non seulement l'application cible, mais également l'application source, doivent comprendre le mappage de l'identité et des rôles des utilisateurs aux autorisations en fonction de la portée, de la sensibilité et d'autres critères.
- Cela rend les applications cible et source étroitement couplées, soit en partageant le code pour évaluer les critères d'accès, soit en ne partageant pas le code. Dans ce dernier cas, les applications peuvent se désynchroniser, auquel cas l'application source pourrait par inadvertance omettre des liens vers des informations qui devraient réellement être disponibles pour l'utilisateur!
- Cela rend beaucoup plus difficile la mise à niveau efficace et correcte des applications source et cible.
- Les performances sont affectées, car les bases de données doivent être interrogées lors de la génération des liens sur la page source, ainsi que lors de la vérification des privilèges d'accès sur la page cible. Si les applications source et cible sont hébergées dans des emplacements différents, l'impact sur les performances peut être substantiel.
- Lorsque les pages source et cible se trouvent dans des systèmes différents, cela signifie que les informations d'identification pour accéder à la base de données de rôles de l'application cible doivent être partagées entre plusieurs applications source différentes, ce qui rend plus difficile la conservation et la sécurité de ces informations d'identification.
Lorsque ce principe est important, il peut être mis en œuvre, à un coût important. Mais il ne devrait jamais être appliqué en tant que règle générale.
Le principe n'a jamais été pleinement mis en œuvre dans nos sites Web intranet, car il n'était pas pratique. Finalement, il a été abandonné. (Et il y avait une grande joie.)
Je soutiens les compromis suggérés, tels que ne pas fournir de lien mais fournir une indication qu'il y aurait un lien si l'utilisateur avait accès (c'est-à-dire "désactiver"). Cependant, les coûts de développement de cette fonctionnalité peuvent être substantiels et doivent être mis en balance avec les avantages (vs cliquer sur le lien et obtenir un message d'erreur informatif sur la page cible). Je pense que les avantages sont faibles, mais je peux voir des cas où cela pourrait être important (par exemple, lors de la présentation d'une longue liste de liens, dont beaucoup entraîneront des erreurs "pas d'accès" ou "non trouvées"). Cela dépend de la tâche de l'utilisateur et de son besoin de tenir la main.
Une situation où je pourrais voir un cas pour cacher complètement les informations de l'utilisateur serait si l'existence même d'une ressource est une information sensible. Dans ce cas, vous ne cachez pas un lien car l'utilisateur n'a pas l'autorisation d'accéder aux données cibles; vous masquez les métadonnées (l'existence de la ressource) car l'utilisateur n'a pas l'autorisation d'accéder à ces métadonnées.
Certes, il y a lieu de réduire l'encombrement inutile ou moins utile à l'écran afin que les éléments utiles soient plus faciles à trouver. Surtout si les liens qui ne mènent à rien d'utile sont susceptibles d'être nombreux et fréquents. Mais le masquage n'est pas le seul moyen d'atténuer l'encombrement ... qui peut être accompli en rendant les liens "condamnés" plus petits, grisés, désactivés ou en les déplaçant vers le bas d'une page. L'omission de l'un des deux liens sur une page peu fréquentée ne réduit pas l'encombrement, mais les yeux bandés sur l'utilisateur.
Je pense que je suggérerais de ne pas leur donner de lien du tout, mais plutôt de donner au texte un style similaire au lien, tout en le rendant facile à discerner comme étant inaccessible. Ensuite, j'aurais une sorte de lien à côté de chaque non-lien avec quelque chose comme "dites-moi pourquoi je ne peux pas accéder à ce contenu, et ce que je peux faire à ce sujet". Si je voulais être vraiment proactif à ce sujet, je pourrais faire une petite icône facilement reconnaissable à côté des non-liens où, lorsque le non-lien est survolé, une petite infobulle apparaît sur l'icône pour indiquer qu'ils peuvent en savoir plus sur les non-liens en cliquant sur l'icône.
Comme d'autres l'ont noté, les pages non accessibles ne doivent pas être liées à la fois et doivent également être protégées par une validation côté serveur sur la page elle-même pour se protéger contre les utilisateurs intelligents.
Si la situation le permet, je pourrais avoir la page "ce qui ne sont pas des liens"/modale inclure un formulaire dans lequel l'utilisateur peut sélectionner dans une liste de services et soumettre une demande d'autorisations dans certaines circonstances (ex: l'utilisateur dispose d'autorisations suffisamment élevées pour qu'il peut être en mesure d'accéder à plus de contenu en contactant Joe Somebody, donc la page leur permet de le faire immédiatement et facilement).
Pour les info-bulles, j'aime Plugin TipTip jQuery .
Si j'étais dans une situation où certains contenus doivent être interdits, mais ce n'est pas dangereux d'informer tout le monde qu'un tel contenu existe, alors je:
- Changez la couleur de l'hyperlien non autorisé en gris.
- Vous pouvez soit conserver la fenêtre contextuelle, soit la transmettre à une page plus explicite sur le contenu non autorisé, et à qui s'adresser si elle pense en avoir besoin.
Si vous utilisez des URL RESTful facilement devinables (par exemple, http://example.com/page/1/) et un utilisateur est autorisé à voir les pages 1 à 3, mais pas 4, simplement ne pas donner à l'utilisateur la possibilité de cliquer sur un lien pour accéder à la page 4 n'est pas sécurisé (ou changer le lien en une fenêtre contextuelle JavaScript) .
Un attaquant qualifié peut facilement saisir lui-même le nom de l'URL manquante. Vous devez vous assurer que votre serveur Web ne servira pas les pages interdites à l'utilisateur sans privilèges. (Et vous devez vérifier les autorisations de manière saine, c'est-à-dire qu'ils se sont connectés au système et ont un jeton de session impossible à deviner.) Vous ne devez pas vérifier en fonction de la dernière page qu'ils ont consultée ou de leur adresse IP (surtout si vous accédez à un section interdite peut faire une sorte d'action, comme créer un utilisateur).
Même si votre URL n'est pas facilement devinable, un attaquant peut être en mesure de parcourir l'historique des utilisateurs, de trouver les journaux du serveur, d'écouter les connexions http non chiffrées, pour trouver les URL.
if (is_loggedin())
echo "<a href=\"destination\"">Click</a>";
else
echo "Log in to access this link."
Cela devrait fonctionner.
Si l'utilisateur est connecté, il suffit de faire écho au lien, sinon de faire écho au texte ... aussi simple que cela.