Webservice : accès concurrentiel, persistance de contexte et authentification

Bonjour,

j'ai créé un Webservice avec WB17 0.78n, les fonctions renvoient du flux XML en fonctions de paramètres. La consommation se passe bien, je récupère bien mon flux.

J'ai cependant plusieurs questions :

1) Accès concurrentiel
a) Si plusieurs applications consomment le webservice en même temps avec des paramètres différents, comment le webservice gère l'accès concurrentiel à ses fonctions ?
b) Ne risque-t-on pas de télescoper le flux XML entre les 2 appelants ?

2) Persistance de contexte
a) J'utilise la persistance de contexte avec DéclareContexteWebservice cependant, jusqu'à quand le contexte d'une variable persiste si l'application consommatrice tourne en permanence et appel le webservice via un timer ? (TimeOut de libération du contexte)

b) Est-ce que l'accès à une variable de contexte est bien spécifique à une "session webservice" ? Par exemple si ma variable de contexte vaut 10 après consommation du webservice par un poste client A, est-ce que je suis certain qu'elle sera remise à 0 si je lis son contenu depuis un poste client B ?
(En effet si je consomme mon webservice j'accède à ma variable de contexte et son contenu, tant que je ne ferme pas mon application qui consomme le webservice la variable est accessible. Si je la ferme, la variable est remise à 0)

3) Authentification
a) Est-il possible de s'authentifier lorsqu'on utilise un Webservice (dans le cas où il accède à des données sensibles ?) Si oui comment le faire ?
b) Lors de la création du Webservice, comment peut-on spécifier un login+mot de passe nécessaires lors de l'importation du webservice dans une application ?

Merci !

Citation:

---

Envoyé par cladoo

Bonjour,

j'ai créé un Webservice avec WB17 0.78n, les fonctions renvoient du flux XML en fonctions de paramètres. La consommation se passe bien, je récupère bien mon flux.

J'ai cependant plusieurs questions :

1) Accès concurrentiel
a) Si plusieurs applications consomment le webservice en même temps avec des paramètres différents, comment le webservice gère l'accès concurrentiel à ses fonctions ?

---

- Le web service fonctionne de la même manière qu'un site web, le moteur CGI générant un "environnement de travail" propre à l'appel : a priori pas de risque de téléscopage...

Citation:

---

b) Ne risque-t-on pas de télescoper le flux XML entre les 2 appelants ?

---

- A priori non (plusieurs de nos applications exploitent un WS avec des accès simultanés : applis (jusqu'a un cinquantaine de users en TSE en simultané, sites web (difficile a déterminer mais quelques dizaines simultanés potentiels)

Citation:

---

2) Persistance de contexte
a) J'utilise la persistance de contexte avec DéclareContexteWebservice cependant, jusqu'à quand le contexte d'une variable persiste si l'application consommatrice tourne en permanence et appel le webservice via un timer ? (TimeOut de libération du contexte)

---

- A priori, tant que l'application consommatrice revient appeler régulièrement le WS, la session est maintenue, donc le contaxte également. Attention au Time Out du serveur webdev par defaut 16 mn je crois...

Citation:

---

b) Est-ce que l'accès à une variable de contexte est bien spécifique à une "session webservice" ? Par exemple si ma variable de contexte vaut 10 après consommation du webservice par un poste client A, est-ce que je suis certain qu'elle sera remise à 0 si je lis son contenu depuis un poste client B ?

(En effet si je consomme mon webservice j'accède à ma variable de contexte et son contenu, tant que je ne ferme pas mon application qui consomme le webservice la variable est accessible. Si je la ferme, la variable est remise à 0)

---

- oui... le moteur génère une 'session' qui crée un pseudo environnement pour son contexte WebService... si vous laissé le stockage du contexte stocké sur disque (sur le serveur), mode par défaut, le fichier généré du contexte est identifié par son id de session.

Citation:

---

3) Authentification
a) Est-il possible de s'authentifier lorsqu'on utilise un Webservice (dans le cas où il accède à des données sensibles ?) Si oui comment le faire ?

---

- J'utilise une méthode d'authentification basé sur un GUID (windows) qui est renvoyé en réponse au consommateur. ce "jeton" doit être passé à toutes les autres méthodes du WS pour authentifier le contexte (cité précé demment)
- Autre possibilité : a tester avec la nouvelle MAJ, l'utilisatiion du WS-ADRESSING a priori dispo dans la nouvelle maj...

Citation:

---

b) Lors de la création du Webservice, comment peut-on spécifier un login+mot de passe nécessaires lors de l'importation du webservice dans une application ?

---

Ce login+ mot de passe à l'install est lié au paramétrage de l'accès au WSDL de puis le serveur HTTP. si vous n'avez pas autorisé les accès anonymes à ce répertoire, le login + mot de passe est nécessaire pour accéder au WSDL du WS.



Cordialement,

Laurent.

Merci beaucoup pour ces réponses très claires, ça fait plaisir! :ccool:

Citation:

---

Envoyé par lolob84

- J'utilise une méthode d'authentification basé sur un GUID (windows) qui est renvoyé en réponse au consommateur. ce "jeton" doit être passé à toutes les autres méthodes du WS pour authentifier le contexte (cité précé demment)
- Autre possibilité : a tester avec la nouvelle MAJ, l'utilisatiion du WS-ADRESSING a priori dispo dans la nouvelle maj...

---

Pouvez-vous m'en dire plus sur votre méthode d'authentification ?
Le GUID est celui de l'appli cliente appelante ?
En quoi celle-ci permet-elle d'éviter l'utilisation du webservice par un client "non désirable" ?

Merci d'avance

Citation:

---

Envoyé par cladoo

Merci beaucoup pour ces réponses très claires, ça fait plaisir! :ccool:



Pouvez-vous m'en dire plus sur votre méthode d'authentification ?
Le GUID est celui de l'appli cliente appelante ?
En quoi celle-ci permet-elle d'éviter l'utilisation du webservice par un client "non désirable" ?

Merci d'avance

---

Bonjour,

Et désolé pour le délai j'ai été Over-OVER-booké!!! lol!

Quand on peut aider, autant le faire...
Ma méthode (qui ne m'appartient pas, cela dit!!!) est très simple :
Un procédure appelée authentifie de mon WS, qui attend en parametres les infos utiles (User, Password, environnement BDD, User BDD, Password BDD, etc...)
Cette procédure verifie les droits du User, verifie la validite des environnement BDD demandés (pour moi, car je travaille en environnement multiple : le meme WS peut attaquer différentes BDD...).
Si tout est Ok, le WS utilise la fonction DonneGUID() qui renvoie un guid unique sur la machine. C'est donc le serveur WS qui genere le GUID.
En meme temps, cette procedure aliment mon contexte globale WS, avec les valeurs passées (citées plus haut) et renvoie le GUID au client ou une chaine d'erreur...

Quand l'appli cliente appelle une autre methode du WS, elle doit passé mon 'jeton de sécurité' comme paramètre, puis tout ceux propres à la méthode.

Toutes les autres méthodes du WS appellent une méthode en entrée qui vérifie la validité du jeton, à savoir si le jeton passé correspond bien au contexte WS en cours... c'est un peu redondant car en théorie, le contexte est bien maintenu, mais je voulais une validation que je puisse contrôler moi même (je me méfie toujours des automatismes, à savoir, oui le contexte Ws est bien le bon)
A l'exploitation, cela semble bien être le cas, depuis la mise en exploitation de ce Ws, plus de 100000 appels ont été effectués et je n'ai à priori pas de soucis de sécurité ou de perte de contexte.

Cordialement,

Laurent