Aller au contenu principal
Version : Suivant

Sessions Desktop

Vue d’ensemble​

Une session desktop est un contexte d'exécution lié à l'utilisateur sur 4D Server, 4D remote ou 4D single-user qui ne résulte pas d'un accès web ou REST.

Les sessions desktop comprennent :

  • Sessions utilisateurs distants : Dans les applications client/serveur, les utilisateurs distants ont leurs propres sessions, gérées à partir du client et du serveur.
  • les Sessions des procédures stockées : Dans les applications client/serveur, la session utilisateur virtuelle unique qui gère toutes les procédures stockées exécutées sur le serveur.
  • les Sessions autonomes: Objet de session locale retourné dans une application mono-utilisateur (utile dans les phases de développement et de test des applications client/serveur).

Le diagramme suivant montre les différents types de sessions et leur interaction :

Tout comme dans une session utilisateur web, le code exécuté dans une session desktop a accès à un objet Session qui fournit des fonctions et des propriétés permettant de stocker les valeurs de session et de les partager entre les process utilisateur, par exemple en utilisant l'objet session.storage.

Toutefois, à la différence du code exécuté dans les sessions utilisateurs Web, le code exécuté dans les sessions desktop n'est pas soumis aux règles des rôles et privilèges. Il peut accéder à toutes les parties de l'application 4D, y compris ORDA et les classes du modèle de données (sur le serveur 4D, la fonctionnalité utilisateurs et groupes peut gérer les accès des utilisateurs). Notez également que les sessions desktop ne nécessitent pas l'activation des sessions évolutives.

Vous pouvez néanmoins partager une session utilisateur distant avec une session web afin que les utilisateurs de l'application desktop puissent accéder à votre application 4D par le biais d'une interface web, en utilisant notamment les pages Qodly et les zones Web.

Sessions utilisateurs distants​

Dans les applications client/serveur, lorsqu'un utilisateur se connecte au serveur, un objet de session utilisateur à distance est créé et disponible à la fois sur le serveur et sur le client. Il est renvoyé par la commande Session sur les deux machines.

Cet objet est géré via les fonctions et les propriétés de la classe Session.

Comparaison des objets de session utilisateur côté serveur et côté client​

Selon l'endroit où le code est exécuté, un objet utilisateur session côté serveur ou un objet utilisateur session côté client est disponible. Les deux objets sont similaires, à l'exception de ce qui suit :

  • leurs propriétés .storage ne sont pas le même objet. Une valeur stockée dans le .storage de la session utilisateur sur le serveur ne sera pas disponible dans le .storage de la session utilisateur sur le client et inversement.
  • pour des raisons de sécurité, la session côté client ne peut pas exécuter de fonctions qui modifient les privilèges (setPrivileges(), clearPrivileges(), promote(), demote(), restore()). L'appel de ces fonctions sur un client génère une erreur.
note

Les fonctions qui lisent les privilèges peuvent être appelées à la fois côté client et côté serveur (getPrivileges(), hasPrivilege(), isGuest()).

Utilisation​

Vous utilisez l'objet session de l'utilisateur distant pour gérer et partager les données de la session.

Dans chaque environnement, un objet session storage est partagé par tous les process de la même session utilisateur. Par exemple, sur le serveur, vous pouvez lancer une procédure d'authentification et de vérification de l'utilisateur lorsqu'un client se connecte au serveur, impliquant l'introduction dans l'application d'un code envoyé par e-mail ou par SMS. Ensuite, vous ajoutez les informations de l'utilisateur au storage de session, ce qui permet au serveur d'identifier l'utilisateur. De cette façon, le serveur 4D peut accéder aux informations de l'utilisateur pour tous les process clients, permettant l'écriture de code personnalisé en fonction du rôle de l'utilisateur.

Dans chaque environnement, vous pouvez utiliser l'objet "session" de l'utilisateur distant pour créer un OTP et partager la session distante pour les accès web.

Sur le serveur, vous pouvez également attribuer des privilèges à une session d'utilisateur distant pour contrôler l'accès lorsque la session provient de pages Qodly exécutées dans des zones web.

note

Côté client, deux objets "storage" locaux distincts sont disponibles :

Articles de blog sur le sujet

Partage d'une session distante pour les accès web​

