Aide pour la mise en place de Allopass Carte bancaire

[ortolojf]

Bonjour

Pour mon site partenaire.

Je suis chargé de la mise en place de la solution de paiement Allopass paiement par Carte bancaire, pour laquelle il n'y a que la solution avec suivi et gestion par Allopass, des renouvellements d'abonnements, et des accès.

La philosophie est donc obligatoirement, un formulaire d'abonnement, et un formulaire des accès ( les deux sur notre site ), déclenchant chacun en POST, une url spécifique d'Allopass, avec des paramètres, dont au moins un identifiant de notre site, et un identifiant produit, ainsi que la variable lang indiquant le langage ( Français ou Anglais ).

Le fait est, que l'interface d'abonnement d'Allopass - sur leur site - nécessite que l'abonné entre son adresse email - valide -, pour recevoir son mot de passe, qu'il utilisera durant la durée de son abonnement, qui elle , dépend du produit que l'abonné a sélectionné dans notre boite-liste en amont, sur notre site, ce qui a fixé l'identifiant produit envoyé en paramètre.

Cependant, rien n'indique dans la documentation de Allopass, que Allopass nous transmette cette adresse email.

Il est possible, que notre site demande de manière séparée aux futurs abonnés, de fournir leur adresse email, mais celà indisposerait les abonnés, de fournir deux fois leur email, et puis les deux adresses email successives, peuvent éventuellement être différentes, sans que nous puissions le vérifier.

Donc, voici ma première question, à ceux qui ont déjà mis en place sur leur site, cette solution Allopass paiement par Carte Bancaire : Comment prendre connaissance, de l'adresse email des abonnés, communiquées par eux à Allopass ?

Je sais qu'il est possible d'utiliser pour ces deux formulaires, en émission, le paramètre data avec des données de notre choix, reçues ensuite par la variable $_POST['DATAS'] en réception, soit par "l'URL d'Acquittement" après un abonnement, soit par le "document protégé" après un accès. Cependant, celà ne nous permet pas de savoir l'adresse email enregistrée par Allopass.

C'est ma première question.

Ma deuxième question, après un formulaire d'accès validé. La documentation dit que nous pouvons vérifier la validité d'un mot de passe venant d'être utilisé, et reçu dans la variable $_POST['RECALL'] par ce script "protégé", pour peu que le paramètre recall ait été envoyé dans ce formulaire d'accès ( en hidden ), avec la valeur "1".

Mais... La documentation dit aussi, que ce "document protégé" n'est appelé, que si le code mot de passe fourni par l'abonné, est bon.

Cette vérification ultime ne sert-elle , comme sécurité, qu'à vérifier qu'une donnée identifiant l'abonné - fournie par nos soins dans le paramètre data - correspond bien au mot de passe pour cet abonné ?

A ce moment-là, évidemment celà suppose que nous soyons capable d'identifier en amont du formulaire d'accès, l'abonné, et donc de lui demander, par exemple, un login, ou son adresse email, de manière à pouvoir l'identifier, pour ensuite faire cette vérification, qui me semble relativement nécessaire, effectivement.

Ma dernière, et en fait seconde question - car la précédente, j'ai plutôt la réponse - c'est de savoir quelle est l'url appelée par Allopass, après le formulaire d'accès, si ce n'est pas le "document protégé".

Et, si ce n'est pas le document protégé, ou si à part le document protégé, il y aussi une autre url appelée, quelle est-elle ? Comment spécifier ou avoir connaissance de cette deuxième url, à part celle du "document protégé" ?

Ce sont la première et la dernière question, auxquelles j'aurais le plus besoin d 'avoir des réponses.

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo

[ortolojf]

Bon, mieux vaut tard que jamais...

En fait, l'ensemble du package d'abonnement Carte Bleue à Allopass, a été mis au point ( par mes soins ), de cette manière :

- Pour les accès :

L'abonné s'identifie par pseudo ( identifiant ) et mot de passe.

Le formulaire envoie le mot de passe à Allopass, qui relance le même script sur notre site avec le paramètre en mode POST (ou GET je sais plus ) RECALL, qui contient ce mot de passe. Lequel est vérifié dans le script avec une url fournie par Allopass, pour savoir si Allopass a authentifié l'abonné.

Le mot de passe, du point de vue de Allopass, est donc le seul critère d'authentification des accès.

Du point de vue de notre site, nous vérifions après lancement de cette url de vérification, que le pseudo associé fourni par l'abonné lors de l'accès, correspond bien au mot de passe, et que le temps restant associé enregistré dans notre base de données, est suffisant.

Les critères d'authentification, semblent donc suffisants.


- Pour les abonnements :

Là, deux solutions : Le prochain abonné existe déjà, ou il n'existe pas, et il doit créer un compte avec pseudo et adresse email, avec un formulaire interne à notre site.

Dans le cas où il existe déjà, qu'il a donc essayé de se connecter, et que son temps résiduel est insuffisant ( ou que son mot de passe n'est plus considéré comme valide par Allopass ), ou qu'il a créé le compte, une indication lui indique qu'il doit s'abonner.

L'abonnement se fait par un formulaire envoyé à Allopass comportant une fonction Javascript dans notre script, le script reçoit donc après envoi du formulaire, les éléments nécessaire à la modification de la base de données ( pseudo de l'abonné, montant payé, temps résiduel mis à jour, etc... ), et la fonction Javascript lancé par le formulaire d'abonnement juste avant, a lancé en asynchrone un autre script sur notre site, qui attend que le contenu de la base de données soit ajusté, et à ce moment-là, rend la main à la fonction Javascript avec le code 200, et la fonction Javascript recharge la page du script avec les paramètres qui vont bien ( transmis à la fonction Javascript par le formulaire ), pour que le contenu de la page soit mis à jour, et que l'abonné soit considéré comme connecté, et ses caractéristiques ajustées à son nouvel abonnement.

Pour qu'il soit possible d'avoir un contenu interactif, il a donc été nécessaire, de faire appel, non seulement à une fonction Javascript associée au formulaire d'abonnement, mais aussi à des fonctions Javascript de lancement asynchrone de l'autre script. Autrement, il aurait été nécessaire, pour que l'abonné prenne conscience que son abonnement est réussi, qu'il recharge la page lui-même, ce qui n'aurait pas été ergonomique.

Lourd, quand même...

Cela vient du fait, que le lancement du script par Allopass après abonnement, provient de l'adresse ip d'Allopass, et non pas de l'adresse ip de l'abonné, ce qui fait que le contenu renvoyé, parvient ( à la rigueur ) à Allopass, mais pas à l'abonné. Il est donc nécessaire de déclencher un refresh de la page dans cette fonction Javascript, à partir du script de départ, pour que l'abonné voit son abonnement visuellement pris en compte.

Il me semble, que ce n'est pas le cas pour des appels téléphoniques surtaxés Allopass, où le contenu de la page est bien mis à jour, sans qu'il ne soit nécessaire de faire tout ce bousin.

Et quand j'ai enfin réussi à mettre au point le bousin, qu'est-ce que j'étais content !

Bien à vous.

Amicalement.

Jean-François Ortolo