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.

[npuzin]

Ca n'a pas l'air simple.

Si j'ai bien compris vous deployez votre API en C qui sera utilisee par le site web du client, et vous voulez vous assurer que leur site web utilise un jeton par connexion, et non pas le meme jeton pour tous les utilisateurs du site.

C'est bien ca ?

[chikhare]

Bingo npuzin!!!

C'est tout à fait ça.

D'un coté, mon client devra gérer ses connexions dans le cas de certains services payants. D'un autre coté, notre API devra donner un jeton de connexion à l'utilisateur qui le demande.

Et donc une fois le jeton donné, le serveur web fait appel à notre API à chaque fois que l'utilisateur effectue une requête ou commande liée à notre API.

[npuzin]

Je ne pense pas que ca soit possible.

Vous devriez facturer en volume de requetes traitees par votre API plutot non ? Ou en nombre de requetes par secondes qqchose comme ca.

[chikhare]

Malheureusement, la licence est de type annuelle pour x connexions simultanées.

En me documentant un peu, je me suis dis qu'une IHM développée par nos soins (exemple en javaFX ou silverlight) communique avec un service web qui lui même interagit avec notre API (via un chargement de la DLL, accès aux méthodes externes...) était peut-être une solution.

Mais le problème est qu'il me semble qu'une service web a son code source ouvert (à l'inverse d'une DLL c native). Bon d'un autre coté, c'est un univers nouveau pour moi et je ne fais donc que supputer.

Je continue de cherche

[npuzin]

Ok inspire de ton idee, je pense que ceci pourrait peut etre marcher, faudrait tester, en supposant que le client a un site ASP.NET :

1) Fournir au client une dll .NET contenant une fonction qui ressemblerait a ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        public int ProcessAPIRequest(string apiRequest)
        {
            try
            {
                string userName = HttpContext.Current.Session["userName"].ToString();
                if (HttpContext.Current.Session["userToken"] == null)
                {
                    HttpContext.Current.Session["userToken"] = GetTokenForUser(userName);
                }
                TheAPI.ProcessAPIRequest(apiRequest);
            }
            catch (MaxTokenUsedException ex)
            {
                // blabla
            }
        }

2) Puis demander au client d'utiliser Assembly.LoadFile() pour charger dynamiquement cette dll et appeller cette methode pour envoyer une requete a votre API.

Tout reside dans le fait que je pense que ta dll aura acces a la session ASP.NET de l'utilisateur, en utilisant HttpContext.Current.Session. A tester.

[chikhare]

Ok inspire de ton idee, je pense que ceci pourrait peut etre marcher, faudrait tester, en supposant que le client a un site ASP.NET :

1) Fournir au client une dll .NET contenant une fonction qui ressemblerait a ca:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        public int ProcessAPIRequest(string apiRequest)
        {
            try
            {
                string userName = HttpContext.Current.Session["userName"].ToString();
                if (HttpContext.Current.Session["userToken"] == null)
                {
                    HttpContext.Current.Session["userToken"] = GetTokenForUser(userName);
                }
                TheAPI.ProcessAPIRequest(apiRequest);
            }
            catch (MaxTokenUsedException ex)
            {
                // blabla
            }
        }

2) Puis demander au client d'utiliser Assembly.LoadFile() pour charger dynamiquement cette dll et appeller cette methode pour envoyer une requete a votre API.

Tout reside dans le fait que je pense que ta dll aura acces a la session ASP.NET de l'utilisateur, en utilisant HttpContext.Current.Session. A tester.

Okidoki. Bon si j'ai bien compris le bout de code, il est possible à partir de la DLL de connaitre le contexte de la connexion http (à savoir paramètres de la session qui appelle mon API)?
La DLL doit être écrite en .NET? Ce n'était pas mon idée initiale et ceci pour essayer d'utiliser du code déjà écrit en C. Mais ce n'est pas un problème.

Par contre, le développeur du site web (qui sera en ASP.NET) peut toujours me leurrer en trafiquant les paramètres de session? non? Par exemple utiliser les vrais paramètres de sessions (username ...) pour ces opérations et m'envoyer un username factif mais identique quelque soit l'utilisateur qui se connecte?

Je sais, je suis parano!!! lol

[npuzin]

