[Cookies] PHP interprété ! oui mais..

Version imprimable

13/12/2005, 13h53
Thierry8

[Cookies] PHP interprété ! oui mais..

Bonjour,

Je me pose une grande question:

PHP est interprété sur le serveur, des renseignements comme la date sont pris sur le serveur, jusque là nous sommes d'accords.

PHP ne communique pas avec le client (navigateur).
Ce que je veux dire, en prenant l'exemple de validation d'un formulaire simple:

1. l'utilisateur renseigne les informations nécessaires
2. l'utilisateur valide ces informations
3. données transférées au serveur
4. serveur receptionne les données (GET, POST, COOKIE, etc..)
5. serveur traite la page
6. le serveur envoit la page traitée

Le cheminement est bien ainsi ?

Là ou je veux en venir, c'est que le serveur ne communique pas avec le client, et donc lors de la connexion à une base de données, celle-ci est réalisée sur le serveur et les informations (mot de passe, login, etc..) ne transite pas, nous sommes d'accords ? Donc lors d'une connexion de ce genre il n'est pas possible d'intercepter les identifiants ?

Est-ce que je fais fausse route ?
13/12/2005, 14h01
khayyam90

Re: PHP interprété ! oui mais..

Citation:

Envoyé par Thierry8

1. l'utilisateur renseigne les informations nécessaires
2. l'utilisateur valide ces informations
3. données transférées au serveur
4. serveur receptionne les données (GET, POST, COOKIE, etc..)
5. serveur traite la page
6. le serveur envoit la page traitée

Le cheminement est bien ainsi ?

oui

Citation:

Envoyé par Thierry8

Là ou je veux en venir, c'est que le serveur ne communique pas avec le client, et donc lors de la connexion à une base de données, celle-ci est réalisée sur le serveur et les informations (mot de passe, login, etc..) ne transite pas, nous sommes d'accords ? Donc lors d'une connexion de ce genre il n'est pas possible d'intercepter les identifiants ?

les identifiants transitent, mais pas entre le client et l'interpreteur php, ils circulent entre l'interpreteur et le serveur de base de donnees. Donc le moyen d'intercepter les identifiants, c'est de surveiller les connexions entre interpreteur et serveur de base de donnees, ce qui est deja plus difficile.
13/12/2005, 14h02
Mr N.

Tu es sur la bonne voie. 8)

Juste pour préciser qu'il n'est pas obligatoire que ton serveur SQL soit sur la même machine que PHP et il est alors possible d'écouter ce lien. Mais il faut être à l'intérieur du réseau alors tu peux dormir tranquille ;)

EDIT: grilled
13/12/2005, 14h07
KiLVaiDeN

Bonjour,

En résumant :

1) L'utilisateur se "connecte" à un site, en faisant une requête HTTP sur une URL.

2) Le serveur reçoit la requête HTTP et l'interprête. Il retourne la réponse, en faisant tous les calculs impliqués dans cette tâche, que ce soit la connection à une base de données, ou bien l'interrogation par sms du Président de la république. Donc en aucun cas le client peut voir ce qu'il se passe coté serveur :)

3) Le serveur après avoir construit sa réponse ( en général constituée de balises HTML ) la retourne sur le port que le client a ouvert en attendant la réponse.

4) Le client reçoit les informations et les affiche. Une fois que la réponse est totalement transmise, la connection est fermée, et une nouvelle requête doit être formulée pour ouvrir une nouvelle URL :wink:

Le PHP est bien un langage interpreté coté serveur ( je "crois" qu'il y a cependant un compilateur de type JIT dans le moteur PHP, mais je ne suis pas sûr ), le client ne voit jamais transiter le code PHP !

En espérant ne pas m'être trompé dans mes explications (j'avais raison d'espérer,lol), A+ :D
13/12/2005, 14h26
Mr N.

Citation:

Envoyé par KiLVaiDeN

1) L'utilisateur se "connecte" à un site, en faisant une requête HTTP sur une URL. Je met le "connecte" entre guillemets, car il ne s'agit pas d'une connection de type socket; c'est une connection asynchrone, terminée dès que la réponse est envoyée.

