Discussion :

[psychoBob]

Bonjour,

J'avais demandé il y a quelque temps comment faire en sorte lorsqu'un visiteur s'inscrit sur le site A, qu'il le soit aussi sur le site B.
Il semble que le plus simple soit une iframe permettant d'insérer dans la page du site A, la page du site B chargée d'insérer les données dans sa base.
Ce pendant que la page A insère de son coté les données dans sa propre base, comme il se doit.

Mais voilà, je ne vois pas comment faire...
- Le visiteur valide le formulaire d'inscription sur le site A
- Il arrive sur une nouvelle page qui insère les données dans la base de A. Tout est classique jusque là.
- Dans cette page, il y a une iframe qui fait apparaitre la page du site B chargée d'insérer les données dans sa base (donc B). Cela le visiteur ne le voit pas, l'iframe est invisible.
- Un message de confirmation dit que le membre peut désormais utiliser ses informations sur A et B.

Donc, comment faire passer les informations du formulaire du site A dans la page B qui se trouve dans l'iframe ?

[ePoX]

Et pourquoi ne pas faire une requete post vers le site B après avoir inséré l'utilisateur dans le site A ?

cf fsockopen ect. Il y à deja eu quelques sujets à ce propos sur le forum.

Sinon si tu veux passer par une firame. Il faut que lorsque tu affiches le résultat de l'enregistrement dans le serveur A, tu pointes le src de ta iframe vers une page du serveur A.
Cette page vas générer un formulaire, dont l'attribut action pointe vers un controleur (une page php) du serveur B (controleur qui vas recevoir les données en post et les enregister dans la bdd du serveur B).
Dans la page du serveur pointé par l'iframe, il faudra faire une auto validation du formulaire en JS lors de l'evenement onload.

voila

bbye

[Mr N.]

pourquoi A ne communiquerait-il pas directement avec B ?

Client <===> A <===> B

Du coup pas besoin de ces horribles iframes

[psychoBob]

Et pourquoi ne pas faire une requete post vers le site B après avoir inséré l'utilisateur dans le site A ?

cf fsockopen ect. Il y à deja eu quelques sujets à ce propos sur le forum.

Sinon si tu veux passer par une firame. Il faut que lorsque tu affiches le résultat de l'enregistrement dans le serveur A, tu pointes le src de ta iframe vers une page du serveur A.
Cette page vas générer un formulaire, dont l'attribut action pointe vers un controleur (une page php) du serveur B (controleur qui vas recevoir les données en post et les enregister dans la bdd du serveur B).
Dans la page du serveur pointé par l'iframe, il faudra faire une auto validation du formulaire en JS lors de l'evenement onload.

voila

bbye

fsokopen m'a l'air bien, je vais approfondir ça, je ne pensais pas que c'était si compliqué, merci.

[psychoBob]

pourquoi A ne communiquerait-il pas directement avec B ?

Client <===> A <===> B

Du coup pas besoin de ces horribles iframes

Elles sont pas horribles les iframes, personnes ne les voit à priori. Ou alors horrible coté code peut être.

Pour Client <===> A <===> B, je ne voudrais pas ouvrir une fenêtre de B lorsque le client valide son formulaire sur A.
Ce qui me souci dans tout ça c'est faire transiter des informations entre deux sites.
Il est hors de question de faire transiter les codes de la bases de données, cela va sans dire, mais rien que les informations du client, ça m'ennuit.
Rq je code le passe en md5() à l'arrivé et pas pendant le transfert, mais bon, reste le mail quand même.

[Mr N.]

Ou alors horrible coté code peut être.

Oui c'est dans ce sens que je l'entendais

Pour Client <===> A <===> B, je ne voudrais pas ouvrir une fenêtre de B lorsque le client valide son formulaire sur A.

Où est ce que tu vois un lien entre B et le client ???
1. le client poste son formulaire sur A.
2. A fais des trucs
3. A demande à B de faire des trucs
4. B fais des trucs
4. B renvoie une réponse (à A)
5. A fais des trucs
6. A renvoie une réponse (au client)

=> le client ne sait pas que B existe... pas d'iframe cachée ou autres siouxeries...

Ce qui me souci dans tout ça c'est faire transiter des informations entre deux sites.

Tu dois mettre le meme niveau de sécurité de communication entre A et B qu'entre client et A

[psychoBob]

Bon quand je passerai à la pratique j'y verrai plus clair, là je m'informe à l'avance le temps que ça se décante.

psychoBob a écrit :
Ce qui me souci dans tout ça c'est faire transiter des informations entre deux sites.


Tu dois mettre le meme niveau de sécurité de communication entre A et B qu'entre client et A

C'est justement ce qui me parrait impossible. De client vers bd A c'est ok. Mais de client de A vers bd de B, forcément les informations du client transitent sur le réseau (ok j'y connais pas grand chose mais bon). Et là elles peuvent donc être interceptée.
Ceci dit si seul le pseudo, l'email et le pass transitent, sachant que le pass est codé par la page B avant l'insertion dans la bd B, le pirate qui récupère ça va en faire quoi ?
Que dalle, il aura un mail, bon, mais le pass qu'il aura aura été encodé par un md5() plus un paquet de sel.
L'important c'est qu'il n'ai pas les informations de la BD, non ?

Ou alors il faut une même bd pour les deux sites, du ssl etc... mais là ça me saoule, c'est que pour des forums, c'est pas des boutiques en ligne avec CB etc...
Et en plus si le pirate veut le code d'une personne en particulier, il va falloir qu'il sniffe pile au moment de l'inscription.

Vous en pensez quoi ?

[Mr N.]

De client vers bd A c'est ok. Mais de client de A vers bd de B, forcément les informations du client transitent sur le réseau

Premièrement le client ne communique pas avec une base de données, mais avec un serveur d'application écrit en php. (après à charge de php de faire des requètes dans une bd ou sur un filesystem)
Deuxièmement quand A communique avec B, il est un client vis à vis de B. C'est exactement comme si le client (le navigateur) attaquait directement B.

Ton navigateur ne connait pas les informations de connexion à la base de données de A. Donc A ne connait pas les informations de connexion à la base de données de B...

Et même, pour peu que A et B soit chez le même hébergeur, j'aurais tendance à dire que tu as plus de chance d'être intercepté entre Client et A que entre A et B...

[psychoBob]

Premièrement le client ne communique pas avec une base de données, mais avec un serveur d'application écrit en php. (après à charge de php de faire des requètes dans une bd ou sur un filesystem)
Deuxièmement quand A communique avec B, il est un client vis à vis de B. C'est exactement comme si le client (le navigateur) attaquait directement B.

Ah oui bien vu, tu m'as illuminé momentanément quelques neurones.


Donc j'en déduis que tu ne vois point d'inconvénients en terme de sécurité à ce système ? Du moins pas d'inconvénients majeurs ?

Et même, pour peu que A et B soit chez le même hébergeur, j'aurais tendance à dire que tu as plus de chance d'être intercepté entre Client et A que entre A et B...

Si tu peux en dire plus, j'ai surement quelque chose à apprendre...


Par contre je ne vois toujours pas comment insérer les données dans bdB depuis la page de B chargé de le faire, sans ouvrir cette page B dans A...

[Mr N.]

Ah oui bien vu, tu m'as illuminé momentanément quelques neurones.

Momentanément ? Flute, j'aurais préféré que ce soit permanent

tu ne vois point d'inconvénients en terme de sécurité à ce système ? Du moins pas d'inconvénients majeurs ?

Tant que tu n'appliques pas une politique de sécurité plus permissive entre A et B qu'entre Client et A, non je vois pas d'objection. (La force d'une chaîne réside dans son maillon le plus faible.)

[psychoBob]

J'ai édité le post au dessus mais comme tu as posté en meme temps, tu ne le verras peut être pas. Je reprend :

Et même, pour peu que A et B soit chez le même hébergeur, j'aurais tendance à dire que tu as plus de chance d'être intercepté entre Client et A que entre A et B...

Si tu peux en dire plus, j'ai surement quelque chose à apprendre...


Me voilà rassuré coté sécurité, par contre je ne vois toujours pas comment insérer les données dans bdB depuis la page de B chargé de le faire, sans ouvrir cette page B dans A... histoire de ne pas ouvrir x fenêtre de divers sites lorsque le client valide le formulaire d'inscription sur A.