Okidoki. Bon si j'ai bien compris le bout de code, il est possible à partir de la DLL de connaitre le contexte de la connexion http (à savoir paramètres de la session qui appelle mon API)?
La DLL doit être écrite en .NET? Ce n'était pas mon idée initiale et ceci pour essayer d'utiliser du code déjà écrit en C. Mais ce n'est pas un problème.

Par contre, le développeur du site web (qui sera en ASP.NET) peut toujours me leurrer en trafiquant les paramètres de session? non? Par exemple utiliser les vrais paramètres de sessions (username ...) pour ces opérations et m'envoyer un username factif mais identique quelque soit l'utilisateur qui se connecte?

Je sais, je suis parano!!! lol

Ca te permet d'acceder a toutes les variables qui ont ete stockees ds la session de l'utilisateur.

Effectivement il y a encore moyen de gruger mais je pense qu'il y a moyen par dessus ca de rajouter des protections.

Genre en utilisant HttpContext.Current.Request tu dois pouvoir recuperer l'IP du client. Alors tu peux crypter le jeton en utilisant l'IP, qqchose comme ca.

[chikhare]

Bonjour npuzin

Merci pour ces renseignements. Pour essayer de bien y voir clair et de bien résumer.

Je met en place une DLL .NET qui sera appelée par le serveur web (écrit en ASP.NET) pour gérer l'attribution ou non des jetons de connexions.

Dans le but d'utiliser du code déjà fait (DLL native en C) et aussi pour des questions de performances (API de calculs mathématiques principalement), est-ce que cette DLL .NET peut ensuite appeler la véritable API (la DLL en C), lui envoyer les requêtes et récupérer les résultats pour les transmettre au serveur web qui se chargera de les afficher?
Ici la DLL .NET agirait comme une DLL wrapper.

Dernière petite question, la DLL .NET n'a rien à voir avec mon idée d'une service web, n'est-ce pas?

Merci.

[npuzin]

Je met en place une DLL .NET qui sera appelée par le serveur web (écrit en ASP.NET) pour gérer l'attribution ou non des jetons de connexions.

Dans le but d'utiliser du code déjà fait (DLL native en C) et aussi pour des questions de performances (API de calculs mathématiques principalement), est-ce que cette DLL .NET peut ensuite appeler la véritable API (la DLL en C), lui envoyer les requêtes et récupérer les résultats pour les transmettre au serveur web qui se chargera de les afficher?
Ici la DLL .NET agirait comme une DLL wrapper.

C'est bien ca. Il est possible en .NET d'utiliser des API ecrites ds d'autres langages avec COM Interop en utilisant l'attribut DllImport dans ton cas je pense.

Dernière petite question, la DLL .NET n'a rien à voir avec mon idée d'une service web, n'est-ce pas?

Oui. Si tu passes par un web service qui serait installe sur une autre machine, tu n'auras pas acces a la session du site web, et donc je ne vois pas comment tu peux forcer le site a utiliser une connexion par utilisateur.

Si le web service est inclu dans le site du client, ca sert a rien d'utiliser un web service.

[chikhare]

Alut,

Encore merci pour toutes tes infos npuzin. Cela m'a permis d'y voir plus clair et de mettre en place un prototype qui s'est avéré concluant.

J'ai crée un site web basique en ASP.NET. Ce site communique avec une DLL .NET qui me permet d'accéder à toutes les infos de sessions. Cette DLL attaque ensuite mon API C qui fait le travail requis.

Primo, le serveur WEB n'a à aucun moment accès au jeton de connexion. Et deuxio, la seule info qu'il m'enverra sera la requête du client. Le jeton de connexion est géré entièrement par l'API et de plus le serveur web ne sait pas quelles infos de session je vais utiliser pour créer le jeton.

Pour les échanges de données (SERVER WEB <-> DLL .NET <-> API), je pensais à un flux XML que chacune des parties devra traiter.

Merci beaucoup.

[npuzin]

Au fait je t'avais dis que tu pouvais utiliser Assembly.LoadFile() pour charger ta dll .NET, mais en fait tu peux tout simplement ajouter a ton site ASP.net une reference a cette dll.

Entre le site ASP.NET et ta DLL .NET tu peux utiliser un moyen de communication plus elabore (objets, liste d'objets, DataTable, etc).

Et du xml entre la Dll et ton API C, comme ca ta DLL joue un peu un role de "traducteur" pour le site ASP.net

Bonne continuation pour ton projet