Problème d'intégration avec un livreur

  • Posts: 27
  • Thank you received: 1
  • Hikashop Business
3 weeks 3 days ago #323561

-- HikaShop version -- : 4.3.0
-- Joomla version -- : 3.9.21
-- PHP version -- : 7.3

Bonjour,
Je suis en train de créer un plugin pour un livreur et je me heurte à un souci.

Le process fonctionne assez bien si l'utilisateur fait tout d'une traite.
-> Création d'un panier -> aller vers le checkout-> choisir son adresse de livraison -> choisir le mode de livraison -> le popup du service de livraison s'ouvre -> l'utilisateur complète le formulaire du livreur -> les données renvoyées par le livreur sont sauvées dans hikashop -> Arriver à l'étape de paiement.

Par contre si le client "hésite" et fait quelque chose du genre :
-> Création d'un panier -> aller vers le checkout-> choisir son adresse de livraison -> choisir le mode de livraison -> le popup du service de livraison s'ouvre -> les données renvoyées par le livreur sont sauvées dans hikashop -> Arrivée à l'étape de paiement -> retour en arrière pour changement d'adresse de livraison ->le popup du service de livraison s'ouvre à nouveau -> l'utilisateur complète le formulaire du livreur -> On reçoit les données du livreur on essaie de les sauver dans le panier et BOUM !.

A ce moment (de temps en temps, surtout si le client a pris un peu de temps on dirait) quand le popup se ferme, au lieu d'être redirigé sur l'étape de checkout suivante et que les infos du livreur soient sauvées l'utilisateur se fait déconnecter et donc tout le process de checkout est à refaire.

Nous avons beau chercher nous ne trouvons pas vraiment d'où ça vient. La seule piste que nous ayons c'est que l'on dirait que le session_id de la table #__hikashop_cart ne coincide plus avec aucun session_id de la table #__session. Une fois qu'on a mis à jours le cart via notre script.
Comme si le fait d'avoir mis à jours le cart via le plugin fesait que la session_id changerait ou ne corresponderait plus.

