Comment maintenir la session dans un programme à trois niveaux écrit par l'architecture Delphi WebService

Origine du problème:

S'il s'agit d'un service distant basé sur une connexion longue TCP / IP, tel que DataSnap recommandé par la nouvelle version de Delphi, il prend en charge la connexion TCP longue basée sur le client et le serveur. Le serveur peut même rappeler le client via cette connexion et lancer une notification active au client. Ensuite, une session est une connexion si longue.

Cependant, l'accès WEB est une connexion courte. Une opération, une connexion est établie, l'opération est terminée et la connexion est déconnectée. La prochaine fois, reconnectez-vous. Par conséquent, si l'utilisateur continue d'autres opérations après la connexion, comment le serveur sait-il si la connexion pour l'opération suivante ou le client connecté la dernière fois?

Il existe plusieurs façons de le faire sur le serveur WEB accessible par les pages Web:

1. Utilisez des cookies pour suivre le client;

2. Utilisez des champs masqués sous la forme de la page Web, c'est-à-dire qu'ils ne sont pas affichés sur la page, mais il y en a dans le code HTML du frontal de la page. Une fois la page soumise, le serveur peut lire le contenu de ces champs masqués, sachant que la page est connectée avant OMS

3. Utilisez les paramètres d'URL. Similaire à http://abcd.com/readDoc?docNumb=123456; voici le paramètre URL après le point d'interrogation. De nombreux sites Web utilisent cette méthode.

4. Il peut y avoir d'autres moyens que je ne connais pas. Veuillez connaître le message.

Alors, comment utiliser Delphi pour développer un WebService basé sur l'accès WEB?

---------------

Comment Delphi peut utiliser:

1. SOAP Header: les méthodes qui peuvent être recherchées sur Internet parlent toutes de l'utilisation de Soap Header. Vous devez définir une classe héritée de TSoapHeader pour stocker la valeur de Session obtenue à partir du serveur après la connexion de l'utilisateur ou simplement le nom d'utilisateur du client et Le mot de passe, en bref, consiste à transmettre des paramètres au serveur via cet en-tête Soap, et le code côté serveur lit cet en-tête Soap pour obtenir les paramètres permettant de savoir qui est le client.

2. Cookie: C'est une fonction que j'ai découverte par moi-même, c'était une fonction très utile, mais sous la nouvelle version de Delphi, c'est un peu gênant.

3. Paramètres d'URL. C'est simple et facile à utiliser. Mais recherche en ligne pour Delphi WebService Soap, etc., il n'y a pas d'informations pertinentes. C'est peut-être trop simple?

----------------------------

Basé sur la méthode Soap Header, le plus gros problème est que chaque fois que le client appelle la méthode côté serveur, il doit appeler la méthode d'envoi de l'en-tête Soap à l'avance. Autrement dit, la quantité de code a augmenté. Même si le client ouvre un TClientDataSet ou soumet un TClientDataSet via TSoapConnection, il doit d'abord exécuter le code pour envoyer l'en-tête Soap.

Utilisez des cookies, car les cookies sont transparents pour le client et le client n'a pas du tout besoin de s'en occuper. Tant que le serveur définit un cookie pour le client, le serveur peut lire le cookie chaque fois que le client se rendra à l'avenir, et le cookie peut dire qui est le client. Très bon moyen. J'ai également écrit un blog sur l'utilisation des cookies avant: Fonctionnement des cookies du WebService de Delphi

Problèmes d'utilisation des cookies:

1. Afin de faciliter le fonctionnement, je mets généralement un THTTPRIO et un TSoapConnection côté client, j'utilise THttpRio pour appeler la méthode d'interface côté serveur et j'utilise l'architecture de base de données à trois niveaux basée sur MIDAS via TSoapConnection. Vous pouvez obtenir des données sans écrire de code et soumettre Données, réduisez la charge de travail du code.

2. Dans la situation ci-dessus, utilisez HttpRio pour appeler la méthode de connexion côté serveur. Le côté serveur vérifie les paramètres tels que le nom d'utilisateur et le mot de passe soumis par le client dans cette méthode. Une fois la connexion réussie, le côté serveur crée un cookie pour que le client enregistre les paramètres du client. À l'avenir, que ce soit HttpRio qui appelle l'interface côté serveur ou ClientDataSet pour lire et écrire la base de données via SoapConnection, le côté serveur peut lire le cookie créé auparavant pour le client et savoir qui est le client en fonction des paramètres.