Va falloire que je revois mes cours de réseaux car je ne pense pas que la connection est fermée tout de suite. Elle est dès que le serveur estime avoir fini d'envoyer la réponse. Deplus c'est bien une socket qui est ouverte par le navigateur.

Citation:

Envoyé par KiLVaiDeN

Le PHP est bien un langage interpreté coté serveur ( je "crois" qu'il y a cependant un compilateur de type JIT dans le moteur PHP, mais je ne suis pas sûr ), le client ne voit jamais transiter le code PHP !

Oui il y a un compilateur, le résultat est du op-code. C'est d'ailleurs là dessus qu'il est possible d'augmenter les perfs, en cachant (=mettre de coté pour un usage ultérieur) ce op-code. Pour illustrer : http://talks.php.net/show/acc_php/16
13/12/2005, 15h03
Thierry8

Et bien merci à vous tous !
Cela répond à mon interrogation ! 20 / 20 !!! ;)

Merci.
Thierry
13/12/2005, 16h16
KiLVaiDeN

Message erroné :D
13/12/2005, 16h37
KiLVaiDeN

Message erroné :D
13/12/2005, 16h46
Kioob

Citation:

Envoyé par KiLVaiDeN

Salut Mr N. :D
Oui il y a une socket d'ouvert par le navigateur, mais dans le but de recevoir une réponse asynchrone; il se peut que la réponse n'arrive jamais :) C'est pour ça que je dis que la connection est asynchrone, car nous on envoie la requête sur le port 80, on ouvre le port 23586 ( par exemple ) pour attendre la réponse, et la réponse ne vient que lorsque le serveur l'a établie, enfin selon ce que j'ai compris c'est comme ça que ça se passe, alors qu'une connection normale ouvrirait directement un port et ferait toutes les communications sur celui-ci, mais peut-être me trompette-je ? :D

Hello,

je ne suis pas du tout d'accord :
1) le client ouvre un socket sur le port 80 du serveur
2) le client envoi sa requete HTTP, et attend la réponse du serveur
3) le serveur répond au client, sur le même socket
4) le client et le serveur ferment le socket (sauf cas du "keep_alive")

Le port 35248 que tu vois "ouvert" sur le client est tout simplement le port source du socket ouvert. (35248 chez le client, 80 sur le serveur).

Par contre le fonctionnement que tu décris correspond à peu pret à celui du protocole FTP, d'où les nombreux problèmes avec les firewalls et routeurs.
13/12/2005, 16h47
Mr N.

J'me disais bien...
13/12/2005, 17h03
KiLVaiDeN

Message erroné :D
13/12/2005, 17h07
Mr N.

Et ben non, toujours à côté. :lol:

en 1.0, c'est la même chose que comme explique Kioob...
La différence entre 1.0 et 1.1, c'est la récupération des ressources.
Soit le code html suivant :

Code:

<html><body><img src="img.png" /></body></html>

en 1.0 tu as deux appels, en pour le flux html et un autre pour l'image.
en 1.1 tu as un seul appel

Mais pour les deux protocoles, le serveur répond sur la même socket qu'a ouvert le client pour la connexion en cours.
13/12/2005, 17h21
KiLVaiDeN

:oops: Eh ben dis donc, j'avais jusqu'à maintenant une notion erronée de la chose, je finirais la journée plus intelligent :D

En plus ce que vous dites est logique; dans la mesure où le système que j'explique necessiterait que le client puisse être contacté de l'extérieur sur un port spécifique de type "23865" ça ne fonctionnerait pas par exemple dans le cas de personnes utilisant un proxy, ou même un firewall.

Et oui en effet j'ai recemment vu le problème lié à FTP, il me semble que le client ouvre un port entre 21 et 30 ( ou quelque chose comme ça, je ne sais plus exactement ) et donc il faudrait ouvrir toute cette plage de port pour le client et c'est ennuyeux :(

Autant pour moi :D Désolé pour la mauvaise information, mis à part cette histoire de port mon histoire reste correcte cependant :wink: J'ai modifié mon message original pour eviter les confusions, A+ !