février
2011
Un article de benwit
Vous connaissez surement le champ d’upload de fichier des navigateurs web.
Certains mettent le nom complet du fichier (avec son chemin),
d’autre le nom court du fichier pour des raisons de sécurité (Le serveur n’a pas besoin de savoir où se trouve le fichier sur le client).
Jusque là, tout va bien.
Mais il se trouve que des **** du W3C ont décidé dans la spécification HTML5 de préfixer le nom de fichier par « C:\fakepath\ » !
Pourquoi cette résolution est mauvaise ? Comment la contourner ?
Pourquoi cette résolution ?
A priori, à cause d’appareils intermédiaires (proxy…) qui n’accepterait que des chemins de type Microsoft, à cause de feignants ou d’incapables qui craignent que leur misérable infrastructure ne fonctionne plus !
Pourquoi cette résolution est débile ?
1) Masquer le chemin sur le client pour des raisons de sécurité, oui mais pas le remplacer par ce préfixe débile !!!
2) Le chemin affiché dans le champs upload « C:\fakepath\fichier » va faire peur à certains utilisateurs
3) La valeur affichée n’est même pas forcément celle envoyée ! L’excuse de l’appareil intermédiaire sur le réseau est donc bidon !
4) Ce chemin « C:\fakepath\fichier » sera même affiché sur des client linux. Le comble !
Comment contourner cette résolution ?
1) Mettre tout en œuvre, pétitions, etc… pour qu’elle soit retirée des spécifications finales.
Ceci dit, j’ai des doutes vu que c’est déjà implémenter par Chrome 8 (vous pouvez donc faire le test sous linux !)
2) Proposer des alternatives comme ceux qui proposent que les boulets qui craignent pour leur misérable infrastructure gèrent eux mêmes leurs éventuels problèmes par configuration.
3) Être plus zen comme ceux qui disent que les nouvelles API de fichier de HTML 5 masqueront cette horreur. Certes mais l’API File est loin d’être encore implémentée aussi largement.
4) Utiliser des librairies JS qui masquent le champs file upload html natif pour diverses raisons, notamment la différence d’uniformité entre les navigateurs (champs + bouton « browse » dans la plupart, bouton « browse » plus libellé dans chrome, …)
Comment contourner cette résolution avec GXT ?
GXT a heureusement uniformisé la présentation du file upload en masquant le composant html natif.
Malheureusement, ils ont oublié au passage de masquer l’horreur du W3C.
Voici donc comment faire si vous utilisez GXT :
class FileUploadFieldWithoutFakepath extends FileUploadField
{
private static final String FAKEPATH = "c:\\fakepath\\";
@Override
protected void onChange(ComponentEvent ce)
{
String filepath = getFileInput().getValue();
if (filepath != null && filepath.trim().toLowerCase().startsWith(FAKEPATH))
setValue(filepath.substring(FAKEPATH.length()));
else
setValue(filepath);
}
}
[…] Comment contourner une débilité du W3C avec GXT ? par benwit (23/02/2011 17:52) Vous connaissez surement le champ d’upload de fichier des navigateurs web. Certains mettent le nom complet du fichier (avec son chemin), d’autre le nom court du fichier pour des raisons de sécurité (Le serveur n’a pas besoin de savoir où se trouve le fichier sur le client). Jusque là, tout va bien. Mais il se trouve que des **** du W3C ont décidé dans la spécification HTML5 de préfixer le nom de fichier par « C:fakepath » […] […]
Le problème c’est que tu n’arriveras pas à imposer un outil qui serait incompatible avec l’existant. Ici Chrome se calque clairement sur le comportement d’Internet Explorer.
C’est malheureux mais tout le monde se fout du respect des standards du moment que ca marche… Va convaincre un manager de changer de navigateur si cela l’oblige à renouveller ou modifier toutes ses applications Web !
Cette optique n’est pas si mauvaise en soit. Cela permet d’utiliser un navigateur récent avec l’existant. Sans cela je suis sûr que la part d’IE6 serait encore plus importante.
Si on veut se débarrasser d’IE6 il faut malheureusement en passer par là, car les sites « optimisés pour IE6″ ne disparaitront pas aussi vide…
a++
Oui pour l’aspect pragmatique mais je pense néanmoins qu’il arrive un moment où on peut (doit ?) dire stop.
Exemple : Des sites d’entreprises n’ont été développés que pour IE6 donc les nouvelles applications doivent être compatibles IE6 et avec cette boucle vicieuse, on se retrouve 10 ans plus tard à utiliser un navigateur que même son éditeur recommande de mettre à jour.
Je pense qu’on peut être courageux et essayer de casser la boucle.
Exemple : Cette nouvelle application devra être utilisée sous firefox (ou chrome).
Alors, effectivement, cela apporte de l’hétérogénéité (deux navigateurs à gérer pendant un laps de temps). On ne parle d’urbanisation des S.I pour rien !
Surtout qu’en entreprise, il est en théorie plus facile d’imposer des outils.
Dans le web public, il faut être en effet courageux et accepter de perdre des clients au moment où on se rend compte qu’on fait 80% d’efforts pour 20% d’entre eux.
Ce ne sont pas des décisions faciles à prendre. La compatibilité est un critère comme un autre, il faut juste bien déterminer la valeur qu’on souhaite lui donner.
Je ne critiquerai jamais quelqu’un qui est conscient des alternatives et qui fait le choix d’être pragmatique pour les buts qu’il vise.
Ceci dit, c’est parfois révélateur d’un état d’esprit qui frise au conformisme étroit.
Ce n’est pas aussi évident…
Cela peut être complètement aberrant mais il faut parfois « implémenter » des bugs ou des comportements « hors-normes » pour assurer une meilleure compatibilité.
Je ne parle pas ici d’un HTML 5 tout propre tout beau mais de compatibilité avec l’existant. Surtout si tu veux t’imposer dans le monde de l’entreprise !
Tu peux avoir un navigateur qui correspondent au top du top du respect des standards, mais si ce dernier ne fonctionne pas avec l’intranet d’une entreprise tu va avoir du mal à convaincre… même si le problème vient de l’intranet et non pas du navigateur !!!
Firefox avait eu des problèmes similaires au début, à causes de son moteur de rendu trop respectueux des standards, ce qui était incompatible avec un grand nombre de site de l’époque conçus pour IE5/IE6. Ils avait dû introduire un mode de rendu « quirks » qui reproduisait le même comportement.
Malheureusement on ne peut pas faire grand chose contre cela, à moins de migrer/corriger tous les navigateurs du monde et tous les sites internet/intranet du monde…
a++
adiGuba, merci pour ton commentaire,
Il m’a obligé à relire le brouillon de spécification du W3C.
Effectivement, aujourd’hui, avec tes yeux et à tête reposée, je vois les choses un peu différemment concernant mon accusation sur ce fait en particulier (le fond du problème restant le même).
La spécification ne reste qu’une spécification et on peut déporter la responsabilité de suivre ou non des recommandations au niveau des implémentations. Ce n’est pas la première fois que certaines seront suivies ou non.
Ayant rencontré ce problème sous Chrome (windows et linux), j’ai rapidement recherché l’origine et je me suis laissé influencer par un commentaire disant que les développeurs ne faisaient que suivre la spécification pour des raisons de compatibilité.
Après avoir relu le texte, on n’a qu’à dire que mon énervement est plus profond et est lié à tous ces ronds de cuir qui prennent des décisions par incompétences ou par intérêt financier. L’informatique regorge de systèmes faits de brics et de brocs … Des claviers AZERTY et QWERTY hérités de l’époque des machines à écrire et conçus pour ralentir notre frappe, des ports obsolètes qu’on a traîné sur des PC récents, des applications web développées initialement sur un protocole sans état conçu pour des documents …
Salut,
Je ne vois pas où les spécifications HTML5 oblige l’utilisation de ce préfixe !? Perso je lis plutôt une note concernant les implémentations actuelles des navigateurs (et IE en particulier), avec un exemple de code permettant de gérer proprement tous les cas…
Le problème c’est que ces erreurs de jeunesse sont tellement utilisés qu’on ne peut pas forcément s’en passer aussi facilement.
a++
Merci pour cette réponse. J’espère qu’elle sera lue par ceux qui peuvent changer les choses mais qui n’osent pas.
Tu as tout a fait raison.
Il aurait été plus propre de faire un nouveau standard bien conçu, plutôt que d’essayer de réviser le HTML. Parce que la, si j’ai bien compris, si on upload le fichier « /etc/passwd », il va mettre « c:fakepath/etc/passwd », et le proxy ne va pas bloquer.
Quand je voie le protocole DNS (impossible a bien sécuriser), les protocoles smtp/pop (impossible de bloquer correctement les spams), le protocole FTP qui n’est toujours pas standarisé (et qui gère très mal le transfert d’une arborescence avec beaucoup de sous répertoire), le protocole http qui devrait être plus stricte pour éviter les attaques, et consort, il est temps de tout remettre à plat. Il devrait y avoir un moyen simple pour distinguer les envoie de fichier par formulaire légitimes, des transferts de fichiers pirates. ce moyen de distinction devrait être à temps constant, pour éviter les DDOS.
Au lieux de ça, les acteurs de l’internet mettent le paquet pour que leurs logiciels fonctionnent avec les techno web défaillantes (gmail, Office Web Apps, etc…). Un jour il y aura des catastrophes pour les particuliers, et ont leur répondra « c’est pas moi, c’est la faute à pas de chance ». C’est pas une question de chance, mais plutôt du manque de courage de ceux qui décident des protocoles à utiliser pour l’internet.
Quand quelque chose doit duré longtemps, et qu’il y a un problème de conception des le départ, il faut le corrigé le plus tôt possible, quitte a ce qu’il y ait des incompatibilités au début. C’est vrai au niveau logiciel, mais aussi au niveau des standards. IPV6, par exemple, a été conçu des les années 90, bien avant qu’il y ai la pénurie d’adresse IPV4.