Avez-vous déjà essayé de connecter une application web à du matériel spécifique ? Peut-être avez-vous réussi à récupérer la localisation d’un terminal par sa puce GPS, ou à activer une caméra… car ce sont des fonctionnalités qui sont prévues et intégrées dans les navigateurs (modernes). Mais imprimer directement sur une imprimante connectée en USB, ou piloter un périphérique branché au port série (comme un afficheur, une balance électronique de précision, etc.) ?
Probablement non… car, par définition, le contenu d’une page web ne doit pas accéder au matériel qui la fait tourner… C’est une base du cloisonnement et de la sécurité du WWW. Et c'est là que le EveConnector apporte une révolution à lui tout seul.
Vous installez EveConnector sur un poste, et toutes les applications web reconnues et supportant le EveConnector peuvent alors piloter en « raw » vos périphériques, y écrire comme y lire des données… À vous d’implémenter côté serveur, en JavaScript sans doute, le pilote qui conviendra.
Mais, concrètement, comment fonctionne le EveConnector ? C’est en fait une passerelle WebSockets, accessible sur par exemple wss://localhost:12345/ par toute page web autorisée (en créant une connexion WebSocket en JavaScript par exemple). L’ouverture d’un tunnel de communication avec un périphérique se fait alors en précisant le type de connexion de ce dernier (USB, série, etc.) et son identification sur le système (par exemple, en USB, le vendor_id et le device_id). Ensuite, il s’agit de dialoguer avec le périphérique en « raw »…
Par exemple, e-venement cherche à connaître les imprimantes connectées en USB qu’il reconnaît (les imprimantes BOCA et STAR dans notre cas de figure) et, en fonction, génère en interne (en utilisant wkhtmltopdf, CUPS et les pilotes CUPS de ces imprimantes) un fichier RAW qui est envoyé sur le port USB correspondant via une connexion WebSocket et le EveConnector, au moment où l'utilisateur cherche à imprimer ses billets. Pour valider l’état de l’impression, e-venement demande au EveConnector de lui rediriger les codes de retour de l’imprimante, qu’il se charge ensuite d’interpréter et d’utiliser pour ses besoins internes.
Programmé en JavaScript et exécuté en utilisant NodeJS, le EveConnector est portable sur toutes les plateformes où NodeJS est installable. Il est utilisable depuis tout navigateur supportant l’ouverture de WebSockets en JavaScript (ou autre), comme Mozilla Firefox, Chromium / Chrome, etc.
Ouvrez-vous de nouvelles perspectives, le EveConnector est un logiciel libre, publié sous licence GNU/GPL !! Utilisez-le, étudiez-le, distribuez-le et… Contribuez-y !
Le EveConnector est une émanation du logiciel de billetterie e-venement, développé par Libre Informatique.
Aller plus loin
- Annonce de la sortie du EveConnector sur e-venement.org (351 clics)
- e-venement, la billetterie informatisée libre (112 clics)
- Libre Informatique (98 clics)
- NodeJS (102 clics)
- Release note about the EveConnector on e-venement.org (105 clics)
# Et la sécurité dans tout ça?
Posté par Laurent Go . Évalué à 6.
En quoi est-ce une révolution de contourner la protection apportée par le navigateur pour permettre à n'importe quelle page web d'envoyer n'importe quel jeu de données (sans aucune validation) à n'importe quel périphérique USB présent sur le poste de travail?
[^] # Re: Et la sécurité dans tout ça?
Posté par ʭ ☯ . Évalué à 3.
À ce que je comprends, c'est sécurisé. Ce n'est pas un contournement, c'est de l'intégration du client léger.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Et la sécurité dans tout ça?
Posté par Baptiste SIMON (site web personnel) . Évalué à 6.
"Par toute page web autorisée"… voilà peut-être la réponse à la question (même si c'est encore améliorable).
Disons que c'est une "révolution" du fait d'ouvrir le champ d'applications métiers ayant besoin de dialoguer avec du matériel spécifique (comme des machines-outil par exemple, mais aussi du plus banal comme des imprimantes) aux logiciels en SaaS… et le tout via une technologie publiée en GNU/GPL. Mais on ne voit que ce que l'on décide de regarder…
Cela dit l'exemple des imprimantes STAR et BOCA est intéressant : tout le paramétrage du driver (et il y a un paquet d'options, souvent vitales pour le bon fonctionnement d'un progiciel en ayant besoin) se fait sur le serveur… sans risque d'avoir des utilisateurs totalement perdus pk la dernière "Windows Update" a tout foutu en l'air et qu'ils n'ont pas les droits "administrateur" pour refaire un paramétrage dont ils ne comprennent de toute façon rien…
Donc oui, puisque cela ouvre des perspectives encore innaccessibles actuellement au web, ça me semble digne d'intérêt ;c)
[^] # Re: Et la sécurité dans tout ça?
Posté par ZeroHeure (site web personnel) . Évalué à 4.
Odoo fait la même chose depuis quelques années pour les caisses, imprimantes et lecteurs de code-barre. Quelles sont les différences ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Et la sécurité dans tout ça?
Posté par marcoslibre . Évalué à 5.
Bonjour,
je ne suis pas un spécialiste d'Odoo, mais après un rapide survol de leur documentation, les différences semblent être les suivantes (corrigez-moi si je me trompe) :
La connexion entre Odoo et les périphériques nécessite un matériel tiers (PosBox, sur Raspberry-Pi) alors qu'EveConnector s'intègre directement au poste de travail.
EveConnector a été développé dans le cadre du logiciel e-venement, mais il n'est pas dépendant de ce dernier, il a été conçu comme une "brique" logicielle générique servant à connecter n'importe quelle application SaaS aux périphériques des postes clients. PosBox de son côté semble être développé exclusivement pour Odoo.
Nous sommes preneurs de toute info concernant les solutions techniques libres permettant de réaliser cette connexion SaaS/matériel, afin de pouvoir comparer, débattre et contribuer…
[^] # Re: Et la sécurité dans tout ça?
Posté par ZeroHeure (site web personnel) . Évalué à 3.
J'ai fait pas mal de LTSP (Linux Terminal Server Project), il y avait un très bon module développé pour accéder au matériel connecté sur le client léger. C'est sensiblement la même problématique il me semble.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Et la sécurité dans tout ça?
Posté par Baptiste SIMON (site web personnel) . Évalué à 3.
mmmmm je ne crois pas …
mais je n'ai pas fait de LTSP depuis… 2003.
LTSP ce n'est pas du client léger au sens du SaaS. Il y a qd mm une partie de l'OS qui tourne sur la machine locale, qui accède au matériel, non ?
Ici c'est vraiment que la partie logicielle "client" est à l'intérieur d'un navigateur web, présenté avec les mêmes autorisations qu'une page web lambda d'un point de vue du navigateur.
[^] # Re: Et la sécurité dans tout ça?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 12 septembre 2016 à 14:50.
Ca ne pose aucun problème au navigateur qui affiche toujours un cadenas vert?
(je n'ai pas testé, je suis juste surpris et curieux que le navigateur laisse passer ça sans faire d'alerte de sécurité sur le chiffrement des données transmises, et j'avoue en avance que ma connaissance des websocket est très très basse donc ma question peut être ridicule)
[^] # Re: Et la sécurité dans tout ça?
Posté par Baptiste SIMON (site web personnel) . Évalué à 4.
Oui (sur nos essais) le navigateur est toujours au vert… à condition de passer sur du wss:// (WebSocket over SSL)…
Par contre, si le certificat du EveConnector n'est pas valide (ce qui, je suppose, sera le cas dans 99% des usages), alors il faut forcer l'acceptation du certificat avant le premier usage du EveConnector "en vrai", en allant simplement sur la page http://localhost:MONPORT/ et en acceptant l'exception de sécurité.
Après il tient à qui de droit de mettre en place un certificat valide…
[^] # Re: Et la sécurité dans tout ça?
Posté par ZeroHeure (site web personnel) . Évalué à 4.
Quelques minutes après avoir posté, je suis allé réviser mes classiques pour me rendre compte que j'avais sans doute écris une connerie…
pour accéder aux périphériques locaux LTSP utilise un système de fichier distant : le ltspfs filesystem.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Et la sécurité dans tout ça?
Posté par Laurent Go . Évalué à 7.
Je suis d'un naturel curieux, et je comprends bien l'intérêt du pourquoi, mais on ne peut pas mettre dans le même texte: "par définition, le contenu d’une page web ne doit pas accéder au matériel qui la fait tourner… C’est une base du cloisonnement et de la sécurité du WWW" et plus loin "Vous installez EveConnector sur un poste, et toutes les applications web reconnues et supportant le EveConnector peuvent alors piloter en « raw » vos périphériques, y écrire comme y lire des données", sans se poser la question de comment tout cela est sécurisé… surtout qu'on parle d'un accès via le web, où de nouvelles failles de sécurité sont trouvées tous les jours, et chaque mois apporte une nouvelle version des plugins Flash ou Java…
En cherchant bien dans le code, je n'ai rien trouvé qui ressemble de loin ou de près à un système d'authentification et d'autorisation. Donc, en l'état, n'importe quelle page web peut envoyer n'importe quoi à n'importe quelle périphérique. J'ai l'impression aussi que le connecteur écoute sur toutes les interfaces réseaux (et pas seulement loopback, ce qui semblerait logique si seul le navigateur est censé pouvoir y accéder).
Peut-être que tout ceci est dans la roadmap des développeurs, ou peut-être que mon idée de comment utiliser EveConnector est faussé. Il s'agit juste d'une base et c'est aux applis ou sites web métiers de créer une version spécifique et sécurisée.
Sinon, une alternative plus générale pourrait être une extension (addon), l'extension demandant confirmation avant d'autoriser une page web à accéder à tel périphérique (et il y a déjà pas mal d'extensions qui utilisent libusb).
Je remercie les développeurs d'e-venement et EveConnector pour leur contribution au Libre, mais dans ce contexte d'utilisation, on ne peut pas laisser de côté l'aspect sécurisation.
[^] # Re: Et la sécurité dans tout ça?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 12 septembre 2016 à 12:20.
Ce n'est plus du client léger car il faut installer quelque chose.
Donc on installe un truc pour utiliser un client léger qui a pour but de ne pas installer un truc. Ca se mord la queue? Oui :).
A force on va comprendre qu'installer un client lourd est la chose à faire, et on refera des toolkits pour faire des clients lourds (car force est de constater qu'aujourd'hui il y a plus de choses en web", et donc je comprend le choix technique fait dans ce cas avec l'état du "marché" en terme technologiques).
Bref, l'histoire habituelle de la mode, avec des retours en arrière et on recommence.
Ils ont juste contourné la "sandbox" du navigateur qui les faisait chier. C'est un trou potentiel de sécurité et ce n'est plus un client léger (où le navigateur est acteur de la sécurité et pose des limites), on revient sur la sécurité "à l'ancienne" (tu en es responsable, c'est "open bar" sur ton logiciel qui a plein d'accès et donc il faut faire attention; après c'est en "local" donc c'est compréhensible, c'est juste plus client léger ni sécurisé par le navigateur)
[^] # Re: Et la sécurité dans tout ça?
Posté par Baptiste SIMON (site web personnel) . Évalué à 2.
Moi je comprends qu'il n'y a aucune logique métier à installer… donc on ne perd rien de la flexibilité, de la maintenabilité, de la scalabilité d'une solution SaaS avec cette techno. C'est en ça que c'est chouette.
La sandbox est ok pour laisser passer du WebSocket… donc ça la contourne car elle le permet.
Ensuite, si le but est de faire du site web, je comprends ton scepticisme, mais qui a un jour été confronté à l'édition de logiciels métiers en SaaS pourra sans doute voir là une opportunité indéniable : il n'y a rien de métier à maintenir sur les postes clients, il n'y a pas de driver à mettre à jour en local, il n'y a pas de risque de mauvaise configuration des postes…
M'enfin, si on n'aime pas le principe et qu'on n'amène rien de constructif pour répondre à la problématique qui est soulevée ici, entendre des dents grincer ne m'étonne pas ;c)
[^] # Re: Et la sécurité dans tout ça?
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 12 septembre 2016 à 14:44.
Ici le problème est qu'on veut afficher du SaaS (car c'est à la mode, le client demande ça car c'est hype etc) sur des besoins non répondables en SaaS (car dépendant de l'équipement, bref du banal client/serveur digne des années 90, c'est pour ça que je parle de retour en arrière).
Bref c'est surtout pour dire que les modes ont leur limites, et finalement on a les mêmes problèmes qu'ils y a 30 ans, avec les mêmes réponses (des bidouilles car on n'a pas le choix autrement).
Euh… Si tu penses à moi avec ce "pic", je t'invite à relire le commentaire auquel tu réponds (hint: il dit justement qu'il n'y a pas vraiment d'autre solution avec les toolits disponibles actuellement et que donc que c'est la pire des solution à l'exception de toutes les autres solutions si on n'a pas le temps de refaire le monde).
Je dis juste que c'est n'est plus du client léger (tu ne l'as pas écrit dans la dépêche, je répondais à un commentaire) car vous installez un logiciel (si j'ai bien compris) à l'ancienne (vous auriez la même chose en installant une appli client/serveur années 90, rien de nouveau dans l'idée, mais il faudrait refaire le GUI et c'est là où c'est nouveau : on doit bidouiller pour refaire avec les technos modernes finalement limitées ce qu'on faisait il y a 30 ans).
[^] # Re: Et la sécurité dans tout ça?
Posté par Michaël (site web personnel) . Évalué à 3.
Ça me paraît aussi bizarre. Ce qu'il faut faire – il me semble – c'est plutôt préparer une mini API http-json et un petit serveur qui la fait tourner, plutôt que d'ouvrir comme ça les entrailles de la bêbête!
[^] # Re: Et la sécurité dans tout ça?
Posté par Baptiste SIMON (site web personnel) . Évalué à 1.
C'est à peu près ce que nous avons fait.
Il est possible de l'implémenter dans un mini-serveur (ex: raspberry), mais également sur une station de travail "localhost"… Le déploiement est aussi flexible que notre imagination ensuite…
# Projet très intéressant
Posté par remi.passmoilesel (site web personnel) . Évalué à 1.
Projet très intéressant, merci pour le partage !
https://github.com/remipassmoilesel ; http://abc-map.fr
[^] # Re: Projet très intéressant
Posté par Baptiste SIMON (site web personnel) . Évalué à 2.
Ne pas hésiter à retourner sur le projet tous les usages possibles qui auront été expérimentés… Je pense par exemple :
- numérisation directe depuis du matériels tiers (ex: VHS, bandes magnétiques, etc.)
- utilisation de balances de précision
- pilotage de machines-outils spécifiques
- déploiement sur une box (de type POSBox de Odoo)
- données provenant de sonars, radars, autres
- etc.
Et si vous développez des drivers spécifiques en Javascript (côté logiciel SaaS, ça peut être utile pour d'autres personnes)…
Sur e-venement, la production nous oblige à ne pas tout finir aussi bien qu'on le souhaiterait, mais l'intégration de CUPS a été faite, l'interfaçage avec les TPE Ingénico, des afficheurs clients, etc… mais nous n'avons pas pris le temps de "sortir" ces drivers de e-venement… Alors si de bonnes volontées veulent s'y mettre… :c) ça ne devrait pas être très difficile.
# pyWebDriver
Posté par hpar . Évalué à 4.
J'utilise pyWebDriver qui répond à peu près à cette problématique (impression directe, connexion à des balances, etc.)
Ça s'installe sur un poste client et ça offre une interface http(s), avec donc un filtrage par le navigateur sur la same origin policy.
Et contrairement à eveConnector, les données ne sont pas transmises en "raw" et sont traités par différents modules (cups, module pour tpe).
Le but n'est pas de l'installer sur le poste de Mme Michu mais dans un environnement d'entreprise avec d'autres niveaux de protections (notamment réseau).
[^] # Re: pyWebDriver
Posté par Baptiste SIMON (site web personnel) . Évalué à 2.
Aaah le voilà le module de Odoo pour faire ça… on l'a un peu cherché et jamais trouvé !! :c)
Chouette de voir comment ils ont fait ça.
On me confirme donc que l'impression "directe", par exemple, dépend du paramétrage du driver installé localement ? Et sous MSWindows, il se passerait quoi ? L'ouverture d'une boîte de dialogue pour confirmer l'impression, le périphérique, etc… ?
D'ailleurs, j'ai un doute, je crois pas qu'il soit porté sous MSWindows si ?
En tout cas, sauf au mieux s'il peut remplacer le EveConnector, on va y jeter un œil attentif pour voir comment s'inspirer de ses meilleures parties !!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.