Mais partant de ce principe là quel est le risque de laisser faire tourner sur la machine cliente des scripts modifiés par le client lui même ?
Si l'appli coté serveur est correctement codée : aucun.
Problèmes de sécurités (on ne maitrise pas la validation des données coté client) ?
La validation des données doit toujours se faire coté serveur ! La pré-validation coté client ne sert, en général, qu'à mettre en place une interface plus réactive, mais, en aucun cas, on ne doit faire confiance aux données venant d'un clien, même si on l'a codé, justement parce que rien n'empêche de changer de client ou de le modifier (cf injections, XSS...)
Problème de charge serveur (le client peut taper comme un bourrin sur le serveur) ?
Là aussi, le client peut faire ce qu'il veut : c'est à l'appli serveur de faire la loi
Problème de business Model (en donnant au client un certain pouvoir (liberté) est-ce qu'on ne le "libère" pas, au moins en partie, du serveur (plus de connaissance, acteur et pas seulement utilisateur, ...) ?
C'est le seul "problème" : en effet, si l'argument est, entre autre, le fait d'avoir un client au top coté réactivité et ergonomie, c'est clairement un problème, d'un autre coté le problème se pose dès le départ et n'est pas nouveau (exemple : face à un client lourd, un client en ligne n'aura que peu d'avantages à part le fait d'être accessible de partout, exemple utiliser l'interface de Zimbra ou Thunderbird+Lightning?)
Enfin, le problème que soulève RMS est réel, mais loin d'être nouveau... cependant, le réel problème n'est pas, à mon avis, de savoir si l'interface en javascript est libre ou pas (si on peut la modifier), mais si l'utilisateur est libre d'utiliser un autre client, pour moi c'est là que réside la réelle privation de liberté et le fait d'utiliser un protocole non standard pour un service "courant" ou de limiter l'accès à ce service à l'interface javascript peut être vécu comme une privation de libertés.
Reste enfin le problème de la contractualité, mais là c'est autre chose.
[^] # Re: En même temps...
Posté par jeffcom . En réponse au journal RMS et le piège du Javascript. Évalué à 5.
Si l'appli coté serveur est correctement codée : aucun.
Problèmes de sécurités (on ne maitrise pas la validation des données coté client) ?
La validation des données doit toujours se faire coté serveur ! La pré-validation coté client ne sert, en général, qu'à mettre en place une interface plus réactive, mais, en aucun cas, on ne doit faire confiance aux données venant d'un clien, même si on l'a codé, justement parce que rien n'empêche de changer de client ou de le modifier (cf injections, XSS...)
Problème de charge serveur (le client peut taper comme un bourrin sur le serveur) ?
Là aussi, le client peut faire ce qu'il veut : c'est à l'appli serveur de faire la loi
Problème de business Model (en donnant au client un certain pouvoir (liberté) est-ce qu'on ne le "libère" pas, au moins en partie, du serveur (plus de connaissance, acteur et pas seulement utilisateur, ...) ?
C'est le seul "problème" : en effet, si l'argument est, entre autre, le fait d'avoir un client au top coté réactivité et ergonomie, c'est clairement un problème, d'un autre coté le problème se pose dès le départ et n'est pas nouveau (exemple : face à un client lourd, un client en ligne n'aura que peu d'avantages à part le fait d'être accessible de partout, exemple utiliser l'interface de Zimbra ou Thunderbird+Lightning?)
Enfin, le problème que soulève RMS est réel, mais loin d'être nouveau... cependant, le réel problème n'est pas, à mon avis, de savoir si l'interface en javascript est libre ou pas (si on peut la modifier), mais si l'utilisateur est libre d'utiliser un autre client, pour moi c'est là que réside la réelle privation de liberté et le fait d'utiliser un protocole non standard pour un service "courant" ou de limiter l'accès à ce service à l'interface javascript peut être vécu comme une privation de libertés.
Reste enfin le problème de la contractualité, mais là c'est autre chose.