ActionScript: Socket.writeUTFBytes ne marche pas

Pendant de nombreuses heures, j’ai chercher à faire marcher les Sockets d’ActionScript. Ceux-ci ne marchaient pas, alors que le policyfile était chargé, il y a avait même un socket policy file server de mis en place, et le policyfile.txt ne m’affichais que des résultats positifs. Encore plus impressionnant, le socket créait une connexion mais les différentes commandes que je souhaitait envoyer ne passaient pas… C’est pourquoi, au bout d’un moment, j’ai utiliser Wireshark pour analyser les différents paquets envoyés. C’est avec celui-ci que j’ai pu voir que uniquement des paquets ACK et SYN étaient envoyés entre le client (via le Flash) et le serveur (socket). Ceux-ci étaient responsables de la connexion établie.

Seulement, les paquets réseau PSH (pour Push) qui envoient les commandes n’étaient pas créés, pas même de paquets déformés contenant mes commandes. Je suis sur Ubuntu 64bits, avec un Flash Player 10, version débuguage 32bits. Donc, un petit essai sur Ubuntu 32bits avec le flash player “basique”, et… miracle, ça marche ! Windows XP, ça marche !

En fait, mon code marchait depuis longtemps mais, pas de bol, ma version du Flash Player est bugguée avec les Sockets… Par conséquent, lorsqu’il se passe des choses comme ça, essayez avec d’autres versions, d’autres environnement car il arrive que se ne soit pas votre application qui soit bugguée mais une autre ! 😉

facebooktwittergoogle_plusredditpinterestlinkedinmail

Les interfaces en ActionScript 3

L’utilisation d’interfaces produit du code à écrire en plus, et surtout à maintenir ! Néanmoins, elle sont extrêmement pratiques lorsque vous utilisez plusieurs classes qui représentent quelque chose de visuel ou qui doivent savoir faire plusieurs actions, qui ne sont pas forcément écrites de la même manière ou qui n’utilisent pas le même support (exemple: un gestionnaire de sauvegarde – il peut y en avoir une classe pour sauvegarder dans PostgreSQL, une pour MySQL, une pour XML mais qui utilisent la même interface car doivent supporter les fonctions insert, update et delete par exemple). Bref, dans ces cas là – ou pour garantir une extensibilité et une réutilisabilité importante -, pour être sûr que votre classe contient bien les bonnes fonctions, il est préférable d’utiliser des interfaces.

En ActionScript, le comportement des interfaces est le suivant:

  • Vous devez les définir dans package
  • Vous devez lister toutes les fonctions (supposées publiques) que la classe doit avoir, sans préciser leurs types (public, private, protected…)
  • Une fonction est définie par son nom, ses paramètres et sa valeur de retour
  • Une interface peut étendre une autre interface en utilisant extends
  • Une classe peut implémenter une seule interface, en utilisant implements

Continue reading Les interfaces en ActionScript 3

facebooktwittergoogle_plusredditpinterestlinkedinmail

Sockets avec Flash: Un serveur pour les “master socket policy file”

Depuis la version 9,0,125 de Flash Player, toutes les connexions à l’aide de Sockets font objet de mesures de sécurité supplémentaires. Dorénavant n’importe quelle connexion utilisant les Sockets devront être explicitement autorisées par le serveur vers lequel la connexion Socket s’effectuera pour le serveur hôte du ficher SWF. C’est-à-dire que, par exemple, si vous hébergez votre fichier Flash (.swf) sur le domaine static.example.com et que la connexion se fait sur le port XX du serveur socks.examples.com, alors il faudra créer un socket sur le port 843 qui retournera le fichier de sécurité (de la même forme de les crossdomain.xml que l’on connait pour les URLs), appelé le “master socket policy file”.

Cette contrainte est apparue depuis la version 9 de Flash Player, et est néanmoins moins restrictives sur ces versions car l’on peut utiliser les Security.loadPolicyFile() pour charger des fichiers de sécurité pour les sockets, alors que dans les versions 10, il faudra un “master policy file”.

C’est pourquoi, il faut dès à présent mieux d’implanter cette fonctionnalité sur votre serveur en créant simplement un petit deamon sur le port 843 qui retournera le fichier de sécurité lors de la requête <policy-file-request/> suivie d’un caractère NULL. Si vous souhaitez créer votre propre “master socket policy file”, faites-le, vous pouvez le faire dans presque n’importe quel langage. Seulement, un développeur de Adobe (société éditrice de Flash) propose un script en Python et en PERL. Nous allons voir comment installer le script PERL, langage qui est installé sur quasiment tous les serveurs, sans même que l’on ne l’ai forcément installer.
Continue reading Sockets avec Flash: Un serveur pour les “master socket policy file”

facebooktwittergoogle_plusredditpinterestlinkedinmail

I2C (IP-to-Country): Gestion des comptes utilisateurs

La récupération des données depuis I2C vient de changer. En effet, dorénavant il vous faudra vous authentifier à l’aide d’un compte client D-Sites avant la récupération du pays d’une adresse IP.

La page du projet i2c à été mise à jour.

Pourquoi ?

Ce système à été mis en place pour lutter contre les utilisations abusives (plusieurs centaines de milliers de requêtes par mois) de I2C.

Qu’est-ce que ça change ?

Pas grand chose, le code de récupération change un peu, rien de bien méchant. Seulement, maintenant, le nombre maximal de requêtes est de 50 000 requêtes par mois. Si vous souhaitez en faire plus, c’est tout à fait possible en payant un peu (quelques euros): 100 000 requêtes (1€), 500 000 requêtes (4€) et 1 000 000 requêtes (7€). Pour plus de requêtes contactez-moi.

Comment ?

Pour créer un compte client D-Sites vous devez vous inscrire sur le site puis aller dans l’administration, où vous trouverez un menu “Compte D-Sites”. Ce menu concerne le compte client D-Sites qui vous permettra de vous identifier au près de tous les services de D-Sites. Une fois créé, activez-le pour i2c dans le sous-menu correspondant. C’est bon, vous pouvez vous connecter avec les identifiants choisis.

Concrètement, le code à mettre en place change pour HTTP et SOAP:

Pour HTTP

Vous devez ajouter les paramètres URL u et p décrivant respectivement le nom d’utilisateur et le mot de passe.

Pour SOAP

Si vous utilisez SOAP, vous avez deux options: soit vous utilisez la fonction login qui prend comme paramètres le nom d’utilisateur et le mot de passe avant getCountry, soit vous utilisez la fonction getCountryLogin qui prend dans l’ordre l’adresse IP, le nom d’utilisateur et le mot de passe.

En espérant améliorer la qualité du service.
Cordialement, Samuel ROZE.

facebooktwittergoogle_plusredditpinterestlinkedinmail