Discussion :

[chikhare]

Bonjour,

Je dois évaluer et choisir les technos qui pourront résoudre au mieux ma problématique dans le cadre de mon travail.

Je vais commencer par poser mon problème dans le domaine du décisionnel. Pour un client, je dois fournir un applicatif de type API (dll en C) qui sera utilisé sur son site web (qui proposera en plus d'autres services en sus de ceux fournis par notre API). Au passage, cette API sera protégé par un dongle physique et vendue pour un nombre maximum de connexions simultanées. Vous l'aurez surement compris, mon problème consiste à gérer le nombre de connexions simultanées en évitant que mon client ait la tentation de tricher!!!

Pour résumer le fonctionnement du futur site web, l'internaute accède au site web avec ou pas un "username" et un "password" (IHM conçu par un tiers et surement en ASP.NET). Le serveur web fait une requête à notre API qui lui octroie un jeton de licence pour une temps donné (TIMEOUT). Le serveur effectue autant de requêtes qu'il souhaite tant qu'il y a encore des jetons disponibles.
Pour un utilisateur connecté, le serveur envoie à notre API l'action que l'utilisateur souhaite effectuer ainsi que le "handle" de son jeton. En fonction de la validité du jeton (TIMEOUT atteint ...) notre API renvoie le résultat au serveur qui se charge de l'afficher en fonction de l'IHM.

Vous l'aurez compris, il serait assez aisé pour le concepteur du site web de demander un jeton, de le mettre en variable globale (donc accessible à toutes les sessions) et de leurrer notre API. Ainsi 200 utilisateurs pourraient utiliser notre API avec le même jeton de licence alors que le licence de notre API n'est valable que pour 50 connexions simultanées (en fait il n'en verrai qu'une dans le cas précis).

Tout en conservant l'API sous la forme d'une DLL en C, je ne vois pas trop comment faire pour résoudre mon problème.

J'ai tout d'abord penser à développer une IHM (à intégrer dans le site WEB) sous la forme d'une application RIA (silverlight, java ou autre). Cette dernière communiquera directement avec notre API stockée sur le serveur web. Bien-sur, cette application devra avoir son code illisible pour le concepteur du site web.

Q1: est-ce une idée qui tient la route?

Q2: Est-il possible à partir de l'application RIA (exécutée en local chez l'utilisateur si je ne me trompe pas) d'accéder à notre API stockée sur notre serveur? Si oui, par quelle(s) techno(s)?

Q3: avez-vous d'autres solutions à me proposer?

Jusqu'ici, nous n'avons développé que des applications Desktop dans le décisionnel. Et pour le compte de notre nouveau client, une version allégée et web de nos applications est nécessaires. Attention, rien à voir avec du cloud. En gros, nos applications Desktop servent à produire des modèles mathématiques et l'API web sert à l'exploitation de ces modèles.

De plus j'ai une autre problématique encore plus tordu!!! Notre API devra surement communiqué avec une deuxième API situé sur un deuxième serveur distant (genre enfermé dans un coffre fort et connecté à une base de données payante) pour effectuer des requêtes, récupérer les résultats et le retransmettre à l'utilisateur à l'origine de la commande.

Je ne sais pas si je suis clair, ni si ce forum est l'endroit adéquat pour ma question.

Merci par avance pour vos réponses.

Bonne journée.

[chikhare]

J'avais aussi posté ce message dans le forum ASP.NET et j'ai obtenu des réponses qui m'ont permis de mettre en place une solution prototype concluante.


La solution que j'ai trouvé (merci npuzin au passage) est la suivante:
Une connexion client se connecte au serveur web et via l'IHM définit une requête. Le serveur web envoie la requête à un composant .NET (DLL développée par mes soins). Ce composant récupère les infos sur le contexte de la connexion cliente (httpcontext) et l'envoie avec la requête vers mon API propriétaire. Cette dernière, avec les infos sur le contexte de la connexion cliente, va créer un jeton de connexion unique (lié à la connexion cliente et ce uniquement lors de la première requète) et si le nombre de connexion max n'est pas atteint traitera la requête client. Le jeton est attribué à cette connexion client jusqu'au moment où elle est fermé (session close) et que le jeton ait été utilisé un minimum de temps. Si la connexion cliente renvoie une nouvelle requête, mon API la traitera si le jeton est toujours valide.

J'espère que j'ai été clair. Le plus dur arrive Ah oui, juste pour info, le site web est développé par mon client (ou son intégrateur attitré).
Imaginons qu'un client 1 se connecte le serveur web (contexte_http_1) et qu'un client 2 se connecte aussi (contexte_http_2). Le concepteur du site peut-il modifier (à travers ses pages en ASP) le contexte du client 2 pour qu'il possède les mêmes valeurs que le contexte du client 1 (contexte_http_1=contexte_http_2)??

