WebDAV

18.12.2014 14:20 | Přečteno: 2462× | Za vším hledej Linux | | poslední úprava: 18.12.2014 14:40

Před několika dny se ve zdejší linuxové poradně objevil dotaz, který lze přeformulovat zhruba takto: Jak nastavit v konfiguraci Apache WebDAV, aby se přes jedno URL dostal uživatel po přihlášení vždy jen a pouze do svého adresáře? Zaujalo mne to, protože z mého pohledu je WebDAV v současné době snad jediné multiplatformí řešení, vhodné pro sdílení dat, které se obejde bez cloudových služeb velkých společností.

WebDAV je - na rozdíl od protokolů síťových souborových systémů, pouhé rozšíření HTTP protokolu o metody, které umožňují jeho prostřednictvím přenášet po síti soubory také zpět na server. Porty 80 (HTTP) a 443 (HTTPS) jsou na rozdíl od portů, přes které fungují jiné komunikační protokoly, obvykle průchozí, aby se uživatelé mohli z vnitřní sítě dostat na webové stránky. Proto lze přes WebDAV pracovat se soubory i přes relativně striktně nastavený firewall nebo proxy.

Požadavek, aby uživatelé mohli své stránky na serveru rovnou upravovat, byl ostatně také za tím, proč vlastně WebDAV vzniknul. S touto možností se u webu počítalo od samého počátku, jenže od myšlenky byla k funkční implementaci ještě dlouhá cesta. Zatím, co první verze HTTP protokolu s číslem 0.9 byla zveřejněna r. 1991, tak první konkrétní návrh jeho rozšíření o metody s nimiž pracuje současný WebDAV učinil až r. 1996 Jim Whitehead. Do té doby, než byl implementován WebDAV, se nejčastěji upravené soubory uploadovaly na server prostřednictvím FTP klienta.

FTP protokol, určený k síťovému přenášení souborů, je starší než HTTP protokol. Jeho návrh pochází z r. 1986 - z doby, kdy magoři neměli ještě o internetu a možnostech jeho zneužití ani ponětí. Veškerá data se jím přenášela v čitelné podobě - včetně přihlašovacích údajů, takže případnému škůdci stačilo kdekoliv po trase odchytit dostatečné množství paketů a pak v nich tyto údaje vyhledat.

V dřevních dobách webových byl editor webových stránek součástí některých prohlížečů. K přenosu souborů z klientské stanice na server zpočátku používaly pouze FTP jehož specifikace byla r. 1997 rozšířena o přidaní bezpečnostní prvky. Teprve zhruba od r. 2003 se začala objevovat alternativní možnost využít pro upload souborů také WebDAV. Ovšem v té době už měla integrovaný wysiwyg editor pouze Mozilla - poslední verze, která ještě obsahovala editor (1.7.13) byla vydaná na jaře 2008.

Wysiwyg editace HTML stránek byla použitelná pouze pro správu statického webu, ale internetový boom v závěru 20. století vynesl do popředí weby se stránkami s dynamicky generovaným kódem, jejichž finální podoba závisela na renderovacím jádru webového prohlížeče. Pro editaci jejich kódu se víc hodily specializované textové editory, než wysiwyg editory jako byla Amaya, Frontpage nebo editor v Mozille.

Na rozdíl od staršího FTP, nabízel přístup k souborům přes WebDAV jen málokterý webhosting. Většina uživatelů byla zvyklá používat FTP klienta, takže o něj ani nijak zvlášť neměla zájem.

WebDAV se stal zajímavou alternativou až s nástupem chytrých mobilních zařízení s trvalým přístupem s internetové síti. A to pro svůj potenciál využitelný ke sdílení uživatelských dat mezi pracovní stanicí a mobilním telefonem.

HTTP protokol s rozšířením pro WebDAV je ve své podstatě podobně otevřený protokol jako FTP, ale s rostoucími nároky na bezpečnost šla ruku v ruce implementace SSL šifrování na komunikace mezi serverm a klientem, takže v tomto případě nebylo nutné - na rozdíl od FTP - řešit problém se zabezpečením komunikace modifikací specifikace protokolu. Pokud operační systém zařízení umí šifrovat síťovou komunikaci přes SSL, není problém se zabezpečením komunikace klienta pro WebDAV. Takže dnes existují aplikace, které umí integrovat adresáře sdílené přes WebDAV do systému prakticky pro všechny v současné době používané platformy - včetně těch mobilních.

WebDAV server

Abychom mohli soubory přes WebDAV sdílet, je třeba mít k dispozici server, který takto rozšířenému HTTP protokolu rozumí. Pokud někomu stačí jednoduchý server, určený pouze ke sdílení souborů, může použít WsgiDAV, ovšem pro řešení zadání, jaké je v perexu tohoto blogpostu je vhodnější použít Apache.

Moje zkušenosti s využitím WebDAVu dosud nebyly nijak velké. Poprvé jsem si s ním hrál zhruba před osmi lety. Viz můj blogpost z r. 2006. Tehdy bylo pro mě podstatné především to, že skrze něj bylo možné protlačit soubory na server ve vnější síti i přes poměrně striktně a navíc idiotsky nastavenou proxy.

Pak ho jeden čas ho využívalo několik našich uživatelů ke vzdálenému přístupu do sdíleného pracovního adresáře. Ale protože stejný server poskytoval zároveň i webové služby, raději jsme od toho ustoupili. Sdílený prostor, dostupný přes WebDAV, který je zároveň publikován přes stejný server jako normální web - byť s autorizovaným přístupem - totiž představuje potencionální problém.

Server přes který publikujeme uživatelské adresáře, si totiž tehdy ještě nevynucoval komunikaci přes SSL, takže hrozila potencionální kompromitace přihlašovacích údajů. Škůdce, který by z odchycené komunikace vypreparoval přihlašovací údaje, mohl uploadovat nenápadný php skript, jehož zavoláním odněkud z webu - bylo možné kdykoliv zaškodit, ne-li rovnou sejmout celý stroj.

WebDAV server s podporou uživatelských adresářů

WsgiDAV je WebDAV server, napsaný v Pythonu, který podporuje SSL a může komunikovat na libovolném rozhraní a portu. Rovněž umožňuje nakonfigurovat pro každého uživatele samostatný adresář. Pro Debian sice není k dispozici žádný instalační balíček, ale instalace a konfigrace je poměrně triviální.

Narazil jsem na něj dřív než se mi podařilo dojít u Apache k funkční konfiguraci. Nicméně to nebylo řešení, jaké jsem hledal, protože co uživatel, to unikátní URL. Navíc, pokud by server naslouchal na standardním portu 443, tak by již nebylo možné používat normální webový server.

WebDAV s podporou dynamicky mapovaných uživatelských adresářů

Bylo jasné, že pro dynamické mapování adresářů přes jedno URL je třeba využít Apache, který musí mít kromě modulů mod_dav a mod_davfs zaveden také modul mod_rewrite, který umožňuje aplikovat na volané URL pravidla, jimiž lze dynamicky měnit cestu do cílového adresáře.

Úspěšná autentifikace je nezbytnou podmínkou k tomu, aby mohla být správně interpretovaná absolutní cesta do uživatelského adresáře, neboť v pravidle pro mod_rewrite se pracuje s obsahem proměnné REMOTE_USER, což je uživatelské jméno přihlášeného uživatele.

Tento uživatel přitom vůbec nemusí existovat v operačním systému serveru. Pochopitelně lze použít autentifikační mechanismus, který umí ověřit uživatele vůči lokálnímu účtu, ovšem z bezpečnostního hlediska je to hovadina, neboť by tím při eventuální kompromitaci přihlašovacích údajů získal potenciální útočník přístup ke konzoli, což by jenom zvyšovalo riziko, že bude stroj nabourán.

Pro autentifikaci uživatelů je tedy lepší využít nějaký jiný mechanismus. Optimální je využít LDAP, ale pro menší skupinu uživatelů je zbytečné rozjíždět vlastní LDAP server, když bohatě postačí, podobně jako při testování, basic ověření uživatelského jména a hesla vůči souboru spravovanému přes utilitu htpasswd.

Z hlediska bezpečnosti je mnohem důležitější aby byla komunikace mezi klientem a serverem šifrovaná přes SSL, než to jaký je použit autentifikační mechanismus. Kvůli zjednodušení však následujícím příkladu uvádím ukázkovou konfiguraci pro nešifrovanou komunikaci!

Vytvoření souboru s hesly

Kde a s jakým jménem bude soubor s hesly uložen, je vcelku jedno. Musí být splněna pouze ta podmínka, že uživatel, pod kterým běží webový server z něj bude moci číst. Utilita htpasswd, kterou lze použít k jeho vytvoření je v Debianu součástí instalačního balíčku apache2-utils

htpasswd -c -m /etc/dav/htpasswd.setup user1
htpasswd -m /etc/dav/htpasswd.setup user2
...

Pozn.: V uvedeném příkladu jsem vnutil parametrem -m použití MD5 algoritmu, protože jsem stejný soubor používal i pro autentifikaci u radicale a jak jsem zjistil z jeho výpisu, klient z BlackBerry posílal k ověření heslo kryptované přes MD5.

Příprava uživatelských adresářů

Uživatelské adresáře, které se budou dynamicky mapovat podle uživatelského jména přihlášeného uživatele, mohou být kdekoliv v systému, nejlépe však zcela mimo strukturu adresáře /var/www, což je výchozí hodnota proměnné DocumentRoot u Debianu.

mkdir -p /srv/dav/user1/.DAV
mkdir -p /srv/dav/user2/.DAV
...
chown -cR www-data /srv/dav
chmod -cR 660 /srv/dav

Aby bylo možné s obsahem těchto adresářů namountovanými přes WebDAV pracovat, musí mít uživatel pod kterým běží webový server (u Debianu www-data) právo nejenom ke čtení, ale i k zápisu do těchto adresářů.

POZOR! Pokud by adresář, který má být dostupný přes WebDAV ,obsahoval soubor, ke kterému by neměl uživatel pod který běží webový server přístup alespoň pro čtení, skončil by pokus o vytvoření nového souboru chybou.

Poznámka: Pokud by neexistoval adresář .DAV, skončil by pro změnu pokus o namountování na straně klienta oznámením, že cílová lokace není dostupná přes WebDAV.

Vytvoření konfigurace pro Apache

Aby server ověřoval uživatele vůči obsahu souboru /etc/dav/htpasswd.setup, musí být do Apache zaveden modul mod_authn_file, který zajistí, že bude rozumět syntaxi tohoto souboru a také autentifikační modul mod_auth_basic, pro základní ověření kombinací uživatelské jména a hesla.

root@stroj:~# cat /etc/apache2/conf-available/dav.conf 
RewriteEngine On

<Directory /srv/dav>
         DAV On
         DirectoryIndex neverused.neverused
</Directory>

<Location /webdav>
        AuthType Basic
        AuthName "WebDAV"
        AuthBasicProvider file
        AuthUserFile /etc/dav/htpasswd.setup
        Require valid-user
</Location>

RewriteRule ^/webdav/(.*)$ /srv/dav/%{LA-U:REMOTE_USER}/$1

Autentifikace uživatele probíhá vůči elementu Location. Ačkoliv na internetu naleznete příklady, ve kterých je autentifikace přítomna v obou elementech, tak z vlastní zkušenosti mohu říct, že vám to pak přestane fungovat. Fungovalo by vám to pouze v tom případě, že byste chtěli adresář, který je v elementu Directory publikovat přes web. Jenže pak na tom zase pro změnu nerozběháte WebDAV.

Také upozorňuji na direktivu DirectoryIndex v elementu Directory. Ta slouží k tomu, aby při přístupu přes WebDAV nedocházelo k nežádoucí interpretaci souborů typu index.html. Pokud byste ji konfiguraci neuvedli, tak v případě, že uživatel vytvoří v podadresáři soubor index.html dojde k jeho interpretaci a obsah adresáře bude nedostupný. Přesto že na serveru normálně bude existovat a dokonce bude fungovat i upload.

Tuto vytvořenou konfiguraci bude Apache akceptovat po restartu.

Připojení na straně klienta

Jako příklad uvádím pouze namountování vypublikovaného adresáře uživatele user1 přes davfs.

mount -t davfs http://stroj/webdav /pripojny_bod -o username=user1

