[arthurdebx]

Bonjour à tous je voudrais savoir si les fichiers externes .as sont fiables. C'est à dire que si je met les bons chmod, les utilisateurs de mon animation .swf ne pourrons pas lire le fichier externe .as?

Et si une personne fait une animation .swf essayant de charger le fichier externe .as, est-ce que cette animation pourra utiliser mon fichier .as?

Merci d'avance pour vos réponses.

[SStephane]

Les fichiers .as sont compilés dans l'animation, tu ne peux pas les charger comme des librairies externes.

Edit : il est possible de décompiler les animations flash et de récupérer les .as, évite donc d'y mettre des sources que tu souhaites masquer.
Sinon il sont fiables...oui, autant que flash, pas plus pas moins que ton animation.

[arthurdebx]

Et est- ce que vous connaissez une astuce pour pouvoir justement mettre du code as quelque part qui ne doit justement pas être vu?

Je pensais qu on pouvais utiliser un fichier .as comme une classe et s en servir dans son swf sans que les utilisateurs, même en décompilant, puisse y avoir accès.

Ce message a été modifié par arthurdebx - 02 mars 2010 - 15:30.

[SStephane]

Utiliser un script serveur, aucune autre solution.
Il existe des "brouilleurs de code", mais bon autant faire avec aspnet php et consort.

AMFPHP fonctionne très bien soit dit en passant.

[arthurdebx]

SStephane, le 02 mars 2010 - 15:34, dit :

mais bon autant faire avec aspnet php et consort.

C est quoi consort?

Mais le problème est que les données entre un swf et un fichier php sont facilement interceptables donc je vois pas comment faire.

On m' a dis que il était presque impossible d intercepter des données qui transitent via des sockets est-ce vrai?et faut-il crypté les informations quand même?

Le souci est que si il faut quand même crypter, alors il faut bien stocker la clé dans le swf... et donc je reviens à mon point de départ.


Par ailleurs, j'ai lu qu'il était plus difficile de récupérer un swf si celui ci était charger dans un autre, c'est une bonne solutions?

Merci

Ce message a été modifié par arthurdebx - 02 mars 2010 - 16:16.

[SStephane]

arthurdebx, le 02 mars 2010 - 16:16, dit :

C est quoi consort?

N'importe quel langage qui s'exécute sur ton serveur.

arthurdebx, le 02 mars 2010 - 16:16, dit :

Mais le problème est que les données entre un swf et un fichier php sont facilement interceptables donc je vois pas comment faire.
On m' a dis que il était presque impossible d intercepter des données qui transitent via des sockets est-ce vrai?et faut-il crypté les informations quand même?

Pas plus, pas moins que n'importe quel transfert non-crypté a priori. DTF ton swf est là pour afficher du contenu, donc tu n'affiches que du contenu, tu traites les infos côté serveur et c'est plié.

arthurdebx, le 02 mars 2010 - 16:16, dit :

Le souci est que si il faut quand même crypter, alors il faut bien stocker la clé dans le swf... et donc je reviens à mon point de départ.

Non puisque tu calcules tout côté serveur, après rien ne t'empêches d'utiliser une protocole crypté dans flash (une requête http par exemple).

arthurdebx, le 02 mars 2010 - 16:16, dit :

Par ailleurs, j'ai lu qu'il était plus difficile de récupérer un swf si celui ci était charger dans un autre, c'est une bonne solutions?

Faux, ou à peine plus

[arthurdebx]

Un grand grand merci à vous.

Citation

Non puisque tu calcules tout côté serveur, après rien ne t'empêches d'utiliser une protocole crypté dans flash (une requête http par exemple).

Pourriez vous me donnez d'avantage d'informations à propos de cette requête HTTP?

Je ne vois absolument pas comment je peux m'y prendre pour envoyer des informations cryptées du flash vers le serveur sans stocker une clé dans mon swf.

J' avais prévu d'utiliser des sockets pour envoyer mes informations.Est-ce vraiment utile? Me conseilleriez vous une autre méthode?

[SStephane]

Et bien, tu effectues une requête vers une page https à partir de flash avec les trucs standards : URLRequest etc.
Tu peux aussi héberger une appli AMFPHP avec SSL : je te renvoie vers cette page ou tu pourras en constater la simplicité d'utilisation : http://www.amfphp.or...tingamfphp.html

