Je dois dire que je ne comprends pas grand chose à tous ces détails
techniques, et d'ailleurs, en tant qu'utilisateur lambda, je ne suis pas
censé y comprendre quoi que ce soit.
Par contre, je persiste à trouver qu'il est scandaleux d'avoir besoin de
la dernière version de je ne sais quel bidule pour pouvoir voter ; qd on
met en place une telle procédure, on s'arrange pour qu'elle fonctionne
partout et sur des machines qui peuvent n'être pas récentes et sur
lesquelles ne tournent pas les dernières versions de softs divers et variés.
Il faudra bien s'interroger sur cette course à l'armement sans fin qui,
souvent d'ailleurs, n'améliore même pas les choses en termes
d'intelligence, de fonctionnalité ou d'ergonomie mais laisse, par
contre, bien des gens désemparés.
Encore le monde du libre y est-il un peu moins soumis, j'arrive encore à
lire de vieux fichiers openoffice avec l'extension swx ! Et puis, on
n'est pas encore obligé de changer de cuisinière chaque fois qu'on
expérimente une nouvelle recette, espérons que cela reste ainsi...
cordialement,
Le 20/10/2011 22:46, ymartin59@??? a écrit : >> savent pas écrire des trucs sans java ces branquignoles ?
>
> Ou serait-ce simplement que la documentation est incomplète ou inexistante ?
>
> Elle aurait dû préciser la version minimum de l'implémentation Java
> requise (celle de Sun/Oracle ou celle de IBM ou encore celle de
> l'ex-BEA/maintenant-Oracle JRockit) et les navigateurs supportés par le
> plugin en question. Tout en indiquant par capture d'écran les opérations
> manuelles nécessaires pour insérer son certificat personnel dans le "key
> store".
>
> L'idée relevée ici comme quoi les navigateurs savent faire du SSL
> authentifié "client certificate" en X.509 est vraie mais dans un cas de
> support de postes variés "dans la nature", il faudrait écrire un manuel
> avec des captures d'écran de chaque combinaison entre systèmes
> d'exploitation (versions mineures comprises) et navigateurs (idem pour
> les versions)
>
> En entreprise, tout est géré de façon centralisée et souvent le
> certificat de l'utilisateur est déployé dans son "key store" par
> l'intermédiaire de son profile. Bref, il ne se rend compte de rien et
> n'a rien à faire - quand il se connecte à un serveur HTTPS qui exige le
> certificat client, le navigateur le trouve au bon endroit et le
> single-sign-on fonctionne.
>
> Et donc le choix fait ici a été de reporter cet aspect de portabilité
> sur... l'installateur de "Java" et de son "plugin" pour navigateur !
> De cette façon, la configuration du certificat dans le "key store" et
> son utilisation par le code de connexion est indépendante de la
> combinaison OS/navigateur.
>
> Maintenant le problème vient plutôt des distributions Linux qui ont fait
> le choix de déployer un OpenJDK 6 qui n'est pas complet par rapport à la
> version "officielle" Sun/Oracle par rapport à la spécification "Java 6"
> - justement sur les aspects de cryptographie (copyright sur les code
> sources) !
>
> Bref, les distributions auraient dues attendre "maintenant" puisque la
> version OpenJDK 7 est bien l'implémentation de référence du "Java 7".
>
> Je trouve que c'est assez effrayant la tendance que nous avons à
> critiquer très facilement/rapidement les choses que l'on connaît peu ou
> pas assez.
>
