THELIA Forum

Bonjour à tous,

J'ai mon site sur un serveur de dév. (1.3.6), j'ai installé le plugin paiement CIC pour effectuer des paiements via le Crédit Mutuel. Avec les éléments fournis par la banque, tout fonctionne parfaitement sur la plateforme de test crédit mutuel. C'est OK et que du bonheur.

Maintenant, j'ai, sur le serveur de prod (un serveur différent du serveur de dév, chez un autre prestataire), fait mon install d'une 1.3.7, réimplanté tous mes templates, le site fonctionne parfaitement, mais dès que je veux exécuter un paiement CB test (avec les mêmes éléments que sur le serveur de dév.), j'ai ce message d'erreur au moment du click sur "Paiement CB" :

Invalid REQUEST_METHOD (not GET, not POST).

Je ne comprends pas, mes templates sont les mêmes entre le serveur de dév. et de prod., les données sont les mêmes, les éléments pour le fichier de config du plugin CIC sont les mêmes aussi, la seule différence est entre la 1.3.6 sur le serveur de dév. et la 1.3.7 sur le serveur de prod.

Ce message d'erreur est-il "explicable" uniquement par le passage vers la dernière version de THELIA ?

Merci à vous, je continue de chercher de mon coté.

Lester

Last edited by Lester (20-10-2008 14:21:54)

Un dernier doute m'habite... lors de la constitution du "sceau" par l'organisme qui gère le TPEV, n'y a-t-il pas un "lien" qui est fait avec le serveur hôte ?

Je m'explique. Lors du développement du site, j'ai livré à la banque l'URL de mon serveur de dév (ex: http://toto.lolo.com), sur ce site, ma connexion au système bancaire marche sans encombre, aucun souci.

