API éditer objet / fonction objet_inserer : associer l'auteur *avant* l'appel du pipeline post_insertion #3238

Closed
opened 9 years ago by tcharlss · 5 comments
tcharlss commented 9 years ago
Owner

Quand un objet générique est inséré en base par le biais de l'API, le pipeline post_insertion est appelé avant que l'auteur ait été associé à l'objet, cf. ecrire/action/editer_objet.php, L.210.

Du coup, lorsqu'on utilise le pipeline post_insertion, à ce stade l'objet est virtuellement sans auteur, ce qui occasionne des désagréments avec certaines fonctions d'autorisations : celles qui vérifient qu'on soit l'auteur de l'objet renvoient des faux négatifs.
Je n'ai pas rencontré d'autres problèmes, mais théoriquement, tout traitement qui implique l'auteur de l'objet est impossible.

J'ignore s'il y a une raison particulière à l'ordre actuel, sinon il faudrait faire appel au pipeline post_insertion après avoir associé l'auteur à l'objet

Quand un objet générique est inséré en base par le biais de l'API, le pipeline `post_insertion` est appelé *avant* que l'auteur ait été associé à l'objet, cf. `ecrire/action/editer_objet.php`, L.210. Du coup, lorsqu'on utilise le pipeline `post_insertion`, à ce stade l'objet est virtuellement sans auteur, ce qui occasionne des désagréments avec certaines fonctions d'autorisations : celles qui vérifient qu'on soit l'auteur de l'objet renvoient des faux négatifs. Je n'ai pas rencontré d'autres problèmes, mais théoriquement, tout traitement qui implique l'auteur de l'objet est impossible. J'ignore s'il y a une raison particulière à l'ordre actuel, sinon il faudrait faire appel au pipeline `post_insertion` *après* avoir associé l'auteur à l'objet
Poster
Owner

Allez un exemple concret, c'est plus parlant.
L'exemple suivant montre qu'un rédacteur n'obtient pas l'autorisation de modifier son article après l'insertion en base, alors que théoriquement il devrait pouvoir.
A ce stade, l'article n'a pas encore d'auteur associé, donc les autorisations qui vérifient les auteurs renvoient des faux négatifs.

function unplugin_post_insertion($flux){

	$objet     = objet_type($flux['args']['table']);
	$id_objet  = $flux['args']['id_objet'];
	$id_auteur = intval($GLOBALS['visiteur_session']['id_auteur'])
	include_spip('inc/autoriser');

	if ($objet == 'article'){
		if (autoriser('modifier', $objet, $id_objet)) {
			spip_log("post_insertion : auteur $id_auteur autorisé à modifier l'article $id_objet","debug");
		} else {
			spip_log("post_insertion : auteur $id_auteur pas autorisé à modifier l'article $id_objet","debug");
		}
	}

	return $flux;
}
Allez un exemple concret, c'est plus parlant. L'exemple suivant montre qu'un rédacteur n'obtient pas l'autorisation de modifier son article après l'insertion en base, alors que théoriquement il devrait pouvoir. A ce stade, l'article n'a pas encore d'auteur associé, donc les autorisations qui vérifient les auteurs renvoient des faux négatifs. <pre> function unplugin_post_insertion($flux){ $objet = objet_type($flux['args']['table']); $id_objet = $flux['args']['id_objet']; $id_auteur = intval($GLOBALS['visiteur_session']['id_auteur']) include_spip('inc/autoriser'); if ($objet == 'article'){ if (autoriser('modifier', $objet, $id_objet)) { spip_log("post_insertion : auteur $id_auteur autorisé à modifier l'article $id_objet","debug"); } else { spip_log("post_insertion : auteur $id_auteur pas autorisé à modifier l'article $id_objet","debug"); } } return $flux; } </pre>
Owner

Hum. Je ne suis pas certain que la liaison avec l'auteur doit être faite avant de passer par post_insertion.

Par contre, si vraiment dans ton plugin tu veux faire une action qui dépend d'une autorisation, tu peux utiliser autoriser_exceptions.

Exemple :

// créer l'auteur en suivant l'API pour que les pipelines s'activent include_spip('action/editer_auteur'); $id_auteur = insert_auteur(); autoriser_exception('modifier', 'auteur', $id_auteur); auteurs_set($id_auteur, array( "nom" => $nom, "statut" => "1comite" )); autoriser_exception('modifier', 'auteur', $id_auteur, false);

Hum. Je ne suis pas certain que la liaison avec l'auteur doit être faite avant de passer par post_insertion. Par contre, si vraiment dans ton plugin tu veux faire une action qui dépend d'une autorisation, tu peux utiliser autoriser_exceptions. Exemple : ` // créer l'auteur en suivant l'API pour que les pipelines s'activent include_spip('action/editer_auteur'); $id_auteur = insert_auteur(); autoriser_exception('modifier', 'auteur', $id_auteur); auteurs_set($id_auteur, array( "nom" => $nom, "statut" => "1comite" )); autoriser_exception('modifier', 'auteur', $id_auteur, false); `
Poster
Owner

Ca résoud un cas de figure lié au problème, mais celui-ci demeure.

Des fois, on a besoin de savoir si on a l'autorisation de mofifier un objet avant poursuivre, non pas de «forcer» celle-ci.
Et là, comme cette autorisation est toujours négative (même quand on devrait y être autorisé), il faut recourir à des hacks inavouables pour contourner le problème, cf. http://zone.spip.org/trac/spip-zone/browser/plugins/albums/trunk/albums_autorisations.php#L153 ou encore http://zone.spip.org/trac/spip-zone/browser/plugins/albums/trunk/albums_autorisations.php#L177

Encore une fois, j'ignore la raison qui fait que l'auteur est associé après l'appel du pipeline, mais en tout cas je constate que ça cause un problème avec certaines autorisations à modifier.

Ca résoud un cas de figure lié au problème, mais celui-ci demeure. Des fois, on a besoin de *savoir* si on a l'autorisation de mofifier un objet avant poursuivre, non pas de «forcer» celle-ci. Et là, comme cette autorisation est toujours négative (même quand on devrait y être autorisé), il faut recourir à des hacks inavouables pour contourner le problème, cf. http://zone.spip.org/trac/spip-zone/browser/_plugins_/albums/trunk/albums_autorisations.php#L153 ou encore http://zone.spip.org/trac/spip-zone/browser/_plugins_/albums/trunk/albums_autorisations.php#L177 Encore une fois, j'ignore la raison qui fait que l'auteur est associé après l'appel du pipeline, mais en tout cas je constate que ça cause un problème avec certaines autorisations à modifier.
Owner

Statut changé à Fermé

**Statut changé à Fermé**
Owner
There is no content yet.
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.