osCommerce France : Accueil Forum Portail osCommerce France Réponses aux questions Foire aux contributions

Bienvenue invité ( Connexion | Inscription )

5 Pages V  « < 3 4 5  
Reply to this topicStart new topic
> Atos - Commandes encaissées et non enregistrées, Cela arrive de temps de temps en temps ...
kenicki
posté 17 Feb 2012, 14:24
Message #101


Ceinture blanche OSC
Icône de groupe

Groupe : Membres
Messages : 5
Inscrit : 22-November 11
Membre no 30391



Salut Gnidhal,

Quand j'ai vu ton post, je me suis dit génial je vais enfin pouvoir le débarrasser de ces "foutus" variables OsCid qui traine dans mon URL.
Et malheureusement après tests ça ne fonctionne pas.

Voila ce que j'ai fait :
- Forcer l'utilisation des cookies
- Effectuer la modification que tu as proposé dans "application_top.php"

Et les variables de sessions sont effectivement disparues dans les URL mais la commande n'est jamais enregistrée dans mon interface.

Pour info, je suis sur une V2.2 RC2

As-tu une idée ?
Merci
Go to the top of the page
 
paddybl
posté 21 Feb 2012, 11:21
Message #102


Ceinture orange+ OSC
Icône de groupe

Groupe : Membres
Messages : 475
Inscrit : 22-September 06
Lieu : Lons le saunier(39)
Membre no 12229



salut désolé kenicki, mais gnidhal n'a jamais dit qu'il se débarrassait des osCId, au contraire...
il ne faut pas activer le forcage des cookies d'apres moi, ca c'est sur

l'osCid est obligatoire pour récupérer les infos de commande et valider.
Gnidhal pense que justement c'est cette osCid qui peut etre manquant et propose une solution pour etre sur qui soit bien récupéré dans tous les cas
qu'elle soit passé en post ou en get avec le data de ta banque

de mon coté j'ai 99% des commandes qui se valident correctement
j'ai programmé et je recois un mail de débuggage systèmatiquement en cas de problème avec les info du client, son nom et le montant et la cause de cette annulation ou erreur a chaque tentative infructueuse.
Et justement les rares fois ou je n'ai même pas se mail ou la commande validé, je retrouve le retour automatique en Failed sur le rapport de banque.

pas un problème d'osCid... soit disant que le serveur est injoignable...
d'autre que moi ont se problème de retour en FAILED?

la solution au problème de retour classique infructueux aurait pu etre le retour automatique sur la boutique, mais je confirme aussi les dire de Gnidhal sur la solution "ultime" de Brouillard... c'est de la fumée...
j'avais tenté quelques choses du genre nettement plus aboutit et celà ne résoud rien...

pour mémoire une vieille explication tres précise de ce type de tentative et du problème de retour en GET:

Citation
simtic
18 Jul 2009, 17:04
Bonjour,

J'ai travaillé ces derniers jours sur le site de Florian pour configurer le retour automatique.
Un petit mot ici pour faire un topo concernant cette intervention, qui s'est révélée assez, heu... riche en découvertes

Bon, le serveur de la banque communique ses infos à la boutique via une variable de nom DATA, qui contient les infos cryptées.
Cette variable est passée, selon les cas, en GET ou en POST, sur tel ou tel fichier php de la boutique.
le fichier qui reçoit la variable utilise le module d'Atos pour la décrypter et réagit ensuite en fonction des infos qu'il y trouve.
ça c'est l'idée.

ensuite,
plus concrétement:
Cette variable est passée une première fois au fichier checkout_process.php, en POST.
là, il s'agit d'une communication directe entre le serveur de la banque et celui de la boutique (ici, le navigateur de l'internaute n'intervient pas).

Puis lorsque l'internaute revient sur la boutique, il arrive sur le fichier atos_response.php.
Et là encore, on trouve le paramètre DATA.
Sauf que
- lorsque le retour automatique n'est pas activé, ce paramètre est transmis en POST (et là tout va bien)
- lorsque le retour automatique est activé (avec DATA!NO_RESPONSE_PAGE!), le paramètre DATA est transmis en GET (allez savoir pourquoi).

Et là, y'a deux problèmes :

1) le paramètre DATA, passé en GET, est mal introduit dans l'url de retour. Cette dernière contient déjà un paramètre GET (osCsid) pour l'identifiant de session, et le paramètre DATA devrait donc être séparé du paramètre osCsid par un &. Sauf qu'il est introduit par un point d'interrogation, comme s'il s'agissait de l'unique paramètre GET. on se retrouve donc avec une url de retour de la forme:
atos_response.php?osCsid=<id_de_session>?DATA=<valeur_du_parametre_DATA>
au lieu de:
atos_response.php?osCsid=<id_de_session>&DATA=<valeur_du_parametre_DATA>

ce qui fait que du point de vue de php, il n'y qu'un seul paramètre osCsid, et qui vaut:
<id_de_session>?DATA=<valeur_du_parametre_DATA>

donc un paramètre de session erroné, d'où la redirection en page d'accueil.

On peut régler ce problème en concaténant un & à la fin des urls de retour normal_return_url et cancel_return_url (dans atos.php).
Si ces urls se terminent par un &, le paramètre DATA n'est plus introduit par un ? et se retrouve bien séparé du paramètre osCsid.
et la session n'est donc plus perdue.

2) Mais j'ai ensuite rencontré un autre problème: une erreur au moment du décryptage du paramètre DATA. L'erreur indiquait que le paramètre DATA n'était pas de la bonne taille. là, je suis pas sûr (d'ailleurs si quelqu'un a une idée...), mais je me suis dit que ça pouvait venir du fait que ce paramètre étant d'une taille assez conséquente, il se pouvait qu'il se soit retrouvé tronqué dans l'url. Il me semble en effet que certains serveurs limitent la taille maximum des urls... enfin à vérifier.

