WebDAV Manager, un client WebDAV ultra-léger en JS

Posté par  (site web personnel, Mastodon) . Édité par palm123 et Ysabeau 🧶 🧦. Modéré par Ysabeau 🧶 🧦. Licence CC By‑SA.
Étiquettes :
51
11
oct.
2022
JavaScript

À l’occasion de mon travail sur l’intégration du protocole WebDAV au gestionnaire d’association Garradin j’ai développé un petit client WebDAV JavaScript permettant avec son navigateur web d’envoyer et télécharger des fichiers, gérer les répertoires, prévisualiser les images et autres fichiers, mais aussi éditer directement des fichiers textes.

L’utilisation principale est d’intégrer directement ce client à votre serveur WebDAV pour proposer une interface web agréable, mais il peut aussi permettre d’utiliser n’importe quel serveur WebDAV depuis son navigateur, sans rien installer (à condition que le serveur WebDAV l’autorise, via les entêtes CORS adéquats, voir la documentation).

Le client permet :

  • création et suppression de répertoires
  • suppression de fichiers
  • création et édition de fichiers textes
  • renommer et déplacer les fichiers et répertoires
  • envoi de fichier depuis le navigateur
  • envoi de fichier par copier/coller
  • envoi de fichier par glisser et déposer
  • prévisualisation dans le navigateur des images, textes, vidéos, fichiers audio, du MarkDown et des PDF
  • prévisualisation du MarkDown lors de l’édition
  • téléchargement des fichiers
  • dispo en anglais et français

Le client ne fait que 8 Ko de JavaScript (gzippé), et n’a besoin d’aucune dépendance, pas de NPM ni rien, juste un fichier JS et un fichier CSS à déposer.

Il a été testé avec mod_dav et NextCloud avec succès.

Aller plus loin

  • # Magnifique !

    Posté par  . Évalué à 4. Dernière modification le 11 octobre 2022 à 11:35.

    De quoi faciliter vraiment la vie pour partager quelques fichiers entre proches…

    Vive les protocoles et les interfaces minimalistes et jolies !

  • # Karadav

    Posté par  . Évalué à 3.

    Il semble que le projet «Karadav» dont tu fait mention dans ton README n'existe plus …

    • [^] # Re: Karadav

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Le repo est privé pour le moment, mais c'est la prochaine annonce dans une semaine ou deux : un serveur WebDAV simple, mais compatible avec les applis NextCloud/ownCloud :)

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Outil similaire

    Posté par  (site web personnel) . Évalué à 2.

    Ça alors ! J'avais justement été surpris de ne rien trouver d'intéressant au moment de créer ma version très similaire de cet outil: https://github.com/club-1/webdav-drive

    Le mien utilise NPM et est en Typescript, mais il est aussi sensé être relativement léger.
    Sinon pour ce qui est du fonctionnement c'est assez similaire. Je n'ai pas encore fait d'interface de prévisualisation ou d'édition mais c'était plus ou moins ce qui était prévu pour le futur. Par contre il y a la possibilité de sélectionner plusieurs fichiers pour appliquer un opération en batch et surtout quelqu'un a contribué une traduction en Norvégien :)

    • [^] # Re: Outil similaire

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Ah je n'étais pas tombé dessus, je rajoute dans le README dans les alternatives merci.

      Oui je me dit que permettre de sélectionner les fichiers ça serait pas mal aussi, je regarderais plus tard.

      Là le but était d'avoir un tout petit truc qu'on puisse intégrer dans n'importe quelle appli qui fasse du WebDAV (ou même juste un mod_dav) pour avoir un truc fonctionnel et agréable sans se prendre le chou :)

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Websocket

    Posté par  (site web personnel) . Évalué à 2.

    Je me demande si on ne pourrait pas remplacer WebDAV par un protocole basé sur les websockets, pour éviter tous ces surcoûts liés aux en-têtes.

    • [^] # Re: Websocket

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      WebDAV est un superbe protocole, très simple mais puissant, et les entêtes ne représentent rien du tout dans la communication, car le listing de répertoire c'est une seule requête (PROPFIND) qui renvoie toutes les infos des fichiers.

      Et… tu peux utiliser HTTP/2 pour compresser les entêtes, mais le gain est ridiculement bas.

      Passer à une usine à gaz proprio genre websockets n'a aucun intérêt :)

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Websocket

        Posté par  (site web personnel) . Évalué à 2.

        Tu as toute la partie authentification, qui peut être particulièrement coûteuse (en particulier avec Kerberos qui impose de doubler les requêtes).

        • [^] # Re: Websocket

          Posté par  . Évalué à 2.

          Plus avec HTTP/2 puis HTTP/3

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Websocket

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Non ça ne coûte rien car on a inventé il y maintenant bien longtemps, un truc bien pratique : les cookies :)

          « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

          • [^] # Re: Websocket

            Posté par  (site web personnel) . Évalué à 2.

            Comment fais-tu avec Kerberos ?

            • [^] # Re: Websocket

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              Je connais pas Kerberos mais 5 minutes de recherche Google me donnent https://github.com/gssapi/mod_auth_gssapi#gssapiusesessions

              qui permet cela exactement: une fois la première auth faite avec login/password, un cookie est envoyé au client, le serveur réutilise ce cookie pour savoir que l'utilisateur est authentifié.

              Simple, basique, fonctionne depuis 1995 :)

              « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Websocket

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Assez d'accord, sauf sur la fin (websocket qui serait proprio)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: Websocket

          Posté par  . Évalué à 4.

          Il parle du protocole au dessus de websocket qui serais ad hoc. C'est propriétaire au sens pas issue d'une normalisation, mais dédié à un logiciel.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Websocket

            Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 12 octobre 2022 à 00:25.

            Formulé comme ça, ça fait sens en effet. (:

            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Websocket

            Posté par  (site web personnel, Mastodon) . Évalué à 1.

            Absolument, WebDAV est un standard (très) bien supporté, documenté. Réinventer la roue par dessus WebSocket ne ferait que créer un nouveau truc pas interopérable et inutile.

            Un peu comme le protocole WOFI de Microsoft, qui ne fait que réinventer WebDAV, en moins bien, en plus compliqué, pour faire du faux-REST. C'est ce qui est utilisé pour ouvrir/enregistrer des documents dans Collabora/OnlyOffice/MS Office Online, et c'est nul :)

            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

            • [^] # Re: Websocket

              Posté par  (site web personnel, Mastodon) . Évalué à 4.

              tu voulais sans doute écrire WOPI.

              Le protocole est beaucoup moins puissant que WebDAV à ma connaissance, mais aussi beaucoup plus simple à exploiter.

              WebDAV a le défaut d'être implementable de différentes façons, ce qui fait qu'on peut difficilement faire reposer des process dessus.

              Exemple : dans Tracim on historique les contenus, y compris quand on déplace un fichier (tu gardes l'historique du fichier). L'interface WebDAV propose aussi ce mécanisme. Mais certains clients ont eu la bonne idée d'implémenter le couper-coller comme une suppression-création et d'autres font un "move", ce qui engendre des comportements inattendus et surtout hétérogènes.

              C'est pas la faute du protocole fondamentalement, mais qqchose de pas assez cadré laisse la porte ouverte …

              • [^] # Re: Websocket

                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                Qu'est-ce qui est plus simple ?

                WebDAV il faut juste savoir faire du HTTP, tu peux tout utiliser avec juste curl, ou même telnet :)

                WOPI, il faut du HTTP et du JSON, gérer tout un tas de trucs, d'états etc.

                Clairement WebDAV est beaucouppppp plus simple ! Je teste mon serveur WebDAV avec quelques commandes curl et c'est suffisant.

                curl -X PUT https://webdav.server/dir/file.txt -d @~/file.txt

                pour envoyer un fichier on ne peut pas faire plus simple :)

                curl -X MOVE -H 'Destination: https://webdav.server/dir/file2.txt' https://webdav.server/dir/file.txt

                Pour déplacer. Etc.

                Je trouve que c'est un super protocole : simple, facile à comprendre, facile à implémenter et à utiliser, qui construit sur des standards existants. Par exemple tu veux juste un bout d'un fichier, ben tu utilise Content-Range :

                curl -H 'Content-Range: bytes 10-20/*' https://webdav.server/dir.file.txt

                Bref c'est super, si on met de côté les bordels de CalDAV/CardDAV qui sont à part.

                Que des clients d'un protocole soient nazes c'est possible mais il faut alors remonter les bugs.

                Le bug que tu mentionne est dans GVFS (GNome) et corrigé depuis 2014 il semble : https://bugzilla.gnome.org/show_bug.cgi?id=572786

                Et rien n'interdit avec WOPI de faire un deleteFile puis un putFile, même souci :)

                « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                • [^] # Re: Websocket

                  Posté par  (site web personnel, Mastodon) . Évalué à 4.

                  WebDAV c'est aussi des données XML …

                  Est-ce que WOPI est mieux ? C'est pas vraiment ce que je pense. Ce que je pense, c'est que mettre du WebDAV entre les mains d'utilisateurs c'est du temps de support garanti car les navigateurs de fichiers gèrent le protocole*mais pas tout à fait* et même chacun un peu comme il veut

                  • [^] # Re: Websocket

                    Posté par  (site web personnel, Mastodon) . Évalué à 3.

                    WebDAV n'utilise du XML que pour lister les fichiers.

                    Je comprends pas cette aversion à XML, c'est un format ouvert, il y a des parsers partout, de quoi valider que ce que tu reçois correspond à ce que tu attends (via XML Schema), c'est assez simple à utiliser (aller, environ 4 lignes de code en PHP pour parser la liste des fichiers avec WebDAV).

                    Mais si tu ne propose pas du WebDAV, ça veut dire que tu ne permet pas à tes utilisateurs de récupérer les fichiers, comme ils le veulent, avec l'OS qu'ils veulent, donc le besoin n'a rien à voir :)

                    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                    • [^] # Re: Websocket

                      Posté par  . Évalué à 0.

                      Mais si tu ne propose pas du WebDAV, ça veut dire que tu ne permet pas à tes utilisateurs de récupérer les fichiers, comme ils le veulent, avec l'OS qu'ils veulent, donc le besoin n'a rien à voir :)

                      Je comprends pas. HTTP n'a pas besoin de webdav pour télécharger des fichiers.

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: Websocket

                        Posté par  . Évalué à 1.

                        WebDAV étend les possibilités offertes par HTTP. D'après la page Wikipedia listée dans la dépêche, il permet par exemple de gérer les droits d'accès et dispose d'un mécanisme de verrouillage pour prévenir les conflits d'écriture. Et à travers son système d'extensions, il propose d'autres outils tels que la gestion des méta-données et des versions.

                        • [^] # Re: Websocket

                          Posté par  . Évalué à 0. Dernière modification le 14 octobre 2022 à 14:00.

                          Ah oui oui, mais il parlait de récupérer des fichiers.

                          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                          • [^] # Re: Websocket

                            Posté par  (site web personnel, Mastodon) . Évalué à 2.

                            C'est lié…

                            gérer les droits d'accès

                            “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                            • [^] # Re: Websocket

                              Posté par  . Évalué à 2.

                              C'est vrai qu'on a oublié de faire de l'authentification dans HTTP ⸮

                              Je rappel la phrase qui m'a fait tiquer :

                              Mais si tu ne propose pas du WebDAV, ça veut dire que tu ne permet pas à tes utilisateurs de récupérer les fichiers, comme ils le veulent, avec l'OS qu'ils veulent, donc le besoin n'a rien à voir :)

                              Tu peux parfaitement permettre aux utilisateurs de récupérer leurs fichiers en HTTP pur. Oui il y a moins de fonctionnalités, mais ce n'est pas de l'enfermement.

                              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                              • [^] # Re: Websocket

                                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                Oui, on est d'accord que HTTP pur n'est pas de l'enfermement (: Mais c'est plus limité pour gérer des accès fins : Tu vas faire du Basic-Auth certes mais par répertoire et c'est lourd à gérer quand tu dois en gérer plusieurs avec des accès différents. À l'inverse, WebDAV te permet de lister le répertoire sans pouvoir lire/télécharger les fichiers, et tu peux mettre en place des droits différents avec moins de prise de tête (un peu comme si tu exposes de façon transparente ton système de fichiers.) La réponse qui t'a été faite va plus loin que la phrase qui t'a fait tiquer au départ…

                                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                              • [^] # Re: Websocket

                                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                                Je parlais d'un protocole de gestion de fichiers, donc : lister, récupérer, modifier, supprimer les fichiers. Ouvrir un service avec du WebDAV permet de jolies choses pour les utilisateurs, alors que si tu fait un protocole proprio qui ne fonctionne qu'avec ton app client à toi, c'est 1. perdre du temps à réinventer un truc qui marche et 2. enfermer les utilisateurs dans une logique proprio :)

                                Je ne compare pas avec permettre un accès en GET en HTTP, évidemment que c'est toujours bien comme truc et que ça n'enferme pas, mais ce n'est pas ce dont je parlais :)

                                « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                    • [^] # Re: Websocket

                      Posté par  (site web personnel, Mastodon) . Évalué à 2.

                      Mais si tu ne propose pas du WebDAV, ça veut dire que tu ne permet pas à tes utilisateurs de récupérer les fichiers, comme ils le veulent, avec l'OS qu'ils veulent, donc le besoin n'a rien à voir :)

                      Tracim le propose. Mais c'est compliqué à exploiter au quotidien, sauf dans une démarche simple récupération ou envoi de fichiers.

                      L'historique géré dans Tracim est mis à mal avec WebDAV.

                      • [^] # Re: Websocket

                        Posté par  (site web personnel, Mastodon) . Évalué à 2.

                        Qu'est-ce qui est compliqué ?

                        Et en quoi c'est mis à mal, à part le bug de GVFS de 2014 ?

                        Je ne comprends pas trop le souci, pour faire aussi du WOPI, c'est la même chose, chaque modification de fichier implique une réécriture complète du fichier, derrière c'est au serveur de gérer le versionnement à coup de diff.

                        Il y a des clients qui font des PUT à 0 octets avant d'envoyer le vrai contenu du fichier, il suffit d'ignorer ces PUT lors du versionnement. Ce genre de comportement est détaillé dans l'auto-versionnement proposé par SVN (basé sur WebDAV) : https://svnbook.red-bean.com/en/1.7/svn.webdav.autoversioning.html

                        Il existe d'autres serveurs WebDAV qui font de l'auto-versionnement un peu plus malin.

                        Mais je suis curieux de savoir ce qui pose souci chez Tracim en particulier :)

                        « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                        • [^] # Re: Websocket

                          Posté par  (site web personnel, Mastodon) . Évalué à 4.

                          En fait les deux protocoles ne sont pas comparables dans l'usage :

                          • WebDav c'est accédé par les clients et donc il faut développer une robustesse à l'ensemble des clients qui exploitent le protocole. Mettre en place le mécanisme de versionning qui analyse les requêtes WebDAV c'est implémenter un mécanisme de transaction pour traiter les différents cas de figure qui peuvent intervenir en 1 ou plusieurs requêtes HTTP. C'est super, c'est intéressant, mais vu l'utilisation de WebDAV on a meilleur temps de dépenser notre énergie ailleurs
                          • WOPI c'est utilisé pour interconnecter Collabora Online. C'est utilisé entre des briques serveur, c'est un environnement maîtrisé. Le coût d'implémentation ? 4 endpoints d'Api (avec grosso modo 2 semaines d'exploration initiale pour s'approprier le protocole). Ça marche.

                          Si tu veux faire du WebDAV, fais. Si tu veux gagner de l'argent, fais un calcul de coût et de rentabilité et peut être que tu utiliseras WebDAV, peut-être pas.

                          • [^] # Re: Websocket

                            Posté par  (site web personnel, Mastodon) . Évalué à 1.

                            WOPI oui c'est une utilité différente, je parlais juste de ça car c'est très clairement un mauvais WebDAV, par exemple au lieu de faire un PUT, on fait un POST en indiquant que c'est un POST dans un header proprio (WTF). Mais oui c'est pas bien compliqué, mais comme WebDAV en fait :) en 2 jours j'avais lu la spec et implémenté le protocole pour que ça marche :)

                            WebDAV est un standard qui permet à tes utilisateurs⋅trices de ne pas rester enfermer dans ton environnement web, et de se réapproprier leurs données. Du coup c'est dommage de considérer que la liberté des utilisateurs⋅trices ne vaut pas les quelques heures passées à leur permettre de choisir la méthode d'accès à leurs données (en plus des avantages de pouvoir gérer les fichiers dans un environnement natif local, et pas une interface séparée).

                            Après chacun ses choix, mais je n'ai pas l'impression personnelle que prendre en compte les quelques défauts de certains clients WebDAV est plus long que discuter de tout ça sur LinuxFR ;)

                            Après quand j'aurais implémenté le versionnement je dirais peut-être pas la même chose héhé :)

                            « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

                            • [^] # Re: Websocket

                              Posté par  . Évalué à 3.

                              Après chacun ses choix, mais je n'ai pas l'impression personnelle que prendre en compte les quelques défauts de certains clients WebDAV est plus long que discuter de tout ça sur LinuxFR ;)

                              Je pense que tu sois estime grandement le travail que ça représente. Tu dois créer une heuristique, être en mesure de déduire ses choix après coup pour pouvoir aider tes utilisateurs, tu va devoir la tester sur un paquet d'implémentations sur différents os voir différentes versions tout ça pour un truc qui aura pleins de cas aux limites (git n'a pas de sémantique de move dans les patch et tu perds facilement la continuité).

                              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Quelques améliorations d'UI/UX

    Posté par  . Évalué à 2.

    Si tu affiches l'extension sous forme d'icônes, alors il ne sert à rien de la répéter dans le nom du fichier.
    Aussi, je suppose que chaque fichier étant représenté comme un lien, en cliquant dessus on le télécharge ?
    Si oui, le bouton Download ne sert à rien.
    Le bouton Rename ou Delete devrait utiliser des icônes. Idéalement, ces icônes ne doivent pas être visible par défaut car ce sont des actions "à effet", il faudrait 2 clics pour effacer un fichier ou le renommer. Peut être en mettant ces icônes dans une sorte de menu accordéon, ça pourrait le faire.

    Regarde un peu ce genre d'interface:
    https://tinyfilemanager.github.io/demo/
    https://filegator.io/
    https://filerun.com/demo
    https://larsjung.de/h5ai/demo/header%20and%20footer/
    https://www.filestash.app/ (en mode liste)

    • [^] # Re: Quelques améliorations d'UI/UX

      Posté par  (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 12 octobre 2022 à 11:00.

      1. Extension répétée : tu peux via la CSS ne pas afficher l'extension dans l'icône, mais une icône visuelle, donc utile de garder l'extension dans le nom de fichier :)
      2. Quand on clique sur un fichier ça le prévisualise si c'est un type prévisualisable, sinon ça le télécharge, donc le bouton Download sert bien à quelque chose :) Et on ne le cache pas pour les fichiers non-prévisualisables sinon les utilisateurs se demanderaient pourquoi ces fichiers ne sont pas téléchargeables :)
      3. Les actions sont à confirmer via un dialogue de confirmation. Les menus accordéons sont une horreur d'UX, les gens ne savent pas ce que c'est. Les icônes seules c'est pareil, rien ne vaut le texte.

      Ça fait 10 ans que je fait des interfaces adaptées aux personnes peu à l'aise avec l'informatique, donc je commence à avoir quelques idées sur ce qui marche et ce qui ne marche pas, mais merci des suggestions :)

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

      • [^] # Re: Quelques améliorations d'UI/UX

        Posté par  . Évalué à 4.

        Si je peux faire une suggestion, les fichiers semblent trié par ordre alphabétique, je pense que par date et par taille peut aussi être utile quand tu veux faire de la place dans ton dossier.

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # une petite suggestion

    Posté par  (site web personnel) . Évalué à 4.

    Si tu pouvais rajouter le fait de pouvoir dropper les fichiers directement dedans, c'est normalement pas très compliqué à mettre en place (pour l'avoir déjà fait).

    De souvenir, c'est plus ou moins cette doc :
    https://developer.mozilla.org/en-US/docs/Web/API/HTML_Drag_and_Drop_API/File_drag_and_drop

    • [^] # Re: une petite suggestion

      Posté par  (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 13 octobre 2022 à 21:51.

      C'est déjà fait, c'est dans la liste des fonctionnalités en plus ;)

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Mode d'emploi ?

    Posté par  . Évalué à 2.

    Bonjour,

    J'ai Nextcloud d'installé sur Yunohost, où dois-je placer les fichiers ?

    Merci.

    arnauld

    • [^] # Re: Mode d'emploi ?

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Avec Apache et NextCloud je fait comme ceci :

      • tu télécharge index.html, webdav.js et webdav.css
      • dans index.html tu marque /remote.php/dav/files/bohwaz/ dans l'attribut data-webdav-url du tag html
      • tu met les 3 fichiers dans un répertoire genre /var/www/webdav-manager
      • tu configure Apache comme ceci (dans le VirtualHost de NextCloud) :
          Alias /webdav-manager/ /home/bohwaz/git/webdav-manager.js/

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} GET
        RewriteCond %{HTTP:Authorization} .
    RewriteRule "remote.php/dav/files/?.*/$" /webdav-manager/ [L,PT]

      Je viens de tester avec nginx qu'utilise Yunohost et j'ai l'impression que ce n'est pas possible de faire la même chose, nginx est trop limité :(

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # swift

    Posté par  . Évalué à 1.

    Super !

    Et quelque chose d'identique pour Openstack Swift serait tout aussi désirable.

    • [^] # Re: swift

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Pas prévu :)

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.