Projet

Général

Profil

Bug #21330

identifiant de transaction réutilisé

Ajouté par Frédéric Péters il y a environ 6 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
-
Version cible:
-
Début:
22 janvier 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Callback de site de paiement :

  File "/usr/lib/python2.7/dist-packages/combo/apps/lingo/views.py", line 459, in post
    return self.handle_callback(request, request.body, **kwargs)
  File "/usr/lib/python2.7/dist-packages/combo/apps/lingo/views.py", line 411, in handle_callback
    transaction = Transaction.objects.get(order_id=payment_response.order_id)
  File "/usr/lib/python2.7/dist-packages/django/db/models/manager.py", line 127, in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/django/db/models/query.py", line 338, in get
    (self.model._meta.object_name, num)
MultipleObjectsReturned: get() returned more than one Transaction -- it returned 2!

À inspecter la db, l'identifiant a déjà été utilisé, en septembre 2017.

eopayment les assure uniques sur la journée.

Peut-être qu'en solution non-optimale mais très simple on pourrait ajouter une contrainte sur le start_date, pour ne pas risquer d'identifiant trop proche. (mais ça devrait être plusieurs jours quand même, sur l'idée qu'il peut y avoir des notifications tardives).

Ou alors au moment de l'initialisation de la transaction assurer l'unicité.

(Aussi, pour le moment, on génère un identifiant de six caractères, on pourrait taper plus, je crée un autre ticket).

Historique

#1

Mis à jour par Benjamin Dauvergne il y a environ 6 ans

Les différents backend ont des contraintes sur les tailles et syntaxe des identifiants de transaction différents, j'espère que je l'ai documenté dans le code pour ceux que j'ai fait mais rien n'est moins sûr.

Ils sont garantis unique sur une journée parce que c'est ce que demande les API assez souvent.

En attendant on peut faire Transaction.objects.filter(order_id=payment_response.order_id).order_by('-pk').first().

#2

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Statut changé de Nouveau à Résolu (à déployer)

Ça ne concernait a priori que systempay et sips, c'est corrigé sur eopayment depuis :

commit 5af46793682dc33a970763c0dc0b5ae41cbad667
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date:   Tue Apr 26 12:41:19 2011 +0200

    Ensure transaction id unicity, add logging to spplus

et sips a disparu. Pour les autres les collisions me semble improbable mais je peux refaire un tour:

eopayment/ogone.py:        reference = self.transaction_id(20, string.digits + string.ascii_letters)
eopayment/ogone.py:                + self.transaction_id(29 - len(orderid),
eopayment/paybox.py:            self.transaction_id(12, string.digits, 'paybox', self.site,
eopayment/sips2.py:        transaction_id = self.transaction_id(10, string.digits, 'sips2', data['merchantId'])
eopayment/spplus.py:        reference = self.transaction_id(20, ALPHANUM, 'spplus', self.siret)

coté TIPI pas de collision dans le temps possible :

eopayment/payfip_ws.py:    def _generate_refdet(self):
eopayment/payfip_ws.py-        return '%s%010d' % (isonow(), random.randint(1, 1000000000))
--
eopayment/tipi.py:    def _generate_refdet(self):
eopayment/tipi.py-        return '%s%010d' % (isonow(), random.randint(1, 1000000000))

et on va migrer de toute façon vers des références déterministes autant que possible via orderid.

#3

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

  • Statut changé de Résolu (à déployer) à Nouveau

Tu pointes un commit de 2011 qui aurait corrigé ça, mais ce ticket date de 2018. (?)

#4

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

Frédéric Péters a écrit :

Tu pointes un commit de 2011 qui aurait corrigé ça, mais ce ticket date de 2018. (?)

Tu n'indiques pas le backend, mais en 2018 ça devait donc être sips qui n'existe plus. Je pointais simplement que le problème avait été vu/corrigé dans d'autres backends avant et que les restants semblaient moins concernés. Le problème n'existe donc a priori plus.

PS: je te laisse re-fermer.

#5

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

  • Statut changé de Nouveau à Fermé

De la référence "on génère un identifiant de six caractères" ça pointe vers sips2, et après ce ticket il y a #21331, qui a passé l'affaire de 6 à 10 caractères, je voyais alors ça comme un contournement rapide, mais ok si on dit que ça permet d'ignorer la possibilité de problème ici.

#6

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Projet changé de Lingo à EOPayment

Pour sips2 il y a #47535 qui devrait régler le problème définitivement en plus d'éviter de remplir /tmp.

Aussi je déplace sur eopayment, lingo n'y étant pour rien.

Formats disponibles : Atom PDF