Quoi qu'il en soit, en partant de cette idée, nous avons décidé de nous basé sur le paramètre DATA au moment où il est transmis au fichier checkout_process.php, puisqu'à ce moment-là, retour automatique ou pas, il est passé en POST. C'est à dire que nous avons mis en place un système de sauvegarde de ce paramètre, pour qu'il puisse être ensuite réutilisé au moment de l'appel à atos_response.php. Pour prendre en compte le fait que plusieurs commandes pouvaient être passées en même temps, nous avons d'abord pensé à créer une table en base, avec un champ customer_id et un champ DATA. Puis nous avons finalement opté pour une sauvegarde dans un dossier. Chaque paramètre DATA y étant enregistré dans un fichier dont le nom est formé avec l'identifiant du client. Lorsque le fichier atos_response.php est appelé, c'est donc à partir de cette sauvegarde que le paramètre DATA est récupéré, et non plus à partir du paramètre GET. Et voilà .


Ce message a été modifié par paddybl - 21 Feb 2012, 11:25.


--------------------
oscommerce version ms2fr-060817; contributions: AdminMS2fr_V2.3 - Easypopulate 2.76 - MS2-big_images 1.25 - 2.2-MS2 - BoxImageThemaMS2fr_V2.7 - BUY_TWO_MODULE-V21a - xsell_v2.3 - Your Recent History V3.0 - QTPro.v4.25 - Full-products_on_order1.2 - Ultimate_SEO_URLs 2.2.2 - .buy_now_link_to_button_v1.2c - Site Map MS2 - 2.3a-.robots1.1 - Dynamic Meta Tags - best sellers v1 - bestseller with admin - Review Approval System v1.3_1 - online_offline - SEO_Assistant_V_1.4 - Product Tabs 1.7-2 - avsearch - zones-french_Latin1 - new-faster-checkout - Anti Robot Registration Validation 2.4.01 - anti_spambot_contact_us_1.2 - anti_spambot_review_1_2 - colissimo_1.5.2 - ajax_contrib - GoogleFeeder103 - store feeds.v3.1 - categoriesFrontPage2-3d - Extra pages-info box w-admin 4_6 - PDF data-sheet v.1.7 compatible gif - CCGV5.18 - cvv2_version2 -Edit Order with ecotax- OrderCheck_v2.5.2 with Ecotax- orderlist4.0 - payment_atos_5_00-2.2.4 - payment_bluepaid-2 - Featured_Products_v1.5.8 - newsdesk_v_1.48.3 - .FAQDesk.v1.01.1 - French_Chronopost_Shipping - Popup Estimated Shipping v1.7b -optimize tax ver1.2-query debug 1.7-faster configuration cache 1.32- Print Order Receipt v1.4with ecotax- b2bsuite corrigé par moi ;o) ,

Ecotax v1.4.1 Plus Export, Paypal donation et Infinit'Images par moi même et d'autres à venir...
Go to the top of the page
 
Loocktet
posté 3 Mar 2012, 01:13
Message #103


Ceinture blanche OSC
Icône de groupe

Groupe : Membres
Messages : 1
Inscrit : 3-March 12
Membre no 30650



Bonjour à tous,
Depuis plusieurs jours, le retour automatique ne fonctionnait plus (avec bien sur, les conséquences de commandes encaissées et non enregistrées).
Pas de trace dans le log Apache (ou plutôt plus de trace de checkout_process), pas de mail d'erreur Atos, rien... sad.gif

Après quelques tests et recherches, j'ai pu constater qu'Atos ne supportait plus la réponse automatique sur une page en SSL (oui, je sais, c'est spécifié dans la doc mais ça marchait depuis plusieurs années).
J'ai modifié l'adresse de retour dans atos.php en remplaçant le $request_type par 'NONSSL' et là, miracle, cela fonctionne à nouveau.

CODE
$command .= " " . $this->os_info['quote'] . "automatic_response_url=" . tep_href_link(FILENAME_CHECKOUT_PROCESS, tep_session_name() . '=' . tep_session_id(), 'NONSSL', false) . $this->os_info['quote'];


Pour info, j'avais appliqué la modif de application_top.php postée par Gnidhal (merci!) dans ce topic afin de conserver la session en cas de retour sur une page non SSL.

Voilà, si ça peut aider ceux qui avait positionné leur page de réponse automatique en SSL...
Go to the top of the page
 
tofquer
posté 4 Mar 2012, 17:03
Message #104


Ceinture jaune OSC
Icône de groupe

Groupe : Membres
Messages : 56
Inscrit : 16-October 06
Lieu : Brest
Membre no 12677



Bonjour,

Depuis quelques temps, je rencontre aussi ce problème de commande bien payée mais dont la commande n'apparaît pas dans l'administration. A chaque fois, le problème vient quand il y a un doublon sur l'ID de commande des clients.
Encore aujourd'hui, deux clients ont le même numéro d'ID commande, l'un en paiement paypal et l'autre en paiement cyberplus, sauf que celui qui a payé par cyberplus, ba je n'ai pas sa commande ?
Les autres fois, la même chose sauf que les deux clients avaient payés avec cyberplus paiement.

Je viens d'installer la modif indiquée par Gnidhal, je verrai si ça change.


--------------------
osCommerce 2.2-MS2 + header tag SEO + SEO url rewriting + loginbox
Go to the top of the page
 

5 Pages V  « < 3 4 5
Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



RSS Version bas débit Nous sommes le : 28th March 2024 - 23:48
Ce site est déclaré auprès de la commision Nationale
de l'Informatique et des Libertés (déclaration n°: 1043896)