Les vues respectent hook_node_access

J'utilise hook_node_access()pour refuser aux utilisateurs l'accès à certains nœuds en fonction de critères personnalisés. Cependant, je ne veux pas que ce contenu s'affiche dans une vue qui le répertorie si l'utilisateur ne satisfait pas aux critères. Existe-t-il un moyen d'avoir des vues respectant les hook_node_access()implémentations?

views hooks users

— nenne
source

Si le module Views ne respecte pas vraiment les autorisations d'accès définies avec hook_node_access(), il y a juste une chose à faire: modifier le code du module Views.

— kiamlaluno

Je ne pense pas que le crochet soit déclenché jusqu'à ce que le nœud soit réellement chargé dans son intégralité avec node_load, c'est probablement pourquoi il apparaît toujours. J'ai cependant commencé à travailler sur un plugin de filtrage qui utilisera la même méthode de filtrage que l'implémentation de hook_node_access () utilise pour verrouiller les gens. Je vais juste devoir me rappeler d'ajouter ce filtre dans toutes mes vues et cela devrait fonctionner. Je reviendrai ici avec des informations à ce sujet une fois que j'aurai terminé afin que d'autres puissent en bénéficier.

— nenne

Ok, donc mon cas d'utilisation était le suivant: le client veut que 10 niveaux d'accès s'appliquent à n'importe quel nœud et les utilisateurs devraient pouvoir voir tous les nœuds sous leur niveau d'accès. Cela a été facilement résolu via hook_node_access pour la vue standard des nœuds. Cependant, comme les vues ne respectaient pas cela, j'ai créé un filtre contextuel avec du code php personnalisé pour l'argument. Le code php a fondamentalement renvoyé les valeurs inférieures ou égales pour le niveau d'accès des utilisateurs (dans la syntaxe appropriée séparée par,). L'inconvénient de cette solution est que chaque vue aura besoin de cette configuration.

— nenne

J'ai trouvé un problème pour les vues qui traitent de ce problème, il fait également référence à une bonne façon de résoudre le problème: drupal.org/node/1266388 .

— nenne

Si vous pouvez écrire une réponse sur la façon de résoudre le problème, c'est parfaitement acceptable; comme le dit merlinofchaos, le module Views charge les nœuds à l'aide d'une requête de base de données, et c'est la raison pour laquelle les hook_node_access()implémentations ne sont pas respectées. Comme c'est "par conception", signaler une solution de contournement est très bien.

— kiamlaluno

Réponses:

J'ai eu la même question il y a quelque temps ici .

hook_node_accessn'est pas reconnu par viewsou menus. Il ne doit être utilisé que comme dernière ligne de défense.

Un meilleur moyen de contrôler l'accès aux nœuds est de passer par hook_node_access_recordset hook_node_grantscomme décrit ici et ici .

— Baba
source

hook_node_access () uniquement est invoqué lors de la tentative d'affichage du nœud complet. Ce que vous devez faire est d'implémenter hook_node_access_records () et hook_node_grants () .

— rik
source

Peux-tu élaborer?

Les vues utilisent SQL pour déterminer les nœuds à afficher. Malheureusement, pour des raisons de performances, il ne serait tout simplement pas possible pour Drupal d'effectuer un node_load sur tous les candidats potentiels, puis d'appeler hook_node_access sur chacun de ceux-ci. Imaginez une vue qui montre des milliers de nœuds (surtout lorsque vous utilisez un pager). Si la logique n'est pas effectuée en SQL, les pageurs auraient des fonctionnalités très inhabituelles, donc Drupal vous oblige à le faire comme indiqué précédemment en utilisant les enregistrements d'accès dans votre base de données.

Faire access_records est beaucoup plus de travail mais le fera fonctionner avec SQL. Je recommande donc d'utiliser un module node_access existant pour résoudre vos fonctionnalités autant que possible, car il sera probablement implémenté à l'aide des enregistrements d'accès et fonctionnera donc avec les vues.

Par la façon dont les enregistrements d'accès sont stockés dans la table node_access , comme indiqué ci-dessous: entrez la description de l'image ici Grâce aux commentaires pour chaque colonne, vous pouvez comprendre leur objectif. Considérez le domaine comme le système utilisé pour l'accès aux nœuds et le gid comme le groupe au sein d'un domaine. Ce groupe peut avoir des autorisations d'affichage, de mise à jour et de suppression. En général, chaque module node_access définit un ou plusieurs domaines (parfois plusieurs modules node_access peuvent également fonctionner en parallèle). Un utilisateur a un ou plusieurs gids dans chacun des domaines.

Dans Drupal, toutes les requêtes qui ont la balise "node_access" auront automatiquement une logique spéciale ajoutée. Consultez la documentation pour en savoir plus sur le balisage. Cette logique spéciale rejoint la table "node_access" pour chaque domaine et ajoute la condition que lorsque le "gid" est égal à l'un des gids appliqués à un utilisateur, l'utilisateur dispose de l'autorisation appropriée.

L'ensemble de ce système permet à toutes les requêtes de gérer correctement node_access, même de compter les requêtes, etc. Il est très puissant mais a une courbe d'apprentissage plus élevée que le simple hook_node_access. Dans la mesure du possible, l'utilisation d'un module node_access existant peut vous éviter tout ce mal de tête.

— Thomas4019
source