Discussion :

[marc.collin]

Merci pour ces explications.

Y'en à qui l'utilise du coups ?

Plutôt en entreprise. Je trouve que c'est un bon compromis quand tu as besoin de faire des interfaces graphiques très complexe et que tu veux une certaine facilité niveau déploiement, maintenance.

Niveau composant graphique pour le web, mis à part 2, 3 frameworks, c'est pas la panacé

[Uther]

Il va falloir que je regarde l'impact d'integrer un serveur de websocket dans une application java, si quelqu'un a des pistes de recherche je suis preneur. Et comme mon "applet" communique aussi directment avec mon backend (en utilisant de services rest) il va falloir que je regarde comment faire passer le token d'authentification de ma page web à l'application en Java Web Start... l'architecture de l'implementation va quand meme etre un poil plus complexe.

A priori si c'est juste pour échanger un simple résultat, tu n'as pas besoin d'un serveur complet. Un simple objet ServerSocket devrait suffire pour gérer manuellement une requête http.

[tchize_]

Quelqu'un a une solution pour lire le contenu d'une smartcard depuis le browser sans passer par un plugin? Je suis curieux. De toute ma carrière c'est la seule fois ou j'ai eu besoin d'une applet java et je ne vois pas par quoi la remplacer. Webstart n'est pas une option car le formulaire web n'y a pas accès et je ne vois pas d'api spécifique en javascript permettant d'accéder à un lecteur de carte.

[RyzenOC]

Quelqu'un a une solution pour lire le contenu d'une smartcard depuis le browser sans passer par un plugin?

Je pense que c'est une mauvaise utilisation d'une technologie.
Il faut se poser la bonne question, pourquoi lire des cartes à puce dans une page web ?

N'y aurait t'il pas une autre solution plus adapté, faire un logiciel installer directement sur la machine, remplacer la carte a puce, par une carte avec des numéros a taper (comme les cartes bancaire)...etc.

Si c'est pas trop risqué niveau sécurité, remplacer les puces par des codes barre à prendre en photos (il y'a des api html5 pour utiliser la webcam).
J'ai jamais compris pourquoi y'a cette volonté de vouloir faire du 100% web.

[Nico02]

Quelqu'un a une solution pour lire le contenu d'une smartcard depuis le browser sans passer par un plugin? Je suis curieux. De toute ma carrière c'est la seule fois ou j'ai eu besoin d'une applet java et je ne vois pas par quoi la remplacer. Webstart n'est pas une option car le formulaire web n'y a pas accès et je ne vois pas d'api spécifique en javascript permettant d'accéder à un lecteur de carte.

Je comprends pas pourquoi tu dis que le formulaire n'y a pas accès ?

Tu peux toujours demander à ton appli web de lancer ton appli java via JWS qui elle va lire les données pour les renvoyer au serveur non ? J'imagine que c'est plus lourds à mettre en place mais ça doit être faisable.

[The F0x]

Je pense que c'est une mauvaise utilisation d'une technologie.
Il faut se poser la bonne question, pourquoi lire des cartes à puce dans une page web ?

N'y aurait t'il pas une autre solution plus adapté, faire un logiciel installer directement sur la machine, remplacer la carte a puce, par une carte avec des numéros a taper (comme les cartes bancaire)...etc.

Si c'est pas trop risqué niveau sécurité, remplacer les puces par des codes barre à prendre en photos (il y'a des api html5 pour utiliser la webcam).
J'ai jamais compris pourquoi y'a cette volonté de vouloir faire du 100% web.

Je me permet de repondre car je suis dans le meme cas de figure, je developpe des applications de GED et pour un client voulant mettre en place un systeme de signature electronique legale, il nous a fallu un support pour "heberger" le certificat de l'utilisateur, nous nous somme donc tourner vers un systeme de smartcard(finger print sur le reader pour remplacer le code pin et activer le certificat) ensuite toute la signature se fait dans la smartcard, c'est la aussi un des interests, meme avec un machine corrompu on ne peut generer de vraie fausse signature. Les regles de bon usage veulent que chaque utilisateur doit posseder physiquement son certificat.