[Mr N.]

Imaginons que A et B soit tous les deux hébergés chez un hébergeur H.
Quand A communique avec B, il y a quand même peu de chance que A sorte du réseau de H pour atteindre B, puisqu'ils sont dans la même infrastructure.
Alors qu'avec ton navigateur, quand tu communiques avec A, les paquets de données transitent à travers internet et j'estime qu'il y a plus de chance qu'un voisin se connecte sur ta passerelle wifi que das l'infrastructure de l'hébergeur.
(avis personnel qui n'engage que moi bien entendu)

[psychoBob]

Ok,

Bon quand je passerai à la pratique il faudra surement que je ré ouvre un post, mais au moins là je vois que l'idée est valable.

Merci

[Mr N.]

Me voilà rassuré coté sécurité, par contre je ne vois toujours pas comment insérer les données dans bdB depuis la page de B chargé de le faire, sans ouvrir cette page B dans A... histoire de ne pas ouvrir x fenêtre de divers sites lorsque le client valide le formulaire d'inscription sur A.

Exemple. Un client s'identifie sur un site A, mais en fait le mot de passe est vérifié sur un site B afin d'éviter à l'utilisateur d'avoir 36 mots de passe :

Code formulaire fournit par A :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
<form method="POST" action="login.php">
  <input type="text" name="login" />
  <input type="password" name="pwd" />
  <input type="submit" />
</form>

Code login.php (A) :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<?php
 
$params = 'login='. $_POST['login'];
$params .= '&pwd='. $_POST['pwd'];
$erreur = file_get_contents('http://www.B.com/error_in_login.php?'. $params);
if ($erreur) {
   echo "Erreur d'identification : ". $erreur;
} else {
   session_start();
   $_SESSION['is_logged_in'] = true;
   echo "Welcome";
}
?>

Code error_in_login.php (B) :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<?php
 
if ($_GET['login'] != 'john') {
   echo 'Login incorrect !';
} else {
   if ($_GET['pwd'] != 'smith24') {
      echo 'Pwd incorrect !';
   } else {
      //Tout est bon, on renvoie rien
   }
}
 
?>

Bien sur pas testé.

[psychoBob]

J'ai rien compris. Avant la technique, voyons l'idée générale.

- Le client est sur formulaire.php de A.
- Il valide le formulaire avec email et pass.
- Il arrive sur confirmation.php de A.
- Confirmation.php de A envoie les données dans BD de A.

Tous est normal jusqu'ici.
Maintenant comment fait-on intervenir la page confirmation.php de B ?

- Le client est sur formulaire.php de A.
- Le client valide, on ouvre deux pages, confirmation.php de A et en _blank confirmation.php de B.
- Les deux pages confirmation.php font leur boulot respectif vis à vis de leurs bases de donnée.

Problèmes :
- Je ne sais pas si on peut ouvrir deux fenêtres en validant un formulaire.
-C'est de toute façon bidon puisqu'on ouvre deux fenêtre, si il y a 10 sites ont en ouvre 10, c'est justement ce qu'il ne faut pas.

Conclusion :
C'est toujours obscure pour moi.

[ePoX]

Ce que tu n'arrives pas à omprendre c'est que lorsque l'on te dit que le site A communique avec le site B, le navigateur n'intervient pas.

En effet dans ce cas de figure on vas forger une requete HTTP en POST. Que l'on vas envoyé en PHP vers une page du serveur B.
Et cette page vas se comporter comme si un client navigait avec un navigateur, sauf que ce n'est pas la cas.

Récapitulatif (ou tentative) :


-> Client Envoie une requete vers le site A (utilise son navigateur)
----> Le Site A enregistre les données dans la BDD
----> Le site A créé une requete HTTP-POST en utilisant PHP
----> Le site A envoie la requete à destination du serveur B (http://serveurb.com/inserUser.php par exemple)
--------> Le site B recoit la requete HTTP
--------> Le site B enregistre les données dans sa base de données
--------> Le site B affiche une page avec un message confirmant l'insertion
----> Le Site A lit la réponse, accessoirement en fait quelquechose
----> Le site A génére la page de réponse pour le client
----> Le site A envoie la réponse au client
--> Le client recoit la réponse (utilise son navigateur)
--> Le client affiche la réponse à l'utilisateur (utilise son navigateur)
-> * CONGRATZ * Vous êtes inscrit (utilise son navigateur)

En esperant que cela t'aide à comprendre la mécanique.

bbye

[psychoBob]

Oui alors disons que ça s'éclaircit.

Ce que tu n'arrives pas à omprendre c'est que lorsque l'on te dit que le site A communique avec le site B, le navigateur n'intervient pas.

En effet dans ce cas de figure on vas forger une requete HTTP en POST. Que l'on vas envoyé en PHP vers une page du serveur B.
Et cette page vas se comporter comme si un client navigait avec un navigateur, sauf que ce n'est pas la cas.

Bon je partais de l'idée, non approfondie, que pour déclencher une action sur une page d'un site internet, il fallait que celui-ci soit affiché à l'écran. Je devrais raisonner en terme de serveur plutot, je crois.

-
> Client Envoie une requete vers le site A (utilise son navigateur)
----> Le Site A enregistre les données dans la BDD
----> Le site A créé une requete HTTP-POST en utilisant PHP
(Comment est-ce que cela se présente une requête HTTP-POST à l'intérieur d'un script php d'un site A à destination d'un site B) ?
----> Le site A envoie la requete à destination du serveur B (http://serveurb.com/inserUser.php par exemple)
--------> Le site B recoit la requete HTTP
--------> Le site B enregistre les données dans sa base de données
--------> Le site B affiche une page avec un message confirmant l'insertion
Non, il ne doit rien afficher, aucune page du site B ne doit s'ouvrir lorsque le client valide le formulaire du site A, même si une page de B doit réceptionner les données pour les envoyer dans sa propre base.
----> Le Site A lit la réponse, accessoirement en fait quelquechose
----> Le site A génére la page de réponse pour le client
----> Le site A envoie la réponse au client
--> Le client recoit la réponse (utilise son navigateur)
--> Le client affiche la réponse à l'utilisateur (utilise son navigateur)
-> * CONGRATZ * Vous êtes inscrit (utilise son navigateur)

Donc, nous sommes bien d'accord, le résultat doit être le suivant :

- Le client valide un formulaire sur une page du site A.
- Il se retrouve sur la page de confirmation du site A.
- Un message de confirmation lui dit qu'il est inscrit sur les deux.
- Mais tout à été transparent quant à l'inscription sur B, aucune page/fenêtre de B n'a eu besoin d'être ouverte par le client, ou automatiquement, pour insérer les données du formulaire dans bdB en plus de bdA.

C'est ça, on est sur la même longueur d'onde EpoX ?
Si oui, il me reste donc à comprendre, en terme de code pur, comment envoyer les données Vers confirmation.php de B depuis confirmation.php de A le tout sans ouvrir aucune page de B dans le navigateur.

[ePoX]

C'est tout à fait cela

Quand au comment, deux méthodes, fsockopen ou socket_create.

Je me contenterai de la première, la seconde n'étant pas forcèment utile ici.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 <?
// Les données envoyées en POST sous forme d'url
$data = 'txt1='.urlencode($txt1).'&txt2='.urlencode($txt2).'&id='.$id_session;
 
// monfichier.php3 est l'URL du fichier devant recevoir la requete POST 
$message  = "POST /monfichier.php3 HTTP/1.0\r\n";
$message .= "Content-type: application/x-www-form-urlencoded\r\n";
$message .= "Content-length: ".strlen( $data )."\r\n";
$message .= "\r\n";
$message .= $data."\r\n";
 
// monserveur correspond au serveur qui doit recevoir la requete
$fd = fsockopen( <a href="http://www.monserveur.com" target="_blank">www.monserveur.com</a>, 80 );
fputs($fd,$message);
fclose($fd);
?>

bbye

[Mr N.]

Quand au comment, deux méthodes, fsockopen ou socket_create.

Je rajouterais deux méthodes :
- http://php.net/curl
- http://php.net/file_get_contents

[psychoBob]

Ok c'est chouette, je sais que mon projet est possible.
Dès que je passerai à l'action, je saurai quels outils utiliser.

Merci à tous !

**edit**

Euh, une question quand même pour mieux situer le truc, fsockpen a été créer pour quoi au départ ?