Par contre, une fois que j'ai fait mon install sur le serveur de prod. (http://www.dudu.com, donc url différente de celle de mon serveur de dév), la connexion à mon TPEV ne se fait plus et j'ai donc ce désormais légendaire message "Invalid REQUEST_METHOD (not GET, not POST)." (vu environ 237 fois aujourd'hui).

Je me demande donc s'il n'y a pas corrélation entre le TPEV et l'url du serveur "émetteur", qu'en pensez-vous ?

J'en perds un peu mon latin (pourtant une bien belle langue, torte morte soit-elle).

Merci à vous de vos lumières.

Lester

as-tu bien repréciser à cybermut la nouvelle adresse de confirmation ?
ne pointe t-elle pas sur l'ancien adresse qui correspond à ton serv de dev ?

ton lien de retour CGI 2 est donc toujours celui du serveur de dev vu qu'il continue de fonctionner, ils n'ont donc pas effectué la modification de ce lien
c'est le seul lien entre le TPEV et le site que tu ne peux modifier toi même, eux seuls ont la possibilité de le modifier.

Salut Lester,

Apparement c'est un soucis avec php5...

Essai de trouver ces lignes sur le fichier paiement.php de ton plugin cic :

$stub_method = $HTTP_SERVER_VARS["REQUEST_METHOD"];
if (($stub_method == "GET") or ($stub_method == "POST")) {
    $wstub_order  = "HTTP_" . $stub_method . "_VARS";
    $stub_order  = ${$wstub_order};
}
else
    die ('Invalid REQUEST_METHOD (not GET, not POST).');

Oh tiens, ton fameux "Invalid REQUEST_METHOD" je te le remet, je crois que tu l'aime bien

Et remplace par :

$stub_method = $_SERVER["REQUEST_METHOD"];
if (($stub_method == "GET") or ($stub_method == "POST")) {
    $wstub_order = "_" . $stub_method;
    $stub_order  = ${$wstub_order};
}
else
    die ('Invalid REQUEST_METHOD (not GET, not POST).');

Tiens nous au courant si c'est bien ça...

++

C'est un soucis avec php5 oui et non.
Oui car ce sont des variables qui ne sont plus supportées par php5 en natif, et non car ... elles peuvent être supportées par php5 si on le souhaite.

Dans le php.ini:

; Whether or not to register the old-style input arrays, HTTP_GET_VARS
; and friends.  If you're not using them, it's recommended to turn them off,
; for performance reasons.
register_long_arrays = On

Coté baisse de perfs, rien de vraiment visible de mon coté avec cette option activée. Donc si vous avez la main sur votre conf php et que vous souhaitez une compatibilité maximum, vous pouvez les activer.
Il ne me semble pas avoir vu un kit php5 fournit par le CIC ou CyberMut ...
Donc pour le moment je garde la compatibilité des variables datant de php4.

[troll]
Pas sur que les banques aient un budget de développement d'un kit php5 vu la situation actuelle ...
[/troll]

Salut Lester,

Par hasard, dans ton fichier confirmation.php, ligne 97, ne faudrait-il pas changer :

$wCMCIC_bruteVars = "HTTP_".$CMCIC_reqMethod."_VARS";

par :

$wCMCIC_bruteVars = "_".$CMCIC_reqMethod;

Tiens nous au courant... l'enfer n'est qu'une étape!!!

++

Je regarde le fil de la discution et je voudrais revenir sur quelques points, En fait j'ai l'impression qu'il y a un problème de version de php, non pas à cause de PHP5 mais l'inverse pour une version ancienne, comme $HTTP_SERVER_VARS qui est une variable obsolète.

Rendez vous sur la doc de php vous le constaterez par vous même : http://www.php.net/manual/fr/reserved.v … server.php

elles ne sont pas dans le code de thélia, elles sont utilisés vraissemblablement par les modules fournis par la banque.

register_long_arrays, permet d'activer ou de désactiver les variable de type HTTP_*_VARS. Mais aujourd'hui elles ne sont plus utilisés (à part par nos très chères (ou chers ^^) banque). En le mettant à on tu les autorises, à off tu les interdits.

Merci eriath & manu,

Je viens de refaire mon config.php à l'aide du "tool" extract2HmacSha1.html livré par la banque... par deux fois... mais en vain... toujours ce maudit "CGI2 NOTOK"

Manu, juste pour revenir sur ce que tu indiques, sur le fait que les variables old school semblent être utilisées par le module de la banque, pour ma part, je n'ai rien fait d'autre que d'utiliser THELIA avec le plugin livré avec (CIC). Penses-tu que je dois procéder autrement et reprendre tout à zéro avec d'autres éléments (cette perspective me motive moyennement... ).

Eriath, quand tu parles de "revoir mon MAC", il s'agit bien des clés à calculer (pour le fichier config.php) en Hmac-SHA1 avec l'outil extract2HmacSha1.html du kit CIC-Crédit Mutuel ?

Merci à vous deux (et autres futur(e)s participant(e)s, on est bien içi, il fait chaud, ça sent bon le chocolat et puis on se marre toujours plus quand on est nombreux),

Lester

Last edited by Lester (08-11-2008 15:17:00)

Oui, en effet, je suis en environnement de test, le mail cgi2-ko@xxx.com me renvoie donc toute cette belle littérature :

Date:     Sat, 8 Nov 2008 14:49:19 +0100 [02:49:19 PM CET]
From:     COMMERCE ELECTRONIQUE <nepasrepondre@e-i.com>
To:     cgi2-ko@xxx.com
Reply-To:     COMMERCE ELECTRONIQUE <centrecom@e-i.com>
Subject:     TEST TEST *** Probleme CGI2 *** TEST TEST - Référence 144914 - VALIDEE

Votre CGI 2 de TEST a émis un accusé de réception invalide
et la commande a ete VALIDEE
---------------------------------------------------

TEST TEST TEST TEST **** Opération FICTIVE **** TEST TEST TEST TEST
TEST TEST TEST TEST **** Opération FICTIVE **** TEST TEST TEST TEST

RECAPITULATIF DU PAIMENT :

Numero de TPE commercant : XXXXXXX
Date du paiement : 2008-11-08 à 14:49:14
Reference du paiement : 144914
Montant du paiement : 33 EUR
Descriptif du paiement : -

TEST TEST TEST TEST **** Opération FICTIVE **** TEST TEST TEST TEST
TEST TEST TEST TEST **** Opération FICTIVE **** TEST TEST TEST TEST

Vous trouverez ci-dessous les informations relatives à la requête émise par notre serveur et la réponse renvoyée par votre CGI de confirmation (CGI2).

Cordialement.

CyberMUT Paiement - Paiement CIC
Commerce Electronique
mailto:centrecom@e-i.com

REQUETE EMISE PAR NOTRE SERVEUR :
GET (pour information):
http://www.xxx.com:80/client/plugins/ci … r=payetest

Méthode d'appel retenue : GET
TPE : XXXXXXX
Host appelé : www.xxx.com
Port : 80
CGI appelé : /client/plugins/cic/confirmation.php
Requête émise : TPE= XXXXXXX&date=08%2f11%2f2008%5fa%5f14%3a49%3a19&montant=33EUR&reference=144914&MAC=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&texte-libre=%2d&code-retour=payetest

Erreur 0

REPONSE DE VOTRE CGI DE CONFIRMATION :

Trying PHP<=3 old style !

Is it Better ?
Pragma: no-cache
Content-type: text/plain
Version: 1 Document Falsifie 0--XXXXXXX +++++1.2open++

***************************************************
ATTENTION !
Ce courriel a été envoyé depuis une adresse qui ne peut recevoir de réponse.
Merci d'utiliser centrecom@e-i.com pour toutes vos communications.
***************************************************

Je n'ai pas accès au php.ini sur mon hébergement, un phpinfo() peut-il faire ton bonheur ? Si oui, je t'envoie l'URL par mail.

Dis-moi (et thanks par avance !)

Lester

c'est vrai que moi aussi j'ai fait ce test ce matin d'appel direct dans mon navigateur du client/plugins/cic/confirmation.php... et même résultat que toi... mais j'en conclus pas grand chose