Projet

Général

Profil

Bug #53944

Trace sur /api/forms/?full=on

Ajouté par Mikaël Ates (de retour le 29 avril) il y a presque 3 ans. Mis à jour il y a presque 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Frédéric Péters
Version cible:
-
Début:
11 mai 2021
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

Tests sur https://demarches-mates.test.entrouvert.org/api/forms/ avec ces comptes de tests : https://demarches-mates.test.entrouvert.org/backoffice/settings/api-access/ :
  • "test1" - Accès de test sans rôle et sans anonymisation.
  • "test2" - Accès de test avec rôle et sans anonymisation.
  • "test3" - Accès de test sans rôle et avec anonymisation.
  • "test4" - Accès de test avec rôle et avec anonymisation.

Le rôle donne accès en BO à ces données : https://demarches-mates.test.entrouvert.org/backoffice/management/inscription-aux-activites/

Pour test1 et test3 qui n'ont pas de rôle le retour est : {'data': []} OK

Pour test2 et test4 qui ont un rôle donnant accès à des données : Erreur 500 avec {'err': 1} NOK

Fichiers

0001-api-raise-bad-request-when-full-on-is-given-to-globa.patch (1,94 ko) 0001-api-raise-bad-request-when-full-on-is-given-to-globa.patch Frédéric Péters, 11 mai 2021 20:35
0001-api-raise-bad-request-when-full-on-is-given-to-globa.patch (1,94 ko) 0001-api-raise-bad-request-when-full-on-is-given-to-globa.patch Frédéric Péters, 12 mai 2021 08:23

Révisions associées

Révision 7255de9d (diff)
Ajouté par Frédéric Péters il y a presque 3 ans

api: raise bad request when ?full=on is given to global forms API (#53944)

Historique

#1

Mis à jour par Frédéric Péters il y a presque 3 ans

  • Sujet changé de Accès à /api/forms/ en HTTP BASIC retourne une 500 et {'err': 1} à Trace sur /api/forms/ receipt_time datetime vs struct_time
  • Statut changé de Nouveau à En cours
  • Assigné à mis à Frédéric Péters

Vraisemblablement aucun rapport avec l'authentification.

La trace,

Exception:
  type = '<class 'TypeError'>', value = ''datetime.datetime' object is not subscriptable'

Stack trace (most recent call first):
  File "/usr/lib/python3/dist-packages/wcs/formdata.py", line 1155, in get_json_export_dict
  1153         data['display_name'] = self.get_display_name()
  1154         data['text'] = self.get_display_label()
> 1155         data['receipt_time'] = datetime.datetime(*self.receipt_time[:6])
  1156         data['last_update_time'] = datetime.datetime(*self.last_update_time[:6])
  1157         data['criticality_level'] = self.criticality_level

  locals:
     anonymise = False
     data = {'id': '123', 'digest': None, 'display_id': '9-123', 'display_name': 'Inscription aux activités - n°9-123', 'text': 'Inscription aux
activités - n°9-123'}
     include_files = False
     self = <_wcs_Inscription-Aux-Activites 'Inscription aux activités - n°9-123' id:123>
     user = <wcs.api_access.ApiAccess.get_as_api_user.<locals>.RestrictedApiUser object at 0x7f524acb1f98>

On a donc cette demande (Inscription aux activités - n°9-123), dont la date de réception apparait être un datetime plutôt qu'un time.struct_time.

C'est curieux, brièvement testé, elle m'apparait bien en time.struct_time; et via https://demarches-mates.test.entrouvert.org/backoffice/management/inscription-aux-activites/123/json ça s'affiche.

#2

Mis à jour par Frédéric Péters il y a presque 3 ans

Vraisemblablement aucun rapport avec l'authentification.

De fait, après m'être donné du rôle, https://demarches-mates.test.entrouvert.org/api/forms/?full=on me donne la 500.

#3

Mis à jour par Frédéric Péters il y a presque 3 ans

  • Sujet changé de Trace sur /api/forms/ receipt_time datetime vs struct_time à Trace sur /api/forms/?full=on

En fait, /api/forms/?full=on, ce n'est ni documenté ni testé, et c'est normal parce que ça n'existe pas, comment t'es-tu trouvé à utiliser ça ?

Ce qui se passe c'est qu'on récupère les demandes en masse depuis la vue avec toutes les demandes, mais cette vue, elle ne contient pas les données et les date·heures y sont formatées différemment.

La résolution de ce ticket va être de lever une erreur 400 quand ?full=on est passé à cette API.

#4

Mis à jour par Frédéric Péters il y a presque 3 ans

#5

Mis à jour par Mikaël Ates (de retour le 29 avril) il y a presque 3 ans

En fait, /api/forms/?full=on, ce n'est ni documenté ni testé, et c'est normal parce que ça n'existe pas, comment t'es-tu trouvé à utiliser ça ?

Je pense que ça vient de l'usage sur les couche carto {{ eservices_url }}api/cards/piscine/geojson?full=on comme par exemple https://validation.test.entrouvert.org/manage/maps/layers/piscines-eo/edit/.

La résolution de ce ticket va être de lever une erreur 400 quand ?full=on est passé à cette API.

Ok.

#6

Mis à jour par Thomas Noël il y a presque 3 ans

'so such parameter (full)' j'imagine que tu voulais écrire "no such" et je propose d'écrire 'no such parameter "full"' histoire que le "(full)" ne soit pas lu comme "paramètre inexistant (et y'a un truc qui est plein dans cette affaire)".

#8

Mis à jour par Thomas Noël il y a presque 3 ans

  • Statut changé de Solution proposée à Solution validée
#9

Mis à jour par Frédéric Péters il y a presque 3 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 7255de9d3eedf9b76c923092fc26adcb5b241852
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Tue May 11 20:33:05 2021 +0200

    api: raise bad request when ?full=on is given to global forms API (#53944)
#10

Mis à jour par Frédéric Péters il y a presque 3 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF