Restriction plus stricte sur l'accès aux documents #1

Manually merged
nicod_ merged 1 commits from :master into master 11 months ago
nicod_ commented 11 months ago

Un document ou un forum lié à un objet (article, rubrique) en accès restreint, et lié également à un autre objet (auteur, événement...) se retrouve en accès autorisé.
On ajoute un test sur une constante ACCES_RESTREINT_OBJET_LIEN_STRICT, qui permet de ne jamais autoriser l'accès à un document ou un forum lié à un objet en accès restreint.

Un document ou un forum lié à un objet (article, rubrique) en accès restreint, et lié également à un autre objet (auteur, événement...) se retrouve en accès autorisé. On ajoute un test sur une constante ACCES_RESTREINT_OBJET_LIEN_STRICT, qui permet de ne jamais autoriser l'accès à un document ou un forum lié à un objet en accès restreint.

testé OK sur une installation "de base" en 3.2.7

testé OK sur une installation "de base" en 3.2.7

Du coup cette modif me fait voir que j'ai un doute sur le code actuel car même si pas d'interface par défaut, tout objet peut être restreint (= être lié à la zone), or dans le test, quand c'est pas les tables mises en dur, ça appelle pas la fonction générique accesrestreint_objet_accessibles_where() qui existe bien, alors que ça devrait…

Sinon pour le nom du define, tous les autres du plugin sont préfixés par "AR_", sauf le tout dernier ajouté ACCES_RESTREINT_FORCE_AUTORISE (ajouté par toi :p )

Ce serait donc mieux de renommer comme les autres AR_OBJET_LIEN_STRICT (et pour le précédent, ça serait bien aussi de le renommer en le prenant avec le bon préfixe "AR" en priorité, et sinon celui actuel, pour rien casser).

Du coup cette modif me fait voir que j'ai un doute sur le code actuel car même si pas d'interface par défaut, tout objet peut être restreint (= être lié à la zone), or dans le test, quand c'est pas les tables mises en dur, ça appelle pas la fonction générique accesrestreint_objet_accessibles_where() qui existe bien, alors que ça devrait… Sinon pour le nom du define, tous les autres du plugin sont préfixés par "AR_", sauf le tout dernier ajouté ACCES_RESTREINT_FORCE_AUTORISE (ajouté par toi :p ) Ce serait donc mieux de renommer comme les autres AR_OBJET_LIEN_STRICT (et pour le précédent, ça serait bien aussi de le renommer en le prenant avec le bon préfixe "AR" en priorité, et sinon celui actuel, pour rien casser).
Poster

Bon, au final on fait quoi, on intègre cette PR ou bien je me ballade avec une branche dans mon coin ?

Je sais bien que c'est un cas particulier et encore une constante cachée de derrière les fagots, mais ça répond à un vrai besoin, très concret.

@cy.altern a validé, chez moi ça tourne en prod sur deux gros sites.

Bon, au final on fait quoi, on intègre cette PR ou bien je me ballade avec une branche dans mon coin ? Je sais bien que c'est un cas particulier et encore une constante cachée de derrière les fagots, mais ça répond à un vrai besoin, très concret. @cy.altern a validé, chez moi ça tourne en prod sur deux gros sites.

à minima si on garde tel quel, juste renommer la constante donc avec "AR" comme préfixe, pour pas augmenter le nombre de choses ajoutées ne correspondant pas à celles qui existaient

aussi je verrai plus pour le nom une analogie similaire à celles ajoutées par marcimat : AR_TYPE_RESTRICTION_LIENS et dire que quand la variable vaut "forte" alors ça restreint… plus fort (la question étant "quel est le type de restriction sur les liens ?")

sinon j'ai une impression que c'est pas intuitif à piger, parce que ça peut être un lien avec n'importe quoi d'autre y compris un vrai contenu classique :

  • imaginons ya un document qui est lié à un article restreint
  • ce même document, on le lie à un objet Patate, ou Chapitre etc non restreint, lisible par tous, un vrai contenu classique (pas un auteur, qui est assez particulier), juste c'est pas un article
  • les gens qui vont lire ce contenu normal ne verront pas le doc, ne pourront pas le télécharger, alors qu'ils ont parfaitement accès (et qu'ils ne peuvent même pas comprendre pourquoi ils n'y auraient pas accès, vu qu'ils sont bien sur une page ok)
  • et cela peut valoir y compris dans un site où on voudrait que si c'est lié à un auteur, ça continue de restreindre le doc, sauf que ça va valloir pour tout objet même vraiment éditorial
    Enfin en tout cas c'est pas clair dans ma tête :p
à minima si on garde tel quel, juste renommer la constante donc avec "AR" comme préfixe, pour pas augmenter le nombre de choses ajoutées ne correspondant pas à celles qui existaient aussi je verrai plus pour le nom une analogie similaire à celles ajoutées par marcimat : AR_TYPE_RESTRICTION_LIENS et dire que quand la variable vaut "forte" alors ça restreint… plus fort (la question étant "quel est le type de restriction sur les liens ?") sinon j'ai une impression que c'est pas intuitif à piger, parce que ça peut être un lien avec n'importe quoi d'autre y compris un vrai contenu classique : - imaginons ya un document qui est lié à un article restreint - ce même document, on le lie à un objet Patate, ou Chapitre etc non restreint, lisible par tous, un vrai contenu classique (pas un auteur, qui est assez particulier), juste c'est pas un article - les gens qui vont lire ce contenu normal ne verront pas le doc, ne pourront pas le télécharger, alors qu'ils ont parfaitement accès (et qu'ils ne peuvent même pas comprendre pourquoi ils n'y auraient pas accès, vu qu'ils sont bien sur une page ok) - et cela peut valoir y compris dans un site où on voudrait que si c'est lié à un auteur, ça continue de restreindre le doc, sauf que ça va valloir pour tout objet même vraiment éditorial Enfin en tout cas c'est pas clair dans ma tête :p
Poster

Renommer la constante pourquoi pas.

les gens qui vont lire ce contenu normal ne verront pas le doc

C'est bien le but justement.
Dans certains cas, si un doc est confidentiel, il ne doit pas du tout être accessible avec juste son lien.

Je sais bien que sur le web tout peut fuiter à partir du moment où c'est en ligne, mais que ça fuite juste parce que un utilisateur d'un extranet a envoyé un lien par mail par exemple, c'est trop permissif (dans certains cas, je répète).

De plus, ça invalide juste un des critères where de la requete, ça ne change rien en terme de perf.

(et je ne vois pas comment le faire autrement, avec un pipeline par exemple, mais si vous voyez mieux, pourquoi pas)

Renommer la constante pourquoi pas. > les gens qui vont lire ce contenu normal ne verront pas le doc C'est bien le but justement. Dans certains cas, si un doc est confidentiel, il ne doit pas du tout être accessible avec juste son lien. Je sais bien que sur le web tout peut fuiter à partir du moment où c'est en ligne, mais que ça fuite juste parce que un utilisateur d'un extranet a envoyé un lien par mail par exemple, c'est trop permissif (dans certains cas, je répète). De plus, ça invalide juste un des critères where de la requete, ça ne change rien en terme de perf. (et je ne vois pas comment le faire autrement, avec un pipeline par exemple, mais si vous voyez mieux, pourquoi pas)
Poster

Constante renommée, sans avis contradictoire depuis un moment, je fusionne.

Constante renommée, sans avis contradictoire depuis un moment, je fusionne.
nicod_ closed this pull request 11 months ago
The pull request has been manually merged as 33e4a9f6f1.
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.