Des boites à outils pour développer des applications Web intégrées au poste client (2ème Partie)

Dans l’article précédent, nous avons découvert l’environnement NW.js qui permet de déployer sur un poste client une application basée sur les technologies du web (HTML/CSS/JS), et qui peut bénéficier de toutes les capacités du système d’exploitation. Cette plateforme d’exécution n’étant pas limitée, comme les navigateurs standard, par le sand-boxing d’un environnement dédié à l’internet.

Pourquoi continuer d’écrire des applications d’entreprises limitées par le navigateur dans lequel elles s’exécutent? Alors qu’il est aujourd’hui possible de bénéficier du meilleur des deux mondes.

Dans cette deuxième partie, nous allons regarder comment NW.js adresse les aspects sécurité, ceci afin de garantir une utilisation sécurisée dans l’entreprise. Nous verrons aussi comment adapter une application intranet existante, pour bénéficier des fonctions systèmes quand elle est utilisée dans le contexte de NW.js. Enfin, nous essaierons d’explorer les différentes utilisations possibles de ce type d’outil.

Des applications lourdes, à l’intranet…

Il y a quelques années, de nombreuses applications d’entreprises reposaient sur des clients dit lourds qui dépendaient des capacités du système d’exploitation. Programmées avec les technologies Windows, Mac ou Linux, ces applications permettaient d’avoir des interactions riches avec l’environnement, mais souffraient de deux défauts majeurs : le mode de déploiement de poste à poste, et les langages et frameworks spécifiques à ces différents systèmes.

De nos jours les applications de ce type ont quasiment disparu laissant la place aux applications intranet, bénéficiant d’un déploiement centralisé, elles bénéficient aussi d’un socle commun de programmation reposant sur HTML/CSS/JS.

Mais pour en arriver là, il a fallu sacrifier nombre de fonctionnalités pour pouvoir s’inscrire dans le contexte d’un navigateur internet, qui a comme première vocation de faire de la navigation dans des documents structurés. Les approches, développées lors de l’avènement du modèle Web 2.0, ont conduit au travers des composants CSS/JS et des framework de type SPA (Single Page Application) à des applications plus flexibles et plus proches des applications natives. Elles restent toutefois limitées à la fenêtre (onglet) dans lequel elle s’exécute. Si cela s’entend pour une application internet, est-ce que cela a toujours un sens pour les application intranet ?

Gérer la sécurité des sources

Nous l’avons vu dans l’article précédent, NW.js permet de faire fonctionner une application HTML/CSS/JS sur un poste client dans un navigateur dédié non contraint par les limitations des navigateurs standards. Là ne s’arrête pas ses possibilités, toutes applications intranet servies par un serveur d’entreprise peuvent s’exécuter dans NW.js. Il suffit très simplement, soit de référencer un document sur un serveur dans le package.json, soit de fournir une page ouvrant sur un ou plusieurs liens d’applications intranet.

Les API de node et nw.js sont alors disponible pour l’application qui a été téléchargée au travers de l’URL donnée.

Comme dit dans la première partie, un navigateur NW.js ne propose pas de barre de saisie d’URL ni de flèches de navigation ; ce qui interdit à un utilisateur d’aller sur un site non autorisé, et qui pourrait utiliser les API de façon frauduleuse.

Au sein d’une page HTML on peut intégrer plusieurs frames référençant des origines différentes, par défaut, une page chargée au travers d’une iframe n’a aucun droit, à l’image de ce que ce qui se fait dans un navigateur standard. Pour pouvoir bénéficier des fonctionnalités de NW.js dans une iframe il faut que toutes les conditions suivantes soient vérifiées :

  • nodejs doit être à true dans le fichier package.json (c’est la valeur par défaut),
  • L’URL des fenêtres et des iframe doivent correspondre à la liste des expressions régulières dans node-remote, par exemple :

  • L’iframe ou ses parents ne doivent pas avoir l’attribut nwdisable,
  • L’iframe ou ses parents ne doivent pas être dans un élément <webview>.

L’élément <webview> est un élément HTML particulier, spécifique à NW.js, il est traité de façon très semblable à une iframe, à la différence qu’il s’exécute dans un environnement de thread et de mémoire séparé, donc dédié à des sites extérieurs non approuvés. Par exemple :

Applications mixtes Intranet/NW.js