3. Cependant, la nouvelle version de Delphi utilise HttpRIO1 pour appeler les méthodes côté serveur. Les cookies créés par le côté serveur ne peuvent être lus par le côté serveur que lorsque ce HttpRio1 appelle à nouveau d'autres méthodes côté serveur; si HttpRIO2 ou SoapConnection1 est utilisé pour faire fonctionner le serveur Côté serveur, le cookie créé auparavant ne peut pas être lu côté serveur. C'est-à-dire que les multiples instances HttpRio et SoapConnection dans le client de la nouvelle version de Delphi ne partagent pas les cookies créés par le serveur.

3.1 La méthode pour résoudre le problème ci-dessus est un peu plus gênante, c'est-à-dire que même si c'est pour appeler la méthode côté serveur, utilisez SoapConnection1.RIO pour appeler, au lieu d'utiliser un autre HttpRio1 pour appeler. Cependant, pour que SoapConnection1.RIO appelle les méthodes d'interface côté serveur, vous avez besoin de:

  SoapConnection1.Connected := False;
  SoapConnection1.SOAPServerIID := '{A4E625D6-1BC4-4335-BEF4-669113CA65B4}';  //这个 ID 是你用 Delphi 写的 WebService 服务器端的接口的 IID
  SoapConnection1.Connected := True; //设计期关掉连接。运行期设置这个为 True

Concernant la méthode ci-dessus, l'aide officielle de Delphi dit ceci:

Si le serveur comprend plusieurs  modules de données distants , vous devez indiquer l'interface du module de données cible (un descendant de IAppServerSOAP) afin que TSOAPConnection puisse identifier le module de données distant que vous souhaitez utiliser. Il y a deux façons de faire ça:

  • Définissez la propriété SOAPServerIID pour indiquer l'interface du module de données distant cible. Cette méthode fonctionne pour tout serveur qui implémente un descendant IAppServerSOAP. SOAPServerIID identifie l'interface cible par son GUID. Au moment de l'exécution, vous pouvez utiliser le nom de l'interface et le compilateur extrait automatiquement le GUID. Cependant, au moment du design, dans l'inspecteur d'objets, vous devez spécifier la chaîne GUID.
  • Si le serveur est écrit en utilisant le langage Delphi, vous pouvez simplement inclure le nom de l'interface du module de données SOAP après une barre oblique à la fin de la partie chemin de l'URL. Cela vous permet de spécifier l'interface par son nom plutôt que par GUID, mais n'est disponible que lorsque le client et le serveur sont écrits en Delphi.

-------------------------------------------------- -------------

Utilisez les paramètres d'URL:

Nous utilisons HttpRio1 ou SoapConnection1 pour nous connecter au serveur. Si le serveur est écrit en Delphi, il vous suffit généralement de définir son URL sur:

https://127.0.0.1:8080/soap

Vous pouvez interagir avec le serveur.

Ensuite, lorsque le client appelle la méthode de connexion côté serveur, le côté serveur peut générer un ID de session pour le client, tel qu'une chaîne de nombres 13559, qui est renvoyée au client via cette fonction de connexion, le client peut alors modifier l'URL ci-dessus en: https://127.0.0.1:8080/soap?session=13579

Ensuite, que ce soit ClientDataSet1.Open ou ClientDataSet1.ApplyUpdates ou utiliser HttpRIO1 pour appeler une méthode d'interface côté serveur, côté serveur, vous pouvez lire cette session = 13579; le client n'a besoin que d'une ligne de code, qui consiste à modifier l'URL, et tout ce qui suit L'opération est automatiquement soumise, aucun autre code n'est requis . La méthode utilisée par le serveur pour lire ce paramètre est:

ID := GetSOAPWebModule.Request.QueryFields.Values['session'];

Explique:

Côté serveur , GetSOAPWebModule est déclaré dans l'unité Soap.WebBrokerSOAP, qui est une fonction globale et renvoie TWebModule. Tant qu'il utilise Soap.WebBrokerSOAP, il peut être utilisé. Request représente la demande du client, à travers laquelle vous pouvez lire les paramètres d'URL du client. Avant de lire, le cookie du client est également obtenu à l'aide de GetSOAPWebModule.

En fait, en utilisant le framework WebBroker dans Delphi pour écrire un programme serveur Web qui utilise la page du navigateur pour y accéder, c'est aussi via ce TWebModule pour manipuler la requête au client et la réponse de contenu à envoyer au client.

Je suppose que tu aimes

Origine blog.csdn.net/pcplayer/article/details/108563773
conseillé
Classement