Les sessions d'utilisateurs distants peuvent être utilisées pour contrôler les accès web à l'application par le même utilisateur et ainsi gérer leurs privilèges. Cette possibilité est particulièrement utile pour les applications Client/serveur dans lesquelles des pages Qodly sont utilisées pour l'interface, sur des machines clientes distantes. Avec cette configuration, vos applications disposent d'interfaces web modernes basées sur les CSS, tout en bénéficiant de la puissance et de la simplicité du développement intégré client/serveur. Dans ces applications, les pages Qodly sont exécutées dans des zones Web 4D standard.

Pour gérer cette configuration en production, vous devez utiliser des sessions utilisateur distant. En fait, les requêtes provenant à la fois de l'application 4D distante et de ses pages Qodly chargées dans les zones Web doivent fonctionner au sein de la même session. Il suffit de partager la session sur le serveur entre le client distant et ses pages web afin d'avoir le même session storage et la même licence client, quelle que soit l'origine de la requête (web ou 4D distant).

Les privilèges doivent être définis dans la session avant l'exécution d'une requête web, afin que l'utilisateur obtienne automatiquement ses privilèges d'accès au web (voir l'exemple). N'oubliez pas que les privilèges ne s'appliquent qu'aux requêtes provenant du web.

note

Les privilèges ne peuvent être définis qu'à partir de la session de l'utilisateur distant sur le serveur. Pour des raisons de sécurité, ils ne peuvent pas être modifiés à partir de la session de l'utilisateur distant sur le client (voir Comparaison des objets de session utilisateur côté serveur et côté client).

Les sessions partagées sont gérées par des tokens OTP. Après avoir créé un token OTP pour la session distante, vous ajoutez le token (par l'intermédiaire de la valeur du paramètre $4DSID) aux requêtes Web envoyées à partir des zones Web contenant des pages Qodly (ou à partir de n'importe quel navigateur Web) afin que la session de l'utilisateur sur le serveur soit identifiée et partagée. Du côté du serveur web, si une requête web contient un id OTP dans le paramètre $4DSID, la session correspondant à ce token OTP est utilisée.

note

Vous pouvez exécuter le code de création d'OTP à partir du serveur ou directement à partir du client (sur le serveur, vous pouvez utiliser par exemple la méthode base On Server Open Connection). Cependant, gardez à l'esprit que le .storage de la session web est partagée avec le .storage de la session utilisateur côté serveur et que les privilèges ne peuvent être définis qu'à partir de la session utilisateur sur le serveur.

tip

À des fins de développement et de test, vous pouvez utiliser une session autonome pour coder et tester toutes les fonctionnalités liées au partage de l'accès au web, que votre application soit destinée à un déploiement mono-utilisateur ou client/serveur.

Article(s) de blog sur le sujet

Intégrez des pages Qodly dans une zone web 4D sans coût supplémentaire

Exemple​

Dans un formulaire, obtenez un OTP et ouvrez une page Qodly dans une zone Web :

Form.otp:=getOTP

Form.url:="http://localhost/$lib/renderer/?w=Products&$4DSID="+Form.otp

WA OPEN URL(*; "QodlyPage"; Form.url)

La méthode de projet getOTP (avec la propriété Exécuter sur le serveur en Client/Server) :

// En client/serveur:
// ----------------
// Méthode exécutée sur le serveur car l'objet session est sur le serveur
// L'objet Session est Null sur le client 
//

#DECLARE() : Text

return Session.createOTP()

Voici le code utilisé pour placer le privilège "viewProducts" dans la session :

// En client/serveur:
// ----------------
// Ce code doit être exécuté sur le serveur car l'objet session est sur le serveur
// L'objet Session est Null sur la session client 

Session.clearPrivileges() // Nettoie la session de ses anciens privilèges
Session.setPrivileges("viewProducts")

Sessions de procédures stockées​

Sur le serveur, toutes les procédures stockées partagent la même session utilisateur virtuelle.

Utilisation​

Vous pouvez partager des données entre tous les process d'une session de procédure stockée à l'aide de l'objet partagé session.storage.

Disponibilité​

L'objet session des procédures stockées est disponible depuis :

Sessions autonomes​

Une session autonome est une session mono-utilisateur qui s'exécute lorsque vous travaillez localement avec 4D.

Utilisation​

La session autonome peut être utilisée pour développer et tester votre application client/serveur et son interaction avec les sessions web et le partage d'OTP. Vous pouvez utiliser l'objet session dans votre code d'une session autonome tout comme l'objet session des sessions distantes.

Disponibilité​

L'objet session d'une application autonome est disponible pour toutes les méthodes et le code exécutés sur l'application 4D.