Le code pour mettre à jours le panier est assez basique en soi (j'ai retiré les étapes de vérification que les données étaient bien envoyées par le service de livraison, dans la réalité le code est un peu plus long (je regarde que $_POST contient bien tout ce qu'il doit et tout semble fonctionner. C'est juste qu'après le save dans certains cas on perd la cohérence dans la session :

public function onHikashopBeforeDisplayView(&$view) {
     $cartClass = hikashop_get('class.cart');
     $cartId = $cart->getCurrentCartId();

     if(!empty($_POST['orderReference']) && $cartId == $_POST['orderReference']) { // $_POST['orderReference'] is returned from the shipping manager and must match the cart actually in process
             $cart = $cartClass ->getFullCart($cartId);
             
             $cart->cart_params->bpost->deliveryMethodPriceTotal = $_POST['deliveryMethodPriceTotal'] / 100;
             $cart->cart_params->bpost->deliveryMethod = $_POST['deliveryMethod'];
             // some other params to add to cart_params.

             $cartClass->save($cart);

              // The popup of the shipping manager is closed and the checkout goes to the next step
      }
}

J'ai l'impression qu'en faisant comme nous l'avons fait, une subtilité avec les session nous a échappée. Du genre récupérer l'id du cart pour le comparer avec la réfèrence envoyée par le service de livraison via getCurrentCartId() n'est pas une bonne idée dans ce cadre ou quelque chose comme ça... Pouvez-vous nous aider ?

Merci d'avance.

Last edit: 3 weeks 3 days ago by info@lerenardquitrace.be.

Please Log in or Create an account to join the conversation.

  • Posts: 70518
  • Thank you received: 10587
  • MODERATOR
3 weeks 3 days ago #323565

Bonjour,

Pour moi, ce que vous décrivez indique qu'il y a 2 soucis:

- la session utilisateur est coupée par Joomla ( et donc normal que le session id ne corresponde plus ).
Je vous recommande de vérifier la valeur de l'option "session lifetime" dans la configuration de Joomla. Car si la valeur est trop faible alors vous aurez une perte de la session si l'utilisateur prend son temps et il faudrait en effet refaire le processus de passage en caisse.

- le panier est supprimé suite à la création de la commande et donc lorsque l'utilisateur annule son paiement, il ne retrouve plus son panier.
L'option "Clean cart when order is" de la configuration HikaShop permet de choisir si vous voulez que le panier se supprimer à la création de la commande ou au retour de l'utilisateur sur le site suite au paiement.

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 1
  • Hikashop Business
3 weeks 1 day ago #323605

Bonjour et merci pour la réponse.
- Le réglage de session de Joomla! est sur 30 minutes. Je ne pense pas que ce soit le soucis.
- A ce moment du checkout le panier n'est pas encore converti en commande. Il s'agit bien d'un plugin de livraison et pas de payement. L'étape de payement fonctionne d'ailleurs bien si on ne s'est pas fait déconnecté avant. De plus si le problème est survenu et que l'on s'est fait déconnecté et que l'on se reconnecte, le panier est toujours là et l'étape de checkout peut reprendre.

Je viens de passer beaucoup de temps à analyser la situation et ce n'est pas simple à expliquer.

En fait le plugin compile les données du panier pendant le checkout et les envoies à l'API du livreur. L'API (javascript) ouvre un popup pour que le client puisse entrer ses infos et préparer l'étiquette. Une fois que cette étape est faites, le popup retourne un iframe avec une url de retour que j'ai paramétrée avant. (Cette url est l'url de la page "derrière le popup" du checkout) avec des données en POST.

Dans le plugin je regarde si j'ai ces données $_POST et si c'est le cas je les traites et marque ce panier comme disposant d'une étiquette bien prète. Ensuite je ferme le popup (avec window.parent) et je passe à l'étape suivante.

Le problème survient si le popup reste ouvert plus d'une vingtaine de seconde et que l'on valide l'étiquette. AU moment ou l'iframe charge l'url de retour et on est déconnecté (donc au lieu d'arriver sur le checkout on revient sur la page d'accueil de la boutique).

Je ne comprends pas pourquoi quand on revient sur l'url de retour avec les données POST l'utilisateur se fait déconnecté. Et encore moins pourquoi ce n'est pas le cas si on a "bouclé" le process dans le popup en moins d'une vingtaine de secodnes...

Merci d'avance pour votre aide.

Please Log in or Create an account to join the conversation.

  • Posts: 70518
  • Thank you received: 10587
  • MODERATOR
3 weeks 1 day ago #323613

Bonjour,

1. 30 minutes c'est court pour un site d'ecommerce. Personnellement, je mettrais plutôt quelques heures.

2. Après pour le soucis d'être déconnecté au retour, c'est peut être un soucis entre la configuration du serveur et la façon dont est fait le retour.
Par exemple, je me souviens de cas de sites où les sessions des utilisateurs en https et en http étaient différentes. Et du coup, lors d'un passage de http à https, l'utilisateur perdait sa session, et donc son panier.
Tout ce que je peux dire, c'est que dans HikaShop il n'y a rien pour enlever la session de l'utilsateur ou la gérer. Tout cela est géré entre Joomla et le serveur web.

3. Une idée pour tricher:
Générez un token aléatoire et rajoutez-le au panier dans la base de données. Ensuite, dans l'URL de retour sur le site, fournissez le token ainsi que l'id du panier. Ainsi, vous pourrez vérifier que l'utilisateur a bien accès au panier. Ensuite, vous pouvez soit réassigner le panier à la nouvelle session, soit reconnecter l'utilisateur (si il a un compte joomla, c'est un peu plus compliqué, car il faut développer un plugin d'authentification pour valider la connexion).

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 1
  • Hikashop Business
3 weeks 1 day ago #323629

Bonsoir,
Effectivement, j'ai changé la valeur pour la durée de la session.
Merci pour le point 2, je suppose que c'est quelque chose comme ça, dans le cas présent l'url de retour est bien en https et tout le site est forcé en https. Mais il s'agit sans doute d'un conflit dans la communication entre les deux serveurs et je n'ai pas accès à ces infos (le livreur est un peu avare d'informations).

Pour le point 3. Hasard (ou pas ?) j'ai réalisé ce plugin cet après midi :D . J'ai utilisé une clé unique que j'envoie au transporteur et qui est analysée au retour. J'ai, en plus de cela, utilisé la colonne ip de la table #__hikashop_cart afin de vérifier qu'il s'agissait bien de l'utilisateur et je le ré-identifie.

Ensuite je change le token dans le formulaire dans window.parent et je passe à l'étape suivante. Je pense que ça va rester comme cela :-)

Merci pour l'aide.

Please Log in or Create an account to join the conversation.

Time to create page: 0.060 seconds
Powered by Kunena Forum