Si on peut envisager de développer des applications intranet totalement dédiée à l’environnement NW.js, l’intérêt que nous voyons dans l’outil est de développer des applications hybrides qui continue de fonctionner dans l’environnement d’un navigateur, mais qui dans le cas d’une exécution dans NW.js, vont bénéficier d’un autre environnement permettant d’avoir une expérience étendue.

La détection de l’environnement se fait très simplement en JavaScript, en se basant sur l’objet nw qui est disponible dans le contexte window du script:

Nativement, dans NW.js, l’ensemble des fenêtres qui sont habilitées par les mécaniques précédemment décrites partage un contexte commun.

A partir de ce contexte commun, une communication peut s’établir entre les différentes applications. L’implémentation d’un WDM (Windows Desktop Manager) est très facilement faisable avec l’ensemble des API de gestion de fenêtres (déplacement, redimensionnement, focus, mise en avant topmost mode).

Le mode kiosk, permet de mettre l’application en frontal du système d’exploitation, et de le masquer afin de pouvoir proposer une interface unique basée sur HTML/CSS/JS.

Etude de cas

Comme évoqué précédemment, l’intérêt de NW.js est de créer des applications Web s’exécutant dans des fenêtres du bureau indépendantes d’un quelconque navigateur.

La création d’environnement métiers, dont les applications et les données sont présentées de façon pertinente, redevient possible. L’enfer de la gestion de fenêtres et d’onglets disparaît. De nombreuses types de mises en œuvre sont possibles:

  • Frontaux pour agence bancaire,
  • Gestion de portefeuilles client,
  • Système de supervision,
  • etc.

Les applications restent des sites intranets enrobés dans la mécanique NW.js, et dont une partie de la logique de gestion est déportée sur les API de l’outil.

Prototype d’environnement centré sur le geste métier

Dans le cadre d’une étude d”ergonomie sur les environnements de travail dédiés à la supervision, nous avons élaboré un Proof of Concept de l’utilisation de NW.js pour permettre de mettre en valeur les informations métier et simplifier le geste métier.

L’ensemble des applications intranet participant au système viennent s’inscrire auprès du gestionnaire d’application, qui est une fenêtre toujours visible. Une représentation de chaque application se retrouve dans le gestionnaire sous forme de miniature. L’utilisateur peut voir les applications déjà lancées, et commuter de l’une à l’autre en cliquant sur les miniatures.  La commutation consiste à la mise en avant des différentes applications. Une autre application se charge de présenter des informations en temps réel sur les différents événements du système d’information. Cette application est dockée au bas de l’écran et fait office de prompteur. Le gestionnaire d’application, comme l’espace d’info, sont des applications dédiées avec une logique spécifique NW.js, l’ensemble des applications métier, elles, fonctionnent indifféremment dans un navigateur internet ou dans cet environnement.

 

Système de notification

Les navigateurs Web compatibles avec la norme HTML 5 sont censés supporter la norme Web notifications, les spécifications se limitant aux API, chaque éditeur a réalisé une implémentation différente sans moyen de gérer aisément les temps d’apparition et de disparition, le nombre de notifications, etc.

Dans les environnements multi-navigateurs, cette disparité est d’autant plus nuisible qu’elle rend très difficile l’implémentation d’un comportement commun.

A l’issue d’un Proof of Concept, nous avons implémenté un système dont les notifications sont gérées au travers de pop-up NW.js,  qui sont activées par des invocations websocket de l’application intranet, et qui sont transformées en pop-up sur le bureau de l’utilisateur. Chaque pop-up, qui est une fenêtre web sans bord, peut avoir son comportement dédié, et présenter des caractéristiques spécifiques à l’application qui émet l’événement.  Comme l’ensemble des pop-up est géré par NW.js, le nombre de notifications avec leurs placements est maîtrisé.

Aujourd’hui en production, cette mise en œuvre présente une solution élégante dans le contexte d’un de nos clients.

Conclusion

Ces deux articles sont très loin de couvrir l’ensemble des  fonctions de NW.js, au travers de Chromium, son support d’HTML5/CSS3 et des technologies WebGL. L’environnement Node.js sous-jacent permet de mixer aux pages servies par les serveurs d’entreprises, des services locaux  implémentées dans le même langage.

Toutefois, nous espérons que les informations que nous avons donné dans cet article, vous permettront de voir les applications d’entreprise sous un autre angle.

Leave a Reply

Your email address will not be published. Required fields are marked *