[Groupe : Client & Serveur] Communication

Voila, suite à un cours cet aprem, je me suis posé une paire de questions que je penses il peut etre utile de poser, au moins au cas ou....

Donc, voila, ça tombe bien comme la partie client est suposée etre en javascript et communicant avec le serveur, comme c'était un cours sur l'AJAX, ça tombe bien, j'ai découverts pleins de trucs qui pourraient peut-etre servir:
Déjà, pour le comm serveur/client, pour le moment c'est sensé etre du XML si je suis bien, hors je me suis rendu compte que c'est un peu le bordel à exploiter sous Javascript, et mon prof m'a parlé d'un truc qui pourrait etre bien utile aussi: le JSON.
Pour ceux qui ne connaissent pas, le JavaScript Object Notation et une façon d'écrire sous forme de chaine de caractère des objets javascript (et par extensions, des objets tout court ou à peu prés nimporte quel donnée/groupe de données/infos/tableau/...), ce qui pourrait etre trés interessant pour renvoyer les réponses du serveur, et c'est trés simple à utiliser, aussi bien du coté php que du coté javascript
Seul petit problème, c'est trés dur à débugger dés que la quantité d'info grandi.
Donc voila, si quelqu'un a déjà tester plus profondément (j'ai fait que survoler moi), qu'il le dise et donne son avi (Yell??^^), sinon, plus d'infos la ou la (moi perso, c'est le genre de truc bien dense et bien tordu que j'aime, mais bon, les "clienteurs", vous en pensez quoi? (les "serveureurs" peuvent naturellement participer, ainsi que tout le monde voulant ramener son grain de sel, ça va sans dire )

Sinon, pour ce qui est du javascript, toujours dans ce même court, je viens de découvrir un truc vachement simpa pour programmer vachement plus simplement (y a tout une partie AJAX toute classe avec biensur): un framework Prototype. C'est libre bien sur, et y a tout plein de choses pour simplifier beaucoup la prog javascript, si y en a qui veulent tester, aller faire un tour (seul petit prob, ça donne un beau fichier .js de 1800lignes (47Ko je crois), ce qui peut etre un poil long sur des vieilles connexions, mais bon, si on le charg e qu'une fois pour toute, pourquoi pas, enfin bref, à vous de voir, si qq'un a déjà tester bien dans tous les sens, qu'il se gène par pour donner son avis bien sur :p

Le JSON, je connais pas, navré mais je vais de ce pas regarder ce que ca donne. Sinon pour parcourir le XML il y a le DOM et c'est très simple ( du moins une fois qu'ont en compris ) et très bien implementé dans les navigateur.

Pour la library Prototype, je connais, c'est très bien, mais bon, comme je n'ai pas l'habitude de l'utiliser, ca me complique plus la vie plus qu'autre chose.

Voili voilou, mais merci Je savais pas qu'on apprennait ca en cours

Ba hé oh, faut bien qu'y ai quelques cours à peu prés interessant quand même lol (ça et la programation java appliqué à RoboCode, mais bon, ça c pas vraiment un cour, c'est plus un trip avec le prof de maths :p )

Sinon, ba pour ce que j'en ai fait, le JSON à l'air vachement simple pour passer des objets entiers de php à JavaScript, voir même nimporte quelle info, c'est du trés condensé, pas de superflu, c assez simpa, la galère c'est pour lire tout ça avec ces petits yeux, mais bon, ça une fois que c'est bien encapsulé, c'est pu un problème :p

un petit exemple de JSON:
Soit un objet php ayant pour attributs: nom, prenom, age et un tableau d'animaux par exemple, ça donnerai un truc dans ce gout la:

Code:

{ nom:Meme,prenom:Moi,age:25,[chien,chat,poisson] }

Essaie de me refaire ça avec du XML en moins de caractères lol

Bon, aprés ce n'est que mon avis, mais je trouve ça assez interessant

(je viens de voir ça, à parement, il y aurait une extension pour le JSON avec php 5.2)

Je suis pas contre le fait d'utiliser JSON, pour la communication client/serveur, vue que rien n'est encore fait de ce coté la

Mais le probleme de JSON c'est que c'est ciblé JS, donc on poura plus faire un client en .NET par exemple, sauf en parsant. C'est ca l'avantage du XML, il est implementé impeut partout

Mais, a la limite, on fait une classe de communitation, et apres, JSON ou XML, est encupsulé, comme ca, il y a meme plus de probleme

Ouai, je penses que si c'est bien encapsulé, on peut réutiliser le JSON un peu partout, je c'est pas trop, c'est ton coté ça, faut voir :p

Il faut juste qu'on normalize les requettes et les réponces, tu vois ca comment ? ( Generaliste ? Cas par cas ? )

Alors la, je t'avoue ne pas trop trop voir comment ça pourrait se goupiller lol.

Une idée comme ça, vu l'orientation objet du serveur, une page gérant une classe, aprés avec les parametres on appelle telle ou telle methode, avec telle ou telle parametres, et le serveur renvoie le res de la methode, ce qui implique beaucoup de boulot coté javascript.

Sinon, l'inverse, des pages serveur coté suivant ce qui se passe sur le navigateur (page batiments, recherches, ...), et le serveur renvoie un version "brute" de la page, mise en forme aprés par le js, ce qui la, relache beaucoup le le client, et fait plus bosser le serveur. Mais ça implique de savoir quelles pages faire coté client pour coder "l'équivalent" coté serveur.

Aprés, on peut faire un mix des deux, ou bien un truc sans aucun rapport, la nuit porte conseil y parrait, alors j'te dirais ça demain :p

Euh, en fait j'avais pensé faire comme ta première idée.

En gros, le client envois une requête POST à un script, celui-ci vérifie les droits, puis crée une instance de la classe cible et exécute la méthode cible.

En fait ca donne pas tant de boulot que ca, et puis comme ca, ca équilibre la charge de travail. Avec cette méthode on permet le portage du client.

Ba ok, moi si ça te semble viable, y a pas de prob, c partit comme ça!^^

Bon, sinon, je pensais, tant qu'on en était à faire dans la comm client/serveur, établir un mode de connection. Parce que, comme tout le monde le sait, une connexion toute bete par POST n'est pas vraiment ce que l'on peut qualifier de "sécuriser"...

Donc pour ça, je connais deux methodes assez différente, l'une est toujours craquable mais ne demande que peu de ressources, l'autre est un peu plus consomatrice en ressource, mais pour l'heure actuelle, virtuellement incraquable, car reposant sur les nombres premiers (pour ceux qui connaissent un peu de maths, je les renvoie à l'hypothese de Riemann, qui, tant qu'elle n'a pas été résolue, assure la sureté pratiquement totale de cette methode^^)

1ere methode: authentification par challenge.
Lorsqu'un client désire se connecter, le serveur, en meme temps que de lui envoyer classiquement le formulaire, lui envoie un challenge, une suite de caractères générée aléatoirement et de longueur quelquonque, et le serveur stoque ce challenge en session.
Le client, au lieu d'envoyer le mot de passe par POST (ou meme un hachage en MD5 du passe, ce qui ne change rien niveau securite :p), envoie un hachage MD5 de la concaténation du challenge et du pass haché en MD5 (en clair, le client envoie: MD5(challenge+MD5(pass)) lol)
Le serveur reçoit ça, et ayant gardé le challenge en session, peut aisément refaire lui aussi le calcul et comparer les deux condensats MD5.

2e methode: algorithme de Diffie-Helmann:
Cette methode est un peu plus lourde en ressources, mais virtuellement incraquable (ou alors, faut que le pirate y passe quelques annee si les nombres de départ sont assez grand).
Pour info, c'est cet algorithme qui est utilisé pour la plupart des sécurisations internet, la différence est que pour les banques et autres choses bien sécurisées du genre, elles utilisent des nombres premiers de l'ordre du quadrilion (10 puissance 15), ce qui rend le truc completement inviolable, mais meme avec des plus petits chiffres, ça marche trés bien :p

Petite explication:
-Tout d'abord, les deux ordinateurs choisissent deux nombres p et g premiers entre eux (le plus simple est meme premier tout court), avec g < p. Dans notre cas, ce serait le serveur qui les choisierait et les enverrai au client comme pour le challenge.
-Chaque ordinateur choisit un nombre aléatoire entre 1 et p. le serveur choisit a, et le client choisit b par exemple.
-Chacun de leur coté, les deux ordi vont faire un calcul trés simple:
le serveur calcule A = (g^a)%p (^ pour puissance, % pour le modulo)
et le client calcule B = (g^b)%p.
-Les deux ordinateur s'échangent leur chiffre. (par AJAX, c'est trés simple à faire, le client calcule sont chiffre, l'envoie au serveur qui lui renvoie le sien en échange).
Ensuite, les ordinateurs refont un petit calcul dans le genre du premier:
Le serveur calcule Ka = (B^a)%p et le client Kb = (A^b)%p
Et la, comme par magie, les deux ordinateurs obtiene le meme chiffre, ils ont donc un cle de cryptage secrete n'ayant jamais été communiquée sur le reseau (pour la demonstration que c'est toujours le meme nombre à la fin, désolé, j'ai vraiment pas le niveau en maths :p).
Et il est virtuellement impossible de retrouver K avec seulement p, g, A et B (à moins de pouoir décomposer A ou B pour trouver le nombre premier (a ou b) qui s'y cache, mais la décomposition de grands nombres en nombres premiers est trés trés longue, meme pour des supercalculateur (à moins bien sur un jour que quelqu'un arrive à résoudre la fameuse hypothese de riemann, mais je penses que ça nous laisse encore quelques temps pour voir venir lol)(Pour ceux qui regardent la serie numb3rs, il me semble qu'il y a un episode qui parle de ça lol, je sais pu trop, faudrait que je regarde lol, voir si y disent pas trop de betises :p)

Voila, donc la j'ai bien missioné pour ressortir tout ça du tréfond de ma tete, alors vous en pensez quoi? securite vite fait histoire de dire, ou truc serieux mais pas trop trop non plu?? lol

pour moi bien que dev ou /et math c'est proche de 0, je suis asser stresser par la sécurité.
Donc moin c'est aisé pour un quidam de me craker le system mieu je me porte.

Neosys

Lol, ba si tu veux neo, l'algo le + sécrisé la dedan c'est donc le 2e (algo de diffie-hellman), et si tu veux, je peux essayer de tester ça chez moi voir jusqu'à quel point ça fait pas trop galérer le serveur, et j'te di ça aprés :p

merci epso:)

neosys