Vous l'aurez bien compris, mon client utilisera un seul jeton au lieu de deux!!!!

Autre question, le concepteur du site web peut-il créer un contexte http virtuel (en variable globale???) et l'utiliser en lieu et place du contexte http de chaque utilisateur?? Et là, c'est pas un jeton au lieu de deux. Mais un au lieu de quelques centaines voir plus???

Merci pour les éventuelles réponses.

Merci.

[mon_nom_est_personne]

Non c'est tout a fait clair (enfin pour moi) et rien de tordu on fait ca aussi au taff. Un architecture 3-tier; le tier web qui est le cirque ou celui d'un autre, 2eme tier c'est filtre les requetes, decide de qui en faire etc... et le 3eme tier ... n'a meme pas acces a internet, le 2eme tier accede au 3eme via le reseau local.

1.Ca tiens la route mais concernant la securité ca va etre dur, car tu ne contrôles pas ce qui se passe entre l'utilisateur et le 2eme tiers. C'est comme si tu avais un "man in the middle" constament. D'un point de vu general, je dirais que la solution serait dans ton api sur le 2eme tier de generer le code "vue" comme les formulaires, les graphs etc...

2.Elle supporte toute les diverse protocole rest, soap etc.. donc pas de souci a ce niveau la. Le probleme d'un flash, silverlight etc... fixe a integrer, c'est qu'il existe des decompilateurs. Si ton client veux tricher, il le pourras tout de meme.

3. si tu compiles 1 et 2, un solution serait d'au lieu retourné un jeton au client, tu retourne l'interface complete avec le jeton ecrit en dure dedans.
Par exemple, flash. Le compilateur flex (http://labs.adobe.com/wiki/index.php/Flex_3) est open source etc.... Tu peu donc imaginier le senario suivant/
- le client effectue un requete une requete initiale
- Ton serveur traite la requete, inclue le jeton en dur dans le mxml, le compile et renvoie soit le flash en lui meme ou un URI.
- le client affiche le flash
- Seul le flash peut communiqué avec l'API

En esperant que ca peut t'aider,

[chikhare]

Merci mon_nom_est_personne.

Je t'avouerai que je n'ai pas tout compris. Je vais vite résumer.

Si je reprend ton idée d'architecture 3-tiers, le 1er tier serait le client sur internet avec son browser. Le 2ième tiers serait le serveur web et le 3ième serait mon API? Right?

Si c'est le cas, alors le serveur web ne peut pas accéder à mon API (3ième tiers) directement. Il ne peut le faire qu'au travers d'une DLL.NET qu'il sera obligé de charger dynamiquement. De plus, cette DLL est cryptée et protéger par un dongle physique. Donc pour le décompiler, il va y passer beaucoup de temps

Je ne renvoie pas de jeton vers le 2ième tiers. Et je ne pense même pas le faire avec ma propre DLL.NET installée sur le 2ième tiers. Tout restera au niveau de mon API (3ième tier).

Dans mon composant que devra utilisé le 2ième tiers (DLL.NET) aura accès au contexte de la session http. Et ma question portait sur fait de savoir si ce contexte pouvait être falsifié!!

Merci pour ta réponse.

[mon_nom_est_personne]

pour une définition d'une architecture 3-tiers cf. http://fr.wikipedia.org/wiki/Architecture_trois_tiers (dans notre cas le 3eme tiers n'est pas la bdd mais la machine a calcul).Si c'est ma faute, j'avais compris que le DLL serait sur un serveur et non un composant a mettre sur le serveur web.
Toujours est-il, une requête http n'est rien d'autre qu'un fichier texte formater d'une certaine manière.... oui très facile à falsifier.

Je pense sincèrement que de refiler le dll a tes clients pour eux utiliser l'api est dangereux car ils peuvent se mettre très facilement entre le dll et sa requête vers ton serveur d'application (ce que t'appelle ton API).

Je pense que tu as tout à fait intérêt à mettre ton DLL sur un serveur autre que ton API et faite communiquer le site web uniquement avec le serveur ou se trouve le dll. De ce fait il ne sais pas qu'il y a un 3eme serveur, et ca deviens un peu plus ardu a tricher. Tu y gagnera aussi en flexibilité car si demain le tier web n'utilise plus .net; disons java, php etc... t'es obligé de réécrire un équivalent du dll dans le nouveau langage.