formulaire_editer_article_verifier : vérification incomplète #3686

Closed
opened 7 years ago by peetdu · 5 comments
peetdu commented 7 years ago

Il me semble qu'il manque une vérification dans https://core.spip.net/projects/spip/repository/entry/spip/prive/formulaires/editer_article.php#L157 ?
Puisque l'on test l'autorisation creerarticledans c'est que l'on est bien dans la cas d'une création. Donc blinder avec !is_numeric($id_article) ?

auquel cas la ligne 157 deviendrait

and !autoriser('creerarticledans', 'rubrique', _request('id_parent')) and !is_numeric($id_article)

Exemple : un site où les internautes soumettent des projets (des articles en l'occurrence). Le dépôt des projets est soumis à une date limite.
Après cette date, il n'est plus possible de créer des nouveaux projets, mais les déposants doivent pouvoir encore modifier leur projet.

Il me semble qu'il manque une vérification dans https://core.spip.net/projects/spip/repository/entry/spip/prive/formulaires/editer_article.php#L157 ? Puisque l'on test l'autorisation _creerarticledans_ c'est que l'on est bien dans la cas d'une *création*. Donc blinder avec <var>!is_numeric($id_article)</var> ? auquel cas la ligne 157 deviendrait <pre> and !autoriser('creerarticledans', 'rubrique', _request('id_parent')) and !is_numeric($id_article) </pre> Exemple : un site où les internautes soumettent des projets (des articles en l'occurrence). Le dépôt des projets est soumis à une date limite. Après cette date, il n'est plus possible de *créer* des nouveaux projets, mais les déposants doivent pouvoir encore *modifier* leur projet.
b_b commented 7 years ago
Owner

Sur le principe ça me semble logique, mais il faudrait vérifier que cela ne va pas générer des effets de bord. Un truc que je ne comprends pas, c'est quand tu dis :

Après cette date, il n'est plus possible de créer des nouveaux projets, mais les déposants doivent pouvoir encore modifier leur projet.

Tu veux dire que tu as surchargé l'autorisation en question ? Dans quel cas tombes tu sur un bug ?

Sur le principe ça me semble logique, mais il faudrait vérifier que cela ne va pas générer des effets de bord. Un truc que je ne comprends pas, c'est quand tu dis : > Après cette date, il n'est plus possible de créer des nouveaux projets, mais les déposants doivent pouvoir encore modifier leur projet. Tu veux dire que tu as surchargé l'autorisation en question ? Dans quel cas tombes tu sur un bug ?
Poster

La ligne https://core.spip.net/projects/spip/repository/entry/spip/prive/formulaires/editer_article.php#L157, vient de
https://core.spip.net/issues/2508.

L'avantage (?) de https://core.spip.net/projects/spip/repository/revisions/19075, c'est que ça gère aussi bien les cas de création et de modification d'un article dans une rubrique interdite.

J'ai donc testé mon patch avec le cas d'un admin restreint et il n'y a pas d'effet de bord : ceci grâce à autoriser_article_modifier().

Il est donc question ici de compléter/corriger cette demande : il doit être possible de voir et de modifier, même si il est interdit de créer.

Le bug que j'ai trouvé :

C'est le cas qui se présente avec le plugin LIM

1- un article ou des articles ont été créés dans une rubrique;
2- puis le webmestre décide plus tard d'interdire la création de nouveaux articles dans cette même rubrique, ceci grâce à une fonction du plugin LIM;
3- Mais si il n'est plus possible de créer un article dans cette rubrique, LIM gère le cas où l'auteur veut les modifier ses articles présents dans cette rubrique.

Donc le bug soulevé vient du fait que le plugin LIM surcharge l'autorisation autoriser_rubrique_publierdans(). Plus exactement, il ajoute une condition.
voir http://zone.spip.org/trac/spip-zone/changeset/95014/plugins/lim/trunk/lim_autorisations.php.

Je précise que cette fonctionnalité du plugin LIM pose un problème seulement avec l'objet Article. Pas avec les autres objets éditoriaux.

Voilà. J'espère n'avoir rien oublié.

La ligne https://core.spip.net/projects/spip/repository/entry/spip/prive/formulaires/editer_article.php#L157, vient de https://core.spip.net/issues/2508. L'avantage (?) de https://core.spip.net/projects/spip/repository/revisions/19075, c'est que ça gère aussi bien les cas de création et de modification d'un article dans une rubrique interdite. J'ai donc testé mon patch avec le cas d'un admin restreint et il n'y a pas d'effet de bord : ceci grâce à autoriser_article_modifier(). Il est donc question ici de compléter/corriger cette demande : il doit être possible de voir *et de modifier*, même si il est interdit de créer. ### Le bug que j'ai trouvé : C'est le cas qui se présente avec le plugin LIM 1- un article ou des articles ont été créés dans une rubrique; 2- puis le webmestre décide plus tard d'interdire la création de nouveaux articles dans cette même rubrique, ceci grâce à une fonction du plugin LIM; 3- Mais si il n'est plus possible de créer un article dans cette rubrique, LIM gère le cas où l'auteur veut les modifier ses articles présents dans cette rubrique. Donc le bug soulevé vient du fait que le plugin LIM surcharge l'autorisation autoriser_rubrique_publierdans(). Plus exactement, il ajoute une condition. voir http://zone.spip.org/trac/spip-zone/changeset/95014/_plugins_/lim/trunk/lim_autorisations.php. Je précise que cette fonctionnalité du plugin LIM pose un problème seulement avec l'objet Article. Pas avec les autres objets éditoriaux. Voilà. J'espère n'avoir rien oublié.
Owner

cette ligne sert à verifier qu'on essaye pas de déplacer l'article dans une rubrique où on aurait pas le droit d'ecrire (ie si on est par exemple pas admin)

cette ligne sert à verifier qu'on essaye pas de déplacer l'article dans une rubrique où on aurait pas le droit d'ecrire (ie si on est par exemple pas admin)
Poster

Ok merci pour l'info.

On peut fermer ce ticket du coup.

Ok merci pour l'info. On peut fermer ce ticket du coup.
b_b commented 4 years ago
Owner

Et hop :)
Statut changé à Fermé

Et hop :) **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.