1/ Que ce soit d'un point de vue développement comme d'un point de vue UX, qu'apporte l'utilisation d'un websocket par rapport à un XMLhttpRequest plus classique comme le fait jirafeau ?
Voir ma réponse à @stopspam haut dessus. La connexion n'est jamais coupée, donc je renvoie plus rapidement puisque je ne réinitialise pas la connexion (je crois qu'il y a maintenant une réutilisation des connexions déjà utilisées pour pallier ce genre de problème, mais je n'ai pas creusé).
Pour l'UX, bah, du coup ça doit faire gagner quelques pouhièmes de seconde.
Sinon, le développement côté serveur a été vraiment très simple grâce à l'utilisation des Websockets (même si ça n'aurait pas été dur de faire ça pour de l'Ajax classique). J'ai bien aimé :-)
2/La question qui revient sans cesse concernant le chiffrement au travers du web, c'est l'incapacité de s'assurer de l'identité du code JavaScript qui va prendre en charge ce chiffrement, en particulier en cas d'interception du flux de données entre le client et le serveur par des tiers. Si on fait confiance au serveur utilisé, comme cela est a priori le cas chez framasoft, ne vaut il mieux pas laisser celui-ci s'occuper du chiffrement en lui faisant confiance pour oublier la clé ? Question candide d'un béotien du chiffrement...
Quand j'ai fait Lutim avec chiffrement côté serveur, on m'a fait la remarque inverse :p Tu fais confiance à Framasoft, soit, Mais si le serveur se fait poutrer, celui qui est sur le serveur a les clés. Là, même si le serveur est compromis, ce n'est pas grave, les fichiers restent illisibles.
Si le code javascript est compromis, il y a quand même plus de chances que quelqu'un s'en aperçoive que si c'est le serveur qui est compromis, puisque le javascript est lisible par chaque utilisateur. Côté serveur, il n'y a que les admins qui peuvent s'en rendre compte.
3/ Pourquoi envoyer des méta données non chiffrées telles que le nom du fichier, sa taille et son mime type, plutôt que de stocker cela dans le LocalStorage, n'envoyer qu'un hash au serveur, et fournir ces informations via l'ancre de l'URL avec la clé pour les destinataires potentiels ?
Taille : le serveur en a besoin pour savoir :
si la taille ne dépasse pas la taille autorisée
s'il y a suffisamment de place sur le serveur pour accueillir le fichier
quel limitation de délai appliquer
Nom du fichier et mimetype : le javascript de récupération en a besoin pour reconstruire un fichier avec un nom compréhensible et un mimetype correct. Alors oui, éventuellement, je pourrais chiffrer ça dans l'ancre. Faudrait voir comment faire ça proprement.
Merci pour cette nouvelle contribution !
Je t'en prie :-)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Questions d'un curieux
Posté par Framasky (site web personnel) . En réponse à la dépêche Un nouveau logiciel libre : Lufi. Évalué à 10.
Voir ma réponse à @stopspam haut dessus. La connexion n'est jamais coupée, donc je renvoie plus rapidement puisque je ne réinitialise pas la connexion (je crois qu'il y a maintenant une réutilisation des connexions déjà utilisées pour pallier ce genre de problème, mais je n'ai pas creusé).
Pour l'UX, bah, du coup ça doit faire gagner quelques pouhièmes de seconde.
Sinon, le développement côté serveur a été vraiment très simple grâce à l'utilisation des Websockets (même si ça n'aurait pas été dur de faire ça pour de l'Ajax classique). J'ai bien aimé :-)
Quand j'ai fait Lutim avec chiffrement côté serveur, on m'a fait la remarque inverse :p Tu fais confiance à Framasoft, soit, Mais si le serveur se fait poutrer, celui qui est sur le serveur a les clés. Là, même si le serveur est compromis, ce n'est pas grave, les fichiers restent illisibles.
Si le code javascript est compromis, il y a quand même plus de chances que quelqu'un s'en aperçoive que si c'est le serveur qui est compromis, puisque le javascript est lisible par chaque utilisateur. Côté serveur, il n'y a que les admins qui peuvent s'en rendre compte.
Je t'en prie :-)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.