Donc le remplacer par des cartes a code etc, etc, ce n'est pas vraiment envisageable voir remettrait en cause la legalite de la signature.

[The F0x]

A priori si c'est juste pour échanger un simple résultat, tu n'as pas besoin d'un serveur complet. Un simple objet ServerSocket devrait suffire pour gérer manuellement une requête http.

je vais me pencher sur la question, ce que je dois faire c'est lancer l'appli web start (ou voir si elle ne tourne pas deja) ensuite envoyer mes parametres a l'application et attendre son retour pour declencher mes evenements au niveau de ma page web. Avant tout il faut que je regarde comment fonctionne les websockets.

[Uther]

Je me suis amusé a faire un petit essai rapide. Coté application :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
        try (
            ServerSocket ss = new ServerSocket(5666);
            Socket s = ss.accept();
            BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream()));
            Writer out = new OutputStreamWriter(s.getOutputStream());
        ){
            out.write("HTTP/1.1 200 OK\n");
            out.write("Access-Control-Allow-Origin: *\n\n");
            out.write("Hello World");
        } catch (IOException ex) {
            Logger.getLogger(JavaApplication1.class.getName()).log(Level.SEVERE, null, ex);
        }

Coté Web:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
<html>
  <head></head>
  <body>
    <script type="text/javascript">
      document.write("essai : <br>");
      var xhr = new XMLHttpRequest();
      xhr.open('GET', "http://localhost:5666", false);
      xhr.send();
      document.write(xhr.responseText);
    </script>
  </body>
</html>

C'est juste un POC moche et très perfectible, mais visiblement ça marche, sans passer par un serveur de websocket.

[tchize_]

Je pense que c'est une mauvaise utilisation d'une technologie.
Il faut se poser la bonne question, pourquoi lire des cartes à puce dans une page web ?

Pour pré remplir un formulaire avec les données qui s'y trouvent, afin d'éviter de nombreuses erreurs de recopie manuelle

N'y aurait t'il pas une autre solution plus adapté, faire un logiciel installer directement sur la machine

Remplir une partie via un logiciel installé sur la machine, et le reste via le formulaire web. T'aime bien rendre les users fous / surcharger le helpdesk de questions

, remplacer la carte a puce, par une carte avec des numéros a taper (comme les cartes bancaire)...etc.

Si c'est pas trop risqué niveau sécurité, remplacer les puces par des codes barre à prendre en photos (il y'a des api html5 pour utiliser la webcam).

Faudra juste que t'aille expliquer à mon gouvernement que tu es certains qu'il s'est fourvoyé en utilisant des smarcard pour les cartes d'identité électronique et qu'il aurait du utiliser un code QR à imprimer chez soi quand on change d'adresse.

J'ai jamais compris pourquoi y'a cette volonté de vouloir faire du 100% web.

En l'occurence c'était déjà du web, l'extraction de données EID a été rajoutée par la suite, on allait pas remplacer tout notre intranet par une application standalone pour 1 besoin un peu borderline, d'autant que la lecture depuis une applet faisait partie des specs supportées officiellement par le middleware. Ensuite entre les contraintes du web ou les contraintes de déployer et mettre à jour une appli sur 200 bureaux variant de windows 95 à 2000 en passant par vista, linux, mac os x, le choix a vite été fait. D'autant qu'à l'époque, JWS c'était un peu n'importe nawak.

[tchize_]

Tu peux toujours demander à ton appli web de lancer ton appli java via JWS qui elle va lire les données pour les renvoyer au serveur non ? J'imagine que c'est plus lourds à mettre en place mais ça doit être faisable.

Je suis curieux, tu fais comment le lien entre ce que JWS envoie au serveur et le formulaire ouvert sur ta page web? JavaWS ne prends pas de paramètres à l'exécution, donc pas question de lui filer un session id. L'ip est inutilisable par les users derrière un nat. Au mieux faudrait générer un jnlp à la volée avec le session id dedans, le mettre dans le jar, signer le jar à la volée, bonjour la charge pour le serveur. Peut être faisable mais complexe, sujet à de nombreuses erreurs d'exécution.

Enfin bon c'est plus mon problème, je suppose que quand java 9 sera la seule version supportée, mon ancienne boite abandonnera simplement le support de l'eid et ils retapperont tout à l'ancienne.

[Uther]

Je suis curieux, tu fais comment le lien entre ce que JWS envoie au serveur et le formulaire ouvert sur ta page web? JavaWS ne prends pas de paramètres à l'exécution, donc pas question de lui filer un session id.

Il me semble bien que c'est possible : http://stackoverflow.com/questions/1...ith-parameters

[RyzenOC]

En l'occurence c'était déjà du web, l'extraction de données EID a été rajoutée par la suite, on allait pas remplacer tout notre intranet par une application standalone pour 1 besoin un peu borderline

1) Pour moi la meilleur solution c'est de crée un logiciel natif qui s'installe sur la machine (avec java web start ou autre chose).
2) A partir de cette application, soit tu recrée ton formulaire html complet sur ton logiciel, et ton logiciel envoie ensuite les données au serveur
Soit tu fais un logiciel qui lit ta carte a puce puis génère un fichier binaire contenant les infos de ta carte et la date de la lecture, puis l'utilisateur n'a plus qu'a uploader le fichier sur le serveur (avec un formulaire en html et un drag and drop bien conviviale).

Le fichier binaire tu le chiffre avec du RSA ou autre pour garantir plus de sécurité et c'est bon.

[marc.collin]

J'ai jamais compris pourquoi y'a cette volonté de vouloir faire du 100% web.

Facilité de déploiement, maintenance, possibilité de l'utiliser sur la plupart des os et navigateur

[RyzenOC]

Facilité de déploiement, maintenance, possibilité de l'utiliser sur la plupart des os et navigateur

Ce que je veut dire c'est que le web n'est pas la solution à tous les problèmes, y'a plein de défauts à prendre en compte aussi (réactivité/performances médiocre, faut mettre à jour le code tous les jours, peu d'interaction possible avec la machines et ces périphériques...)

maintenance, possibilité de l'utiliser sur la plupart des os et navigateur

un code en C sa dure 20ans, un code en javascript sa dure 6 mois (j'exagère mais c'est l'idée)

[tomlev]

Je me suis amusé a faire un petit essai rapide. Coté application :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
        try (
            ServerSocket ss = new ServerSocket(5666);
            Socket s = ss.accept();
            BufferedReader in = new BufferedReader(new InputStreamReader(s.getInputStream()));
            Writer out = new OutputStreamWriter(s.getOutputStream());
        ){
            out.write("HTTP/1.1 200 OK\n");
            out.write("Access-Control-Allow-Origin: *\n\n");
            out.write("Hello World");
        } catch (IOException ex) {
            Logger.getLogger(JavaApplication1.class.getName()).log(Level.SEVERE, null, ex);
        }

Coté Web:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
<html>
  <head></head>
  <body>
    <script type="text/javascript">
      document.write("essai : <br>");
      var xhr = new XMLHttpRequest();
      xhr.open('GET', "http://localhost:5666", false);
      xhr.send();
      document.write(xhr.responseText);
    </script>
  </body>
</html>

C'est juste un POC moche et très perfectible, mais visiblement ça marche, sans passer par un serveur de websocket.

J'avais fait un essai similaire, mais aller au delà du POC est un peu plus compliqué, surtout si tu commences à réfléchir aux questions de sécurité...

• Si la page web est servie en HTTPS, la politique de sécurité du navigateur impose que la connexion websocket se fasse aussi en HTTPS.
• Donc il faut un certificat, et un certificat auto-signé ne suffit pas.
• Or, tu te connectes sur localhost, et aucune autorité de certification ne délivre de certificat pour localhost.
• Bon, ça peut se contourner : il suffit de faire un domaine qui pointe vers 127.0.0.1.
• Mais c'est pas fini !
• Il faut embarquer le certificat avec l'appli pour que celle-ci puisse l'utiliser.
• Donc ton certificat se promène dans la nature, et est donc compromis...
• N'importe qui peut donc se faire passer pour ton appli, pourvu qu'il arrive à empoisonner le DNS de l'utilisateur.

Bref, c'est malheureusement pas si simple...

[Uther]

Ha je me doutais bien que c'était plus compliqué au niveau de la sécurisation, mais je pensais pas que c'était aussi galère.
Du coup la solution de Nico02 de faire communique l'application locale directement avec le serveur me semble la meilleure.

[OButterlin]

Ce que je veut dire c'est que le web n'est pas la solution à tous les problèmes

Certes, il ne s'agit pas de faire du web partout, ce n'est pas ce qu'il y a de plus performant. Je n'imagine pas la gestion d'une machine outil à coup d'application web

y'a plein de défauts à prendre en compte aussi (réactivité/performances médiocre, faut mettre à jour le code tous les jours, peu d'interaction possible avec la machines et ces périphériques...)

"faut mettre à jour le code tous les jours" ??? Bien sûr que non, le code est stable dans le temps
"peu d'interaction possible avec la machine et ces périphériques" ? Une applet signée à accès à tout, c'est (entre autre) un de ces intérêt

un code en C sa dure 20ans, un code en javascript sa dure 6 mois (j'exagère mais c'est l'idée)

Provoc !
Nos applications on une durée de vie largement supérieure à 6 mois, ça se compte en années aussi... mais c'est du développement classique JSF/Primefaces (donc du javascript raisonnable) voir Struts/Struts-Layout pour les plus anciennes (plus de 7 ans).
Maintenant, une application basée sur un framework javascript, je ne suis pas chaud... il y a trop de différences entre les navigateurs encore.

[tchize_]

Il me semble bien que c'est possible : http://stackoverflow.com/questions/1...ith-parameters

Oui, c'est la partie:

Au mieux faudrait générer un jnlp à la volée avec le session id dedans, le mettre dans le jar, signer le jar à la volée, bonjour la charge pour le serveur. Peut être faisable mais complexe, sujet à de nombreuses erreurs d'exécution.

Mais c'est très lourd pour l'utilisateur car de son point de vue, à chaque fois, il télécharge une nouvelle application.

[tchize_]

1) Pour moi la meilleur solution c'est de crée un logiciel natif qui s'installe sur la machine (avec java web start ou autre chose).

Pour mois c'est la pire solution car elle nécessite de nombreuses manips de l'utilisateur.

2) A partir de cette application, soit tu recrée ton formulaire html complet sur ton logiciel, et ton logiciel envoie ensuite les données au serveur

Donc tu duplique ta logique de validation en ayant deux copies du formulaire et de ses nombreuses règles buisness et tu transforme une modif de 2 jours en une modif de un à deux mois (trois si tu tiens compte du fait qu'à l'époque ce genre d'interconnexion c'était soit la grosse artillerie axis 1 soir les EJB2), avec un blocage de l'utilisateur qui va te dire à raison que les manipulations que tu lui demande seront beaucoup plus longue que de tapper les données à la main. Le but c'est quand même de faciliter la vie de l'utilisateur, pas de faire un trucs complexe, génial et inutile.

[tchize_]

un code en C sa dure 20ans, un code en javascript sa dure 6 mois (j'exagère mais c'est l'idée)

Oui très provoc, je trouve sans problème des codes javascripts d'il y a 10 ans qui marchent encore, et des applis C d'il y a 2 ans qui ne compilent plus parce que dépendent de la librairies X, dont il n'existe pas de version 64 bits et dont la version 32 bits ne marche plus avec la libc récente nécessaire pour avoir un support dual 32/64 sur linux. J'exagère mais t'as l'idée. Et avec un code pur C on ne sait même pas ouvrir une fenêtre sans être lié à un système qui ne pourrait plus être compatible dans 6 mois....

Bon sang, j'ai des jeux vidéo sur mon PC qui ne survivent même pas à une mise à jour de windows. Durée de vie sans patch inférieure à 1 mois....