Tu forces https si ton appli a de gros besoin en terme de sécurité. La phrase sur le site résume bien ce que je t'ai dis précédemment : "Don't store anything sensitive on the client-side or send useless sensitive data"

[arthurdebx]

Super!

Et donc avec SSL, mes utilisateurs ne pourront pas voir ce que le swf envoie au serveur? Et ils ne pourront pas envoyer de fausses informations?

Je suppose donc que je vais devoir demander à mon hébergeur de m'installer une connexion SSL?

Je sais que je suis casse - tête mais vu que je cherche depuis longtemps et que vous avez enfin trouvé, je voudrais être sûr de ce que je vais faire...

Merci

[SStephane]

C'est pour faire quoi exactement ?

[arthurdebx]

Il faut que j"envoie le score d'un jeux vers mon serveur tout simplement.

Seulement je doit être sûr que personne ne peut modifier les données envoyées et que personne ne puisse envoyer des informations par un autre moyen.

Merci

[SStephane]

Dans ce cas amfphp est très bien, sécurise au maximum la méthode qui recevra la requête (avec une session php par exemple), et oublie SSL, honnêtement, ça ne sera pas très utile.

[arthurdebx]

Citation

sécurise au maximum la méthode qui recevra la requête (avec une session php par exemple)

A ce propos, je voudrais savoir si lorsque mon swf envoie une requête http vers une page php, cette page php sait vérifier que cette requête provient d un swf d' une page qui contient une session php?

J'espère que j' ai été clair

Et si oui, est-il possible qu'un client change son id de session ou arrive à simuler une session sans que mon serveur l'ai fait?

Merci

[SStephane]

Je t'avoue que je ne sais pas si la session sera transmise dans cette requête, je dirai que non... essaie donc, si elle est transmise autant l'utiliser. Mais rien ne t'empêche de stocker des couples session/ip et d'envoyer une chaine que tu décrypteras côté serveur.
Ca devrait largement suffire.

[arthurdebx]

Si je fais passer le couple id session/ip au swf, le client pourra changer cela comme il veut non?

Et même le copier pour le transmettre via une application qu'il aura crée lui même et donc il pourra envoyer de fausses données...non?

Je vais faire un test pour voir si la session est envoyée avec une requête depuis un swf.

Merci

[SStephane]

Ou ai-je écrit qu'il fallait le passer que par le swf ?

Certes tu posteras des variables dont l'id de session par le swf, mais il faudra que cette session soit déjà présente dans ta base comme une session véritable... ça change tout, comme ça je vois pas trop comment usurper le système, l'ip n'est d'ailleurs qu'un bonus, et largement plus difficile à spoofer.

[arthurdebx]

Y a moyen de connaitre l'id de session php directement dans le swf?

Je commence à me noyer un peu dans tout ca

Si vous pouviez m'expliquer étape par étape ce qu'il va se passer pour que j y voie un peu plus claire ce serait super sympa

Merci

PS : Je me demandais aussi si la session était aussi active sur un autre navigateur du client?

Ce message a été modifié par arthurdebx - 04 mars 2010 - 21:18.

[SStephane]

Non tu passes la session en flashvars (ainsi que l'ip, personne ne t'interdit de hasher le tout dans la page), tu les auras préalablement stockée sur ton serveur en php.

Quand le flash postera les résultats, il postera tes valeurs+l'id de session(*)+l'ip(*)

(*) = hashé au besoin.
La page qui reçoit les résultat vérifie que l'id de session & l'ip sont présent dans ta base avant d'enregistrer les données.

Quant aux navigateurs non, une seule session par navigateur.

[arthurdebx]

Citation

Quand le flash postera les résultats, il postera tes valeurs+l'id de session(*)+l'ip(*)

Mais donc quelqu'un pourra altérer les données puisque mes valeurs sont transmissent par post...non?

Merci

[SStephane]

Je suis navré mais je peux pas être plus clair mis à part le faire à ta place. Oui tes variables peuvent être altérées dans un flash (comme dans n'importe quelle page web).

Tu stockes donc les sessions (les vrais) pour vérifier pour t'assurer que les données transmises proviennent d'une session qui existe. Et si l'id de session transmise au flash est hashée (flashvar), c'est mieux mais carrément pas essentiel dans la mesure ou tu ne gères pas des comptes en banque (pareil pour SSL), j'exagère un peu mais pas beaucoup.