Tynambule

Wouah, quel titre à rallonge. J’ai posté aujourd’hui un petit message sur Mediabox sur une question qui me parait sans réponse (satisfaisante) pour l’instant, et je la mets ici aussi histoire de poster un peu, pasque ces temps-ci, je m’oublie un peu sur ce blog. ^^

Salut les gens,

J’ai une question assez pointue sur la gestion de la sécurité par le Player Flash, avec un peu de bol quelqu’un se sera déjà cogné les dents là dedans. ^^

Voici mon soucis. J’ai deux fichiers SWF executés depuis une installation locale dans un dossier listé dans le répertoire FlashPlayerTrust: le « maître » et un « esclave ». Le « maître » est executé par l’utilisateur. Lors de l’execution de ce dernier, j’aimerais pouvoir charger mon SWF « esclave » et executer du code AS3 placé à l’interieur.

Mais voilà la petite difficulté: le fichier SWF « maître » est une application de confiance (vu que c’est moi qui la code). Les utilisateurs ne peuvent pas la modifier (enfin, ce n’est pas le débat). Elle communique via un Socket avec un serveur distant, et accède à certains fichiers en local ainsi que sur le Web. Jusque là, pas de soucis.

Seulement, mon SWF « esclave », ce n’est pas moi qui le code, c’est des utilisateurs tiers qui n’ont pas toute ma confiance. J’aimerais laisser le code AS dans les SWF « esclave » accéder à certaines parties bien définies d’une API pour permettre la personnalisation de mon application « maître ». Pour cette partie, pas de soucis.

Mais là où ça se corse, c’est que je ne veux pas que les SWF « esclave » produit par des tiers puissent constituer des chevaux de troies. En clair, je ne veux pas qu’ils puissent communiquer avec l’extérieur, via un socket ou des appels à une page http distante.

Il n’y a à ma connaissance pas de moyen de charger un SWF dans une sandbox particulière, je ne peux donc pas bloquer mes SWF « esclave » dans une sandbox Local-with-file.

Je vois deux solutions possibles :

* Ne pas utiliser des SWF avec de l’actionscript. Créer un pseudolangage, et le parser/executer depuis mon SWF « maître ». Ca peut marcher, mais c’est long, pénible et source de bugs, pouvant même ouvrir des failles de sécurité.

* Charger le SWF « esclave » deux fois: une première fois en tant que donnée binaire, pour parser le format de fichier swf et récupérer les tags de bytecode, puis pour parser ce bytecode à la recherche d’appel à l’API Flash bloqués (l’utilisation d’une classe socket, ce genre de trucs). Mais là, le soucis, c’est que si Adobe change une virgule dans son code et modifie d’un poil le bytecode, paf, une faille. Pareil, si un méchant codeur tiers modifie son swf de façon à ce que la signature de sa classe socket soit légèrement différente, mais qu’elle continue à fonctionner pour le player (en admettant que ce soit possible), paf, feinté. Et en plus, c’est long et compliqué à développer.

Donc voilà, ça me parait être un problème insoluble mais sait-on jamais. Avez-vous une idée meilleure que les miennes? ^^

Merci d’avance!

Alors, fidèle lecteur, as-tu une solution? Allez, salut.

Il y a quelques semaines, ma très chère compagne m’a pressé pour que nous fassions l’acquisition d’une de ces merveille technologique de l’électroménager qui me font douter de l’avenir de l’usage des mains de notre humanité modernisée : une machine à pain. En solde.

Le principe est simple : on remplit une petite cuve en inox avec différents ingrédients dans un certain ordre (comme de l’eau, du beurre, du sucre, du sel, de la farine et de la levure), on choisi une programme concordant avec notre recette, et la machine s’occupe de tout : elle pétri la pâte de son petit bras mécanique, longuement, elle la laisse reposer et gonfler dans un environnement moite et chaud, puis elle la cuit en faisant rougir son petit corps de chauffe.

Sur le papier, c’est génial : on peut même la programmer pour avoir du pain chaud au réveil. Dans la réalité, je pense que je dois être le cuisinier le plus naze de toute l’histoire de la machine à pain. Sur mes nombreux essais (avec différentes farines, différents temps de cuisson, et même un sachet de farine « toute prête avec déjà la levure spécialement pour votre machine à pain que même un manchot pourrait réussir »), j’en reviens toujours au même point : le pain en forme de brique, à la couleur de brique, et surtout, à la densité d’une brique.

Imaginez un cube (et encore, c’est beaucoup dire, 10cm sur 10 de base (c’est la forme de la cuve), et 6 ou 7cm de haut, 12cm dans les meilleurs jours), brun foncé, la croute comme une muraille de Chine acérée de piques, la mie comme un annuaire téléphonique édition Île-de-France. Pour mieux visualiser, ce soir, j’ai failli à la recommandation de toute mère à son enfant lorsqu’il se munit d’un couteau à pain : Fait attention à ne pas te couper !. Et je me suis ouvert le puce. Avec le pain. Un morceau de croute particulièrement aiguisé s’est plantée dans mon doigt jusqu’au sang.

Bref, je crois que le dépôt du tablier s’impose. Mais pas avant d’avoir rentabilisé cette démoniaque machine et son packaging à base d‘inratable et de sans échec, non mais. Je suis peut-être un loser de la baguette, un vaincu de la miche, mais tant pis. Allez, salut.

Un ami et néanmoins collège m’a fait découvrir ce matin un chef d’oeuvre de contre productivité que je vais exorciser avec vous afin de me remettre à bosser : XKCD, a webcomic of romance, sarcasm, math and language.

Plus : C’est par ici !

En AS3, on peut faire un chouette truc tel que décrit dans le billet sur les balises embed, à savoir ceci :

package net.tynambule.exp {
	import flash.display.Sprite;
	[Embed(source="assets/test.swf", symbol="test")]
	public class PrivateEmbed extends Sprite
	{
		public function PrivateEmbed()
		{
		}
	}
}

(Pour les détails, se référer au billet sur la métadonnée embed.)

Maintenant, imaginons que dans notre symbole « test », on aie un TextField qui se nomme « _tfFoo« . Dans notre classe décrivant ce symbole, on en aura certainement besoin. Tout naturellement, je l’aurais ajouté en faisant :

package net.tynambule.exp {
	import flash.display.Sprite;
	import flash.text.TextField;
	[Embed(source="assets/test.swf", symbol="test")]
	public class PrivateEmbed extends Sprite
	{
		internal var _tfFoo : TextField;
		public function PrivateEmbed()
		{
		}
	}
}

Sauf qu’en fait non. Si on fait ça, le compilateur gueule :

 ReferenceError: Error #1056: Impossible de créer la propriété _foo sur net.tynambule.exp.PrivateEmbed. 	at flash.display::Sprite/flash.display:Sprite::constructChildren() 	at flash.display::Sprite$iinit() 	at net.tynambule.exp::PrivateEmbed$iinit()[Y:\Code\Workspace\Exp\src\net\tynambule\exp\PrivateEmbed.as:11] 	at net.tynambule.exp::PrivateEmbedContainer$iinit()[Y:\Code\Workspace\Exp\src\net\tynambule\exp\PrivateEmbedContainer.as:12]

Pourquoi? Parce que les éléments placés sur la scène dans un symbol embed ne sont pas internal (ni private, ni protected), mais… public. Ce qui m’oblige à réécrire :

public var _tfFoo : TextField;

Et là, ça marche. Sauf que moi, j’aurais bien aimé que mon joli TextField ne soit pas accessible depuis n’importe où dans mon code, vu que je préfère quand l’interface est planquée dans son coin et qu’elle n’a rien à voir avec la logique.

Voili voilou, c’est pas très joli et c’est un peu prise de tête de piger pourquoi ça foire. J’me demande pourquoi Adobe a fait ça. Snif. Allez, salut.

Comme vous le savez peut-être, je travaille en ce moment chez Ankama comme responsable du client de Dofus (site web), un MMORPG flash-based acceuillant plus de 80’000 joueurs en simultané en heure de pointe. Ces derniers temps, de très gros projets ont été lancés, et le manque d’effectif se fait ressentir plus que jamais.

J’ai pu constater dans les dernières semaines à quel point il est difficile de trouver des flasheurs en ce moment. À croire qu’on ne pousse pas sous les sapins (ha ha ha). De nombreuses annonces ont été publiées à de nombreux endroits (forums Flash, site d’annonces d’Ankama, etc), et pourtant, c’est la galère. Je m’imaginais que la tâche ne serait pas bien compliqué, étant donné la renommée d’Ankama et de Dofus dans le monde des flasheurs francophone, c’était une erreur.

Je m’adresse donc à vous, amis lecteurs. Si vous recherchez un boulot passionnant, à la pointe de la pointe de la technologie Flash (que je sache, aucune team ne repousse les limites de Flash aussi loin que la notre, dans le monde entier), très (parfois trop) prenant, au sein d’une équipe chaleureuse, acceuillante et pleine de gens super sympas (normal, j’y suis), n’hésitez pas : POSTULEZ !

Voici l’annonce :

Votre rôle: Développeur Flash Actionscript 3
Domaine d’activité: Jeux vidéo / MMORPG / Développement

Missions:
Dans le cadre d’un projet de MMORPG de nouvelle génération, le groupe ANKAMA recherche un développeur Flash AS3. Vous travaillez au sein d’une équipe à la pointe du développement de jeux vidéo forte de son expérience sur DOFUS, et réalisez des implémentations concrètes et des nouveaux systèmes et moteurs pour le projet.

Profil recherché:
- Rigueur, autonome, esprit d’équipe;
- Excellente connaissance de l’ActionScript 3;
- Bonne connaissance de l’ActionScript 2 exigée;
- Rapidité, efficacité et organisation;
- Expérience dans la programmation Flash/Flex (site, application, jeux);
- Expérience dans le monde du jeu vidéo souhaitée;
- Bonne connaissances de l’univers Flash;
- Des notions d’autres langages de programmation sont un plus (Java, C#, C++, SQL, PHP, etc).

Postes à pourvoir: 2

Période: Dès maintenant
Type de contrat: CDI
Lieu: Roubaix (59100)
Rémunération: entre 20k€ et 30k€ par an ( Selon profil ).
Contact: Samuel Lorétan (C’est moi, n’ayez pas peur, il n’y a pas de vilain DRH entre nous.)

Pour répondre à cette offre, veuillez envoyer un mail à jobs@ankama.com (ou directement à tyn@ankama.com si vous êtes timide !) en précisant la référence GAMES-DEVAS3-JOB. Joignez une lettre de motivation, un CV, et un moyen de consulter vos différents travaux.

Allez, n’hésitez plus. Ca pète de bosser ici. Allez, salut.