Discussion :

[berceker united]

Bonjour,
J'ai un besoin assez particulier qui est de pouvoir manager une ou des bases de données SQLServer et Mysql. Ma question est de savoir quelle est la meilleur méthode à utiliser pour pouvoir communiquer avec.
L'un des tout premier critère c'est que le script soit très rapide. Du coté PHP j'ai fais en sorte de ne pas utiliser de framework et d'écrire de manière optimisé et propre. De ce fait, j'obtiens de bon score sur du gros volume.
Maintenant, reste la meilleur façon de communiquer avec Flex et Air afin que cela puisse être souple en terme de paramétrage concernant la connexion. C'est à dire, où il va chercher les données. Il faut pas que ceci puisse être écrit dans le code Flex.
Pour des raisons d'optimisation de temps et de traitement je souhaite pas interfacé une framework (AMFPHP/Zen_AMF).
Pour l'instant je me suis cassé les dents sur le Webservice avec Flex. Il me reste donc le HTTPService en sachant que les réponses du serveur ne sera que du XML. Est-ce délirant ou pas décommandé d'utiliser de telle méthodes pour ce type de projet.
Merci

[Madfrix]

J'ai pas tout saisi de ta requête mais il faut savoir que le protocole amf est de loin le plus performant. Certes zend_amf par exemple est long à instancier vu qu'il s'agit d'un framework mais une fois lamachine lancée, le protocole amf pulvérise tout

Un test ici !

[berceker united]

J'ai pas tout saisi de ta requête mais il faut savoir que le protocole amf est de loin le plus performant. Certes zend_amf par exemple est long à instancier vu qu'il s'agit d'un framework mais une fois lamachine lancée, le protocole amf pulvérise tout

Un test ici !

En faite, ma question est de savoir si j'utilise HTTPService serait ridicule dans mon type d'utilisation plutôt qu'un webservice ou AMF vu que dans mon cas j'ai essuyé quelque échec. Mais au vu des test il semblerait que AMF colle la pâté à tout autre technologie et j'ai besoin justement de ce temps de réponse et réaction. Donc je vais me sortir les doigts là ou il devrait pas et tester ta méthode .

[Jim_Nastiq]

HTTPService c'est ni mieux, ni moins bien qu'une autre solution, c'est une solution

Concernant AMF regarde du coté de AMFphp qui est beaucoup plus simple a mettre en oeuvre que ZendAMF, ca te permettra de faire qq tests avec amf et une solution php coté serveur.

[alain31tl]

HTTPService c'est ni mieux, ni moins bien qu'une autre solution, c'est une solution

Bonsoir

+1

Perso, je l'ai adoptée puisque je développe php en "dur".
J'ai cette chance.
Et celà permet beaucoup plus de souplesse dans les scripts... et surtout lorsqu'ils sont complexes.

Un framework de développement n'aura jamais toute la faculté de l'homme et de sa réflexion.
Il ne propose que des solutions, certes pratiques ou courantes, mais limité dans l'élaboration d'algos.
C'est une bonne initiative, ou alternative selon, mais il ne fait pas le café à notre place, et on est un peu dépendant de ses possibilités.
Quand on a pas le choix.

En ce qui concerne les réponses serveur :
- "Ce n'est que du XML" ???

Et alors ?...mais c'est bien bien ? ...On ne va tout de même pas révolutionner le xml ?

C'est top top

[berceker united]

Entre temps, j'ai choisie le HTTPService. Pour les même raisons que tu évoques. Cela me permet de m'affranchir d'une framework dont j'ai pu esquiver son utilisation jusqu'à présent. L'utilisation d'un xxxamf rend en partie figé la solution.
Par contre j'ai pas compris ta partie concernant le XML.

[Jim_Nastiq]

Je pense qu'il voulait dire qu'il était plus pro XML et donc que le XML etait selon lui une bonne solution

si tu veux mon avis, je ne serais pas si affirmatif sur le bien fondé des échanges XML mais c'est un autre débat

[berceker united]

Je pense qu'il voulait dire qu'il était plus pro XML et donc que le XML etait selon lui une bonne solution

si tu veux mon avis, je ne serais pas si affirmatif sur le bien fondé des échanges XML mais c'est un autre débat

Ha mais non, exprime toi sur ce sujet, je voudrais avoir ton avis sur ce point puisque je pense que beaucoup se pose la question, comme moi.

[Jim_Nastiq]

Alors qq remarques sur le XML :

-extrêmement verbeux, et donc a proscrire dans ces certains cas (optimisation bande passante)
-rapidement compréhensible/lisible pour un humain
-parseur puissant en flex (=> E4X)


Le premier point étant pour moi très important, il faut bien étudier ce que l'on souhaite échanger et dans quel contexte l'échange aura lieu. J'ai vu des cas ou des échanges client serveur se faisait par XML uniquement pour échanger des nombre, entier ou boolean ... c'est un cas extreme mais ca existe

envoyer 40 caractères pour 2 caractères de données c'est la misère

bref le xml c'est normalisé et très utilisé donc c'est un classique mais il faut bien analyser son besoin avant de l'utiliser

[berceker united]

Alors qq remarques sur le XML :

-extrêmement verbeux, et donc a proscrire dans ces certains cas (optimisation bande passante)
-rapidement compréhensible/lisible pour un humain
-parseur puissant en flex (=> E4X)


Le premier point étant pour moi très important, il faut bien étudier ce que l'on souhaite échanger et dans quel contexte l'échange aura lieu. J'ai vu des cas ou des échanges client serveur se faisait par XML uniquement pour échanger des nombre, entier ou boolean ... c'est un cas extreme mais ca existe

envoyer 40 caractères pour 2 caractères de données c'est la misère

bref le xml c'est normalisé et très utilisé donc c'est un classique mais il faut bien analyser son besoin avant de l'utiliser

En effet, le XML donne beaucoup de possibilités mais le risque c'est d'en trop en faire.

[Madfrix]

Bonjour,

entièrement d'accord ! Entre choisir entre la rapidité de compréhension humaine et la rapidité de compréhension informatique, c'est tout vu...

Je prends un exemple concret : les 2 classes de connexion sockets xmlSocket et Socket. Une de ces classes transmet et reçois les infos sous forme xml (je vous laisse deviner laquelle !) et l'autre sous forme binaire. y'a pas photo de rapidité entre les 2...j'ai même envie de dire que la classe xmlSocket devrait être considérée comme dépréciée...

Une question au passage : celui qui sniffe le réseau et intercepte donc des paquets binaires (cas amf ou classe Socket) peut il facilement décrypter ces paquets à l'instar de ce que fait l'appli ultérieurement ?

merci

[berceker united]

Là, je dis "attention". Il faut trouver une frontière juste car si nous rentrons dans le domaine de sécurité, nous risquons de rentrer dans l'excès au même titre que le XML. On peut sniffer 98% du traffic web. A cela je donne qu'une réponse. identification et HTTPS. Je pense que le socket est assez facilement décryptable.

[alain31tl]

... Il faut trouver une frontière juste car si nous rentrons dans le domaine de sécurité, nous risquons de rentrer dans l'excès au même titre que le XML...

C'est clair.

Concernant le xml, j'avoue aussi que je parlais de mon cas d'utilisation.
Je n'exploite pas des fichiers de réponses dépassant 2 MO.
Et le temps de réponse est correct, ou me semble correct, ... et 2 ou 3 MO, celà représente déjà un joli fichier.

Alors maintenant, c'est vrai, tout est relatif.
Et même si je souhaitais optimiser les perfs, je serais pénalisé par les "mini-temps" utiles pour la compression et décompression.
C'est quasi certain.

[alain31tl]

....Une question au passage : celui qui sniffe le réseau et intercepte donc des paquets binaires (cas amf ou classe Socket) peut il facilement décrypter ces paquets à l'instar de ce que fait l'appli ultérieurement ?

merci

Bonsoir

J'avais oublié de répondre à cette question.
J'utilise un système de gestion de session php, et bien entendu pour des réponses au format xml.
==> Non pas cookies mais serveur.
Ce qui signifie que si les paramètres d'identification ne sont pas valides, aucune session n'est initialisée.
Une session valide conditionne l'accés à certaines données.

A l'inverse, seul l'identifié a accés aux données sollicitées...et depuis son poste de travail.
En l'occurrence, transmises vers le navigateur de son PC (temporaires), et non pas enregistrées sur le PC.
Par conséquent, il ne peut y avoir de fuites, ou données susceptibles d'être "sniffées".

[Madfrix]

En fait, je sous entendais que le "sniffeur" était l'utilisateur de l'appli destinatrice du socket. En effet, prenons l'exemple de la classe Socket (envoi binaire donc) l'appli Flex recoit ce message, le décrypte puis agit en conséquence. L'utilisateur de l'appli ne doit quand à lui ne rien voir de cette transmission encodée. Or, via des sniffeurs, il peut récupérer l'envoi du serveur de socket sous forme binaire. Peut il décoder ce message facilement ? Je pense que oui puisque la classe Socket et le serveur Zend_Amf pour ne parler que d'eux le font.

[alain31tl]

... En fait, je sous entendais que le "sniffeur" était l'utilisateur de l'appli destinatrice du socket... .

Et même, celà change quoi puisque ces infos lui sont destinées.(?)
Si celui-ci est identifié, il a nécessairement accés à certaines données, binaires ou pas.
Mais ce qui ne sera pas le cas pour d'autres.
J'avoue ne pas comprendre cette "inquiétude".

[Madfrix]

Et même, celà change quoi puisque ces infos lui sont destinées.(?)

Destinées oui, mais il n'a pas à connaitre le "cheminement" et la méthodologie employée pour lui envoyer.

Prenons encore l'exemple d'une socket (non binaire), toutes les informations circulent donc en clair ou presque. Si l'utilisateur clique sur un bouton, il peut potentiellement envoyer une requête au serveur de socket. Cette requête, il peut en voir le formatage en sniffant et "décoder" ainsi la logique du développeur avec un peu d'habileté. A la limite cela ce n'est pas grave. Par contre, à partir du moment où il peut faire le pont lui même au serveur et envoyer une requête, là ca devient extrêmement dangereux. Certes le policy file est sensé protéger contre ca s'il est bien construit mais bon Flex et Flash donc ne sont pas réputés pour leur sécurité

Voilà en gros une de mes inquiétudes

[berceker united]

Personnellement, je rentrerais pas dans ce chemin là concernant les technologies client serveur. Il faut y placer un minimum de sécurité mais il y a un moment ou il faut utiliser les éléments déjà existant. Peur de se faire sniffer les trames HTTP, alors la réponse est le HTTPs qui va donner plus de mal. Car d'un coté, cela permet de se concentré plus sur son but que les risques possible. Pour avoir travaillé sur la sécurité coté PHP je peux vous dire que le risque de fermer la porte et laisser la clé de l'autre coté est très vite arrivé. Là ou j'ai travaillé c'est qu'il y avait une équipe chargé de s'occuper du développement et de l'autre coté la sécurité. Ceci parce que bien souvent le développeur laissait vagabonder son esprit sur la sécurité et perdait sa tâche principale et de ce faite, la sécurité était encore pire que s'il y en avait pas. Bref, la sécurité je la compare à une chimiothérapie. On utilise la chimiothérapie pour guérir entre autre d'un cancer mais d'un coté le système immunitaire est tellement abaissé.

[alain31tl]

Bonsoir,

Je reviens sur ce sujet, si tant est que le système d'identification soit fiable et sécurisé.
C'est un minimum, mais c'est aussi ce que l'on recherche.
Et si on est convaincu par sa pertinence, tout est possible sans trop se poser de questions pour la suite.
Ce qui me surprend, c'est qu'il n'y a jamais de souci lorsqu'on envoie par POST des identifiants (login & pass).
Tiens donc !
Quelqu'un a déjà réussi à intercepter votre log ou pass ? et pour l'exploiter à votre place ?
Moi, jamais.
Et ceci même avant d'être migré vers un support https.

Ensuite, pour en revenir au système de session php ( non cookies), l'originalité est que l'on peut mettre en session une multitude de variables.
10, 100, 1000, et sans limites à contrario des méthodes GET ou POST.
Elles peuvent être écrasées et/ou remplacées à chaque changement d'état depuis le poste utilisateur.
L'intérêt réside simplement dans la communication unique serveur/client.
Et si aucune session n'est initialisée en amont (poste navigateur client), pas de communication.
Ce qui signifie aussi que les données serveur/client unique ne peuvent être interceptées, dieu merci.

Ceci dit, pour appuyer le fait que le binaire ou pas, n''est qu'une question de choix ou de confort, mais qui ne répond qu'aux problèmes de temps de réponses.
Et à mon avis, ce n'est pas une question propre à la sécurité.

[berceker united]

Mmhhh, je suis pas aussi confiant que tu l'ais avec les sessions. Certes, tu t'es peut être jamais fais intercepter l'identifiant et mot de passe. Mais peut être que tu ne le sais pas ou que tu n'as pas été victime.
Pour information, les sessions peuvent être facilement piratable si le serveur est mal sécurisé. C'est simple, les variables mis en session sont en faite placées dans un fichier dont le nom correspond à l'id de la session. Si quelqu'un accède à ce répertoire, c'est la bamboula party. il y a d'autre moyens mais c'est pas le sujet.

Pour en revenir au sujet principal, binaire ou pas binaire. Je suis conscient et je prend le partie que l'utilisateur peut attendre à la seul condition qu'ont lui fait comprendre qu'il y a une notion de temps à prendre en compte. Pour l'instant je débute et j'ai personnellement pas envie d'aller sur du complexe. Déjà que les webservices n'ont pas l'air de vouloir fonctionner chez moi