Na platformě MS Windows je třeba od MS Windows Vista výše provést nejprve drobnou úpravu v registru, jinak nebude autentifikace jménem a heslem fungovat. Pak již lze normálně použít volbu "Připojit sdílený disk". Reg soubor který tuto změnu udělá, resp. popis kde se má co změnit, včertně nějakých obrázků najdete na naší wiki.

Podobným způsobem se připojení sdílený disk i u Mac OS X, až na to, že nevyžaduje opruz s opravou záznamu v registru.

Na BlackBerry Q10 používám pro připojení adresáře sdíleného přes WebDAV placenou aplikaci PlayCloud a na Androidu můžete použít kupříkladu aplikaci ES file explorer.

Veřejné vypublikování obsahu uživatelských adresářů

Při pokusu o otevření URL http://stroj/webdav v prohlížeči skončí webový prohlížeč na chybě 403 a to i přes úspěšnou autorizaci.

Chcete-li obsah uživatelských adresářů vypublikovat tak, aby byl dostupný (pouze ke čtení) i přes webový prohlížeč, můžete vytvořit do adresáře /var/www symlink, kupříkladu s názvem pub, který bude na /srv/dav odkazovat.

       

Komentáře

[trekker.dk]

Na WebDAV je - minimálně v Apache - nepříjemné to, že se soubory nahrávají pod systémovým uživatelem www-data (obecně pod tím, pod kterým Apache běží) a nejde to změnit. Pokud ten server není jenom datové úložiště, tak to docela vadí.

[Luk]

A co mpm_itk?

[trekker.dk]

No, v dokumentaci hned na začátku píšou, že je to založené na prefork mpm, které na serveru, kde je provoz, AFAIK nepodává úplně nejlepší výsledky.

[pavlix]

Nevím jak v tomto konkrétním případě, ale obecně považuju za jedinou validní alternativu k mpm-itk pustit pro každý jednotlivý subjekt (uživatele) samostatný Apache. To, že někdo umí z Apache vytřískat trochu výkonu navíc je mi většinou naprd, když je cenou za to ztráta možnosti pouštět weby pod různými uživateli.

[trekker.dk]

Nevím, co přesně myslíte souslovím "pouštět weby", ale nestačil by suexec?

[Luk]

Pokud vím, tak byl suexec ve většině případů výkonově horší než mpm_itk.

[trekker.dk]

No, přiznávám se, že jsem to neměřil, ale nezdá se mi to. Bylo by divné, kdyby spuštění nového procesu pro každý request bylo rychlejší než spustit jeden proces a ten nechat vyřídit řádově stovky requestů.

[Luk]

Nový proces pro každý request se vytváří právě u suexec. Jinak může proces Apache vyřídit prakticky libovolný počet požadavků, samozřejmě v závislosti na tom, jak je to nastavené v konfiguraci. U mpm_itk je samozřejmě nepříjemné to, že když si Apache naforkuje procesy pro nějakého uživatele a pak je potřebuje pro jiného uživatele, nemůže je použít. Buď si naforkuje další (pokud je pod limitem pro počet procesů) nebo musí nejdřív ty nevyužité ukončit. Tedy když je uživatelů hodně a požadavky jsou mezi nimi rozložené v zásadě rovnoměrně, může být (ale nemusí!) výkon lepší se suexec, při malém počtu reálně využívaných uživatelů je na tom lépe mpm_itk. Další věcí je, že suexec se týká jen toho, co se po Apachem spouští, kdežto mpm_itk se vztahuje na všechno včetně samotných funkcí Apache.

[trekker.dk]

Nový proces pro každý request se vytváří právě u suexec.

Tak to fakt ne.

Možná se bavíme každý o něčem jiném - já mluvím o nastavení, kdy apache přes suexec spustí program a ten pak běží jako FastCGI server.

Jinak může proces Apache vyřídit prakticky libovolný počet požadavků

Pravda, tohle jsem si zaměnil s CGI - co koukám do dokumentace, tak i prefork režim nechá jeden (pod)proces vyřídit víc požadavků.

Další věcí je, že suexec se týká jen toho, co se po Apachem spouští, kdežto mpm_itk se vztahuje na všechno včetně samotných funkcí Apache.

To je pravda, na druhou stranu ty samotné funkce Apache toho neřeší tolik - přijmout navázané spojení, otevřít soubor, načíst soubor, poslat obsah do toho spojení - na tom není moc co zkazit a i tak se to děje pod neprivilegovaným uživatelem. Za poslední roky přitom nevím o nějaké chybě, která by v tomhle režimu umožňovala vykonat cizí kód nebo aspoň přistoupit k cizím datům.

[Luk]

já mluvím o nastavení, kdy apache přes suexec spustí program a ten pak běží jako FastCGI server

To už je ale trochu něco jiného. Samotný suexec se chová tak, jak jsem popsal.

i prefork režim nechá jeden (pod)proces vyřídit víc požadavků

Může jich vyřídit libovolné množství, pokud se Apache tak nastaví. Při běhu pod více uživateli je tam samozřejmě ten problém, který jsem zmínil. Pokud je k dispozici dost paměti, dá se limit na procesy Apache nastavit vysoko (totéž počet flákajících se procesů, aby je to neukončovalo) a nevzniká zpoždění tím, že by se vytvářely nové procesy.

To je pravda, na druhou stranu ty samotné funkce Apache toho neřeší tolik - přijmout navázané spojení, otevřít soubor, načíst soubor, poslat obsah do toho spojení - na tom není moc co zkazit a i tak se to děje pod neprivilegovaným uživatelem.

Jenže řeč byla o WebDAV, z toho celou dobu vycházím.

[trekker.dk]

No jasně že je řeč o WebDAV, ale v prostředí, kdy ten Apache není jenom datové úložiště, ale webserver (definice slova podle #21). Pokud bych chtěl umožnit nahrávání dat pomocí WebDAV, tak s mod_dav musím obětovat buď výkon (viz níže ten test), nebo ukládání dat různých uživatelů (lidí) pod různými systémovými uživateli. Jedno je horší než druhé a suma sumárum je WebDAV ze hry venku.

[Sten]

Na „pouštění webů“ je spíš PHP-FPM.

[trekker.dk]

Taky možnost, ale všude, kde jsem četl o php-fpm a jak to integrovat do Apache nebo Nginx, taky vždycky psali o "caveat" při přístupu na URL typu /upload/obrazek.jpg/skript.php (obrazek.jpg se předá ke zpracování interpreteru PHP a ten ho vykoná). Jako řešení tam potom vždy psali buď zakázat pathinfo, nebo přidat přepisovací pravidla a kontroly, aby se takový soubor nezpracoval. (Přičemž jak mají dané kontroly vypadat, už bylo dáno jako domácí cvičení laskavému čtenáři.)

S kombinací Apache + suexec + PHP se mi zatím nepovedlo ten caveat reprodukovat. Požadavek na /obrazek.jpg vrací ten obrázek (nebo PHP kód, když se pokoušíme škodit), požadavek na /obrazek.jpg/skript.php vrátí 404.

[pavlix]

Tedy namísto jednoduchého řešení typu mpm-itk, kdy celá obsluha probíhá pod příslušným uid/gid, zvolíme komplikované (a tedy potenciálně děravé), dost možná ještě méně výkonné řešení. Díky, nechci, suexec se mi nelíbil od první chvíle, kdy jsem na něj narazil, považuju ho za velmi pochybné řešení a byl jsem z něj nežťastný do doby, než jsem se prvně seznámil s mpm-itk a od té doby jsem všude rovnou instaloval balík s tímto modulem (a závislostmi) namísto výchozího apache. Nevím, jak takovou prasárnu může vůbec někdo vychvalovat.

[trekker.dk]

Tedy namísto jednoduchého řešení typu mpm-itk, kdy celá obsluha probíhá pod příslušným uid/gid, zvolíme komplikované

Váš názor, nic jiného.

(a tedy potenciálně děravé),

FUD, navíc vycházející z nepravdivého předpokladu

dost možná ještě méně výkonné řešení.

Tak jsem si to lehce otestoval - výchozí instalace Apache, statický obsah (stránka s It works) na localhostu s prefork + itk vs. event nebo worker. Worker cca 6000 req/s, prefork 1000 req/s.

Nevím, jak takovou prasárnu může vůbec někdo vychvalovat.

Asi to bude někdo, komu nastavení suexec nedělá problémy a výsledek bez problémů funguje. Ten někdo se možná podíval do zdrojáku suexec, který je pochopitelný a je z něj naprosto jasně vidět, co to dělá a proč.

[Luk]

Tak jsem si to lehce otestoval - výchozí instalace Apache, statický obsah (stránka s It works) na localhostu s prefork + itk vs. event nebo worker. Worker cca 6000 req/s, prefork 1000 req/s.

To je ale zjevně něco úplně jiného, než o čem tu je řeč. Worker a event nezajistí samy o sobě separaci uživatelů (třeba pro WebDAV, o kterém je tu řeč od počátku), takže tohle porovnání výkonu je nesmysl. Srovnává se nesrovnatelné.

[trekker.dk]

Worker a event nezajistí samy o sobě separaci uživatelů

Ano, to je mi známo, goto #1, první věta.

Kdyby ten webserver byl jenom osobní datové úložiště (tak, jak ho popisuje autor blogu), tak fajn. Na takovém serveru nebude velký provoz. Jenže v konfiguraci, kdy je Apache primárně webserver (čti server poskytující webové stránky webovým prohlížečům, goto #1, druhá věta), už je to něco jiného - tam si pomalý prefork nemůžu dovolit, což potvrzuje i to srovnání.

Jasně, separaci uživatelů worker ani event nezajistí, takže WebDAV je ze hry venku a jsem odkázaný na FTP, SFTP apod.

[pavlix]

Worker a event nezajistí samy o sobě separaci uživatelů (třeba pro WebDAV, o kterém je tu řeč od počátku), takže tohle porovnání výkonu je nesmysl. Srovnává se nesrovnatelné.

+1

[pavlix]

Ne, asi sem budu psát názor někoho jiného :D.

[Petr Tomášek]

Kapico, Kapico! Zase dost velké zjednodušení!

Pro upload souboru na server není WebDAV potřeba. Na to stačí klidně metoda PUT, které je definovaná v rámci HTTP. WebDAV se stará hlavně o zjišťování metainformací o souborech a adresářích (k čemuž např. patří vylistování obsahu adresáře) a taktéž o změnu takovýchto informací (viz metody PROPFIND a PROPPATCH).

Jinak základní podporu pro WebDAV je možné poměrně jednoduše zbastlit i v PHP a to dokonce tak, že jedno URL při přístupem přes normální prohlížeč ukáže nějakou "sexy" stránku např. s výpisem adresáře a přitom přes stejné URL je to dostupné přes WebDAV...

[Aleš Kapica]

No, řekl bych že i přes to zjednodušení jsem dal tomu času víc než dost. Obzvláště, když jde o téma, na kterém dokážou jiní postavit celou svou akademickou kariéru.

[Sten]

Jinak základní podporu pro WebDAV je možné poměrně jednoduše zbastlit i v PHP a to dokonce tak, že jedno URL při přístupem přes normální prohlížeč ukáže nějakou "sexy" stránku např. s výpisem adresáře a přitom přes stejné URL je to dostupné přes WebDAV...

Nebo použijete standardní moduly pro Apache, které udělají totéž

[Petr Tomášek]

Ovšem s tím rozdílem, že vlastní implementací v PHP můžu velmi dobře kontrolovat, co přesně se bude se soubory dít, nebo je dokonce generovat on-the-fly, atd..

[xxx]

No nekteri z nas ten WebDAV na FELu museli pouzivat jako studenti, a ze by to byla tak super vec, to mi uplne neprislo.

Teda ne ze by to nefungovalo, ale bylo zcela zrejme, ze vzhledem k tomu, jak dlouho vyucujicim vzdycky trvalo to spravne zprovoznit, tak aby vsichni meli slozku, kterou maji mit, a prava, ktera maji mit, tak se obavam, ze v administracni privetivosti to melo silne nedostatky.

Coz treba Moodle, ktery se v te dobe zacal sirit, a obcas mi prisel z uzivatelskyho hlediska fakt tragickej (kam se mam sakra zas proklikat), tak tuhle administrativni pripravu mel zrejme lip zmaknutou.

A nebo to proste bylo akorat o nahode.

[Aleš Kapica]

No nekteri z nas ten WebDAV na FELu museli pouzivat jako studenti, a ze by to byla tak super vec, to mi uplne neprislo.

O WebDAV, který jsem provozoval já jde asi těžko. Bylo to čistě provizorní řešení, určené ke sdílení souborů v rámci jedné pracovní skupiny a konfigurace byla vskutku jen základní. Pravděpodobně jde asi o řešení, které bylo donedávna provozované na Katedře počítačů.

Podle toho co mi o něm sdělil kolega byl největší zádrhel ve zbytečně komplikovaném URL a v tom k čemu byl tento sdílený prostor určen.

Nefungovalo to tak, že by měl každý student jeden adresář dostupný přes WebDAV, do kterého by si ukládal svoje soubory, ale zakládal se mu adresář extra pro každý předmět. S tím, že tento adresář byl určen pouze pro odevzdávání souborů souvisejících s předmětem. A jelikož vyučující předmětu k nim musel mít také přístup, tak z toho plynul onen oser s konfigurací práv. A s tím vcelku souhlasím, že to musel být opruz, protože WebDAV nějaké sofistikované nastavení práv vůbec neřeší. Taky se nehodí ani pro uložení uživatelského profilu, protože nelze kupř. pracovat se symlinky. Ovšem pro to, aby měl své každý uživatel dostupné své dokumenty po síti souběžně z různých zařízení, podle mě bohatě stačí.

Coz treba Moodle, ktery se v te dobe zacal sirit, a obcas mi prisel z uzivatelskyho hlediska fakt tragickej (kam se mam sakra zas proklikat), tak tuhle administrativni pripravu mel zrejme lip zmaknutou.

Pokud jde o Moodle, tak že jde o zcela tragický e-learningový systém se nebudu přít. Už jsem se o tom možná tady někde i zmiňoval co vše na něm považuji za špatné - v podstatě to začíná už samotným návrhem aplikace, která nezapře své kořeny v jednoúčelovém bastlu, jehož autor vůbec netušil že se to zvrhne do takového molochu. Bohužel. Stalo se a trend je takový, že s ním bude nutné žít i do budoucna.

[Josef Kufner]

[...], protože nelze kupř. pracovat se symlinky.

Dobré vědět. Doteď jsem si dělal naděje, že by WebDAV šel použít na sdílení dat mezi mými zařízeními, ale chybějící podpora symlinků je na mne příliš omezující.

[Martin Bílý]

Když už tady na to přišla řeč, tak na tehdejším serveru service.felk.cvut.cz byl použit běžný modul mod_dav. Pro autentizaci a autorizaci uživatelů ale existoval domo-robo modul, který pracoval s informacemi uloženými v databázi PostgreSQL. S jeho pomocí bylo možno povolovat přístup pro každého uživatele, ke každému jednotlivému souboru či adresáři některou z tuším šestnácti HTTP (včetně WebDAV) metod. Existoval pojem skupina uživatelů. Existovala dědičnost práv z nadřízeného adresáře. V dobách největší slávy měla největší tabulka s individuálními právy uživatelů něco přes 50 tisíc záznamů.

Problémy působilo především to, že zdaleka ne všechny klientské programy rozdýchávaly situaci, kdy například přečtení souboru bylo povoleno i anonymnímu uživateli, zatímco pro jeho změnu bylo nutné se autentikovat.

Existovala sada scriptů, které zakládaly uživatelské účty, řadily uživatele do skupin, přidělovaly práva do individuálních projektových adresářů automaticky v závislosti na seznamu studentů zapsaných na předmět a v závislosti na profilu předmětu v rámci serveru. Též existovala nadstavba pro správu ad-hoc projektů.

Tolik na doplnění od bývalého admina bývalého serveru.

[brozkeff]

WebDAV využívá i třeba ownCloud, takže pokud nejde o levný hosting za 20 korun měsíčně, ale výkonnější VPSko, tak bych pro jednoduchost možná zvážil i ten owncloud, kde je možnost to napojit na LDAP či AD, nebo vytvářet uživatele a skupiny ručně.