Iis публикация средствами webdav


Iis публикация средствами webdav

облом наступил при попытке заглянуть webdav клиентом в виртуальную директорию.

Дальше начал что-то ещё предпринимать, и добился включения Directory browsing для браузера — что не помогает вебдаву: вирт.директория остаётся для его клиента пустой.

Добавление от 30.06.2020 01:12:

Зы. Также хотелось бы научиться удалять из проводника буквы фантомных вебдав подключений виндового клиента.

Мышкой всё виснет и остаётся на месте,
Remove-PSDrive не выдаёт ошибку, но и не срабатывает,
рестарт эксплорера не помогает.

1. LevT , 30.06.2020 19:25
Короче, 10 IIS настроить я пока вовсе ниасиливаю.

IIS в 2012 R2 сервере — ближе к цели вот по этому гайду http://myworldofit.net/?series=webdav-access-windows…all-on-any-device
(но я настраивал без SSL, и c Windows а не c Basic Authentication)

Application Pool Identity — работает Custom, с админской учёткой
Работает No Managed Code в пуле.
Порт если не дефолтный 80 — то надо вручную допиливать фаерволл на сервере.

И в этом случае виндовый (из 10) клиент всё равно не подключается (system error 5 Access denied) . зато подключается софтина NetDrive.
И видит содержимое виртуальных папок, вау.

Добавление от 30.06.2020 19:54:

Попытка залить этим клиентом 6Гб дистрибутив Exchange обломалась где-то на 2/3
После чего связка клиент-сервер работает нестабильно, обламывается даже на не очень больших файлах (проводник получает восьмизначный IO Device Error)
Даже после последовательных рестартов сайта, IIS и клиента.

2. Musik , 03.07.2020 15:10
LevT
настраивал пруф-концепт
3. LevT , 05.07.2020 19:23
Musik
Видел я эту статью. Вы сами-то это пробовали?
У меня худо-бедно работает NetDrive клиент с 2012 R2 сервером. Десяточный WebClient пишет system error 5 Access denied (если подключаться из net use).

В общем, сейчас ковыряю pydio. Но и там тоже пока не победил бэкенд-аутентификацию к виндовым шарам.

Добавление от 05.07.2020 19:25:

А фантомные подключения сами ушли. после N-ой по счету перезагрузки.

4. vinni , 04.12.2020 20:49
Штатный WebDav-клиент Win 10 «из коробки», подключился по https к папке на Synology, копирую на Synology файл 100+МБ. Проводник рисует график с безумной скоростью 165 МБ/с (это при том, что ноут подключен по 802.11g 130Mbps link speed, а интернет и вовсе 50 Mbps), в итоге график за несколько секунд бодренько упирается в «Выполнено 99%» и висит в таком положении хренову тучу времени. При этом в мониторе самой Synology я вижу поток

0.5-1 MBps. Спрашивается вопрос — чзх?

5. LevT , 04.12.2020 23:45
гм. я тему-то создавал для решения серверной проблемы с IIS
может, для клиента отдельную сделать?

или эту переименовать?

Добавление от 04.12.2020 23:53:

а графики в эксплорере это для тупых юзверей )
кр00тым админом положено рисовать для себя другие графики — из данных etw — или неча на графики кивать )

Установка и настройка WebDAV (IIS 7.5)

WebDAV.

Для начала вкратце что такое WebDAV. Стандарт WebDAV (Web Distributed Authoring and Versioning) — расширение протокола HTTP/1.1. Протокол позволяет работать с файлами на сервере и выполнять обычные действия с ними: чтение, запись, удаление файлов. Используется для совместной работы над удаленными файлами. Говоря по-простому, webdav это web-папка.

Установка WebDAV на Windows Server 2008 R2.

Я не буду подробно описывать процесс установки WebDAV, я хочу . постинсталляционной настройки

Включаем WebDAV для сайта IIS.

Можно сказать на этом установка и настройка по умолчанию выполнена.

Возможные проблемы и ошибки WebDAV.

  • Проверка работоспособности WebDAV на localhost (Server 2008 R2).

При подключении диска на localhost возникает ошибка: Error code: 0x80070043 (The network name cannot be found). Можно через cmd: net use * http://localhost

Ошибка возникает из-за того, что по умолчанию, на Windows Server 2008 R2 не установлен клиент WebDAV (служба WebClient). Для установки клиента необходимо установить фичу — Desktop Experience.

Проверка роботоспособности WebDAV на localhost.

Permanent link to this article: http://www.blogss.ru/installing-and-configuring-webdav

2 комментариев

Border Сообщает:

01.06.2015 на 15:33 (UTC 6 )

Спасибо за решение по Error code: 0x80070043 в картинках

sergey Сообщает:

22.12.2020 на 14:46 (UTC 6 )

О ГОСПОДИ! спасибо, потратил 3 дня на решение ошибки

Удаленный доступ через протокол WebDAV

Удобный способ доступа к внутренним файл-серверам компании Чтобы организовать доступ сотрудников, находящихся за пределами предприятия, к внутренним файл-серверам, лучше всего воспользоваться встроенным протоколом Windows XP и Windows Server

Удобный способ доступа к внутренним файл-серверам компании

Чтобы организовать доступ сотрудников, находящихся за пределами предприятия, к внутренним файл-серверам, лучше всего воспользоваться встроенным протоколом Windows XP и Windows Server 2003, Web Distributed Authoring and Versioning (WebDAV), который обеспечивает безопасный доступ через приложение-посредник. Пример такого доступа — защищенный доступ Outlook 2003 к Exchange Server через HTTP-proxy. Реализовать WebDAV просто, так как протокол инкапсулирован в классическом HTML. Поэтому брандмауэры не являются препятствием для использования протокола, который совместим не только с платформой Windows, но и с другими операционными системами, в частности Mac OS. Для защиты WebDAV достаточно применить HTTP Secure (HTTPS).

Рассмотрим этапы подготовки удаленного доступа через WebDAV к папке на внутреннем файл-сервере. Основные компоненты — сервер Microsoft Internet Information Services (IIS) 6.0, файл-сервер, офисное сетевое соединение и клиентские компьютеры. Сервер IIS и файл-сервер не обязательно должны размещаться на одном компьютере. Также необходима система Windows 2003, подключенная к внутренней сети и доступная через Internet. Этот сервер называется WebDAV-сервером, так как он будет работать с IIS 6.0 и серверным модулем расширения WebDAV. Не беда, если WebDAV-сервер еще не подключен к Internet; однако его нужно защитить.

Доступ к серверу WebDAV через Internet

Способ доступа к серверу WebDAV через Internet зависит от текущего состояния среды и размеров предприятия. Обязательное условие — назначить IP-адрес или имя DNS и номер TCP-порта, с помощью которых удаленные пользователи будут обращаться к серверу WebDAV. Рассмотрим типичные сценарии. На малом предприятии единственное устройство, подключенное к Internet, — типовой широкополосный маршрутизатор/брандмауэр, но это не помешает организовать доступ с использованием WebDAV. Необходим IP-адрес, по которому удаленные пользователи будут обращаться к файл-серверу. Во-первых, следует выяснить, имеется ли у маршрутизатора статический IP-адрес. Если нет, то проще всего получить его у Internet-провайдера. Если статический IP-адрес получить нельзя, можно использовать DDNS. Большинство широкополосных маршрутизаторов совместимы с DDNS. Затем нужно решить проблему TCP-порта. Если для доступа к узлам за маршрутизатором уже применяется HTTPS, можно просто сделать в брандмауэре исключение для передачи входящих соединений в TCP-порт 443 внутреннего сервера, на котором выполняется IIS 6.0 с WebDAV. На данном этапе порт открывать не следует; предварительно необходимо убедиться, что внутренний сервер готов к этому.

Если IIS-сервер еще не подключен к Internet, можно назначить файл-сервер WebDAV-сервером.

В более сложной сети, возможно, уже имеется система Windows 2003, подключенная к Internet напрямую или через брандмауэр, как описано выше. Не составит труда задействовать эту систему. Если сервер Windows 2003 уже работает с IIS, например для Microsoft Outlook Web Access (OWA), SharePoint или общедоступного Web-узла, можно создать виртуальный каталог в существующем Web-узле или подготовить новый узел. Различие в том, что при использовании существующего Web-узла для настройки клиентского доступа WebDAV нужно к имеющемуся URL-адресу Internet добавить имя виртуального каталога. Если создан новый узел, то для него может потребоваться новый номер TCP-порта. При доступе к существующему узлу через HTTPS с использованием стандартного HTTPS-порта 443 необходимо выбрать новый порт для клиентского доступа WebDAV. Если существующий узел настроен на использование порта 443, но никто не обращается к нему через HTTPS, можно изменить текущий порт Secure Sockets Layer (SSL). Если использовать в качестве SSL-порта какой-либо порт, кроме 443, то необходимо добавить к URL-адресу номер порта. Например, для домена с именем webdav.ultimatewindowssecurity.com URL-адрес будет https://webdav.ultimatewindowssecurity.com:XXXXX, где XXXXX — номер порта.

Настройка безопасного WebDAV

В следующих поэтапных инструкциях предполагается, что IIS и WebDAV устанавливаются на системе, отличной от файл-сервера. В этом случае достаточно установить IIS без активизации Active Server Pages (ASP) и любых других необязательных компонентов. После установки IIS следует открыть оснастку Internet Information Services (IIS6) Manager консоли Microsoft Management Console (MMC) (см. экран 1), развернуть папку Web Service Extensions и активизировать узел WebDAV. Чтобы максимально сузить поверхность атаки на IIS, не следует активизировать другие модули расширения.

Экран 1. Активизация WebDAV в IIS 6.0

Затем нужно настроить IIS для приема только проверенных, шифрованных соединений. Из оснастки IIS Manager консоли MMC следует открыть диалоговое окно Default Web Site Properties и выбрать вкладку Directory Security (экран 2). Прежде всего необходим сертификат SSL для сервера. Если в компании запущена служба Microsoft Certificate Services для домена, то запросить сертификат можно с помощью мастера. В противном случае потребуется купить сертификат в общедоступном удостоверяющем центре или создать сертификат с собственной подписью. В комплекте ресурсов Microsoft Windows Internet Information Server Resource Kit есть инструмент для генерации сертификатов с собственной подписью. Если имеется корпоративный удостоверяющий центр, необходимо щелкнуть на кнопке Server Certificate и пройти по операциям мастера Web Server Certificate Wizard. На странице Delayed or Immediate Request нужно выбрать пункт Send the request immediately to an online certification authority и щелкать на кнопке Next до тех пор, пока не появится страница Your Site?s Common Name. На ней требуется ввести имя DNS или IP-адрес для обращения удаленных пользователей к Web-узлу. Если введен IP-адрес и используется DHCP с DDNS, то сертификат при изменении IP-адреса окажется недействительным. Не следует указывать https:// или номер порта. В приведенном выше примере с URL необходимо ввести webdav.ultimatewindowssecurity.com. Нажимая Next, нужно перейти к странице SSL Port и ввести выбранный ранее TCP-порт, а затем щелкать на кнопке Next до появления кнопки Finish. После щелчка на ней сертификат SSL будет установлен. Вернувшись на вкладку Default Web Site Properties Directory Security, следует щелкнуть на кнопке Edit в разделе Secure communications, чтобы вызвать диалоговое окно Secure Communications и установить флажки Require secure channel (SSL) и Require 128-bit encryption.

Экран 2. Параметры вкладки Directory Security

На следующем этапе необходимо потребовать, чтобы все пользователи при обращении к серверу проходили проверку подлинности. На вкладке Directory Security следует щелкнуть Edit в разделе Authentication and access control. Сбросив флажок Enable anonymous access (экран 3), нужно установить флажок Basic authentication (password is sent in clear text). Не обязательно выбирать обычную проверку подлинности, если на предприятии имеются только клиенты Windows. Можно не обращать внимания на предупреждение о простом тексте от IIS — шифрование SSL уже активизировано. Стандартный домен следует настроить в соответствии с параметрами домена, в котором размещены учетные записи удаленных пользователей; в результате пользователям не придется добавлять перед своими именами domain name. Вид диалогового окна Authentication Methods должен быть похож на экран 3.

Экран 3. Правильно настроенные параметры Home Directory

Настраиваем IIS на общедоступную папку

Всякий раз, когда устанавливается новый IIS-сервер, создается виртуальный каталог на существующем Web-узле или новый Web-узел на имеющемся IIS-сервере; необходимо настроить IIS на соответствующую папку файл-сервера, в которую будут направляться запросы от URL-адреса WebDAV. Если создан узел или виртуальный каталог в существующем узле, то IIS предоставляет возможность указать папку, которая содержит информацию для этого каталога или узла. Поскольку используется экземпляр IIS, выделенный для WebDAV, необходимо только связать корневой каталог выбираемого по умолчанию Web-узла с файл-сервером. В диспетчере IIS Manager следует вернуться к Default Web Site Properties и выбрать вкладку Home Directory, затем установить флажок A share located on another computer и ввести в текстовом поле Network directory путь в формате Universal Naming Convention (UNC) для общей папки, к которой предстоит обращаться удаленным пользователям (экран 4).

Необходимо убедиться, что IIS олицетворяет текущего пользователя перед доступом к файл-серверу. Следует щелкнуть на кнопке Connect As. и установить флажок Always use the authenticated user?s credentials when validating access to the network directory. Чтобы пользователи могли получать, отправлять и просматривать файлы в папке через WebDAV, нужно установить флажки Read, Write и Directory browsing на вкладке Home Directory (экран 4). Эти флажки определяют только операции WebDAV, которые может запросить пользователь. Файл-сервер применяет разрешения NTFS для доступа к файлам так, как будто пользователь подключен локально. Остальные параметры на вкладке Home Directory активизировать не нужно, а параметру Execute permissions следует присвоить значение, обеспечивающее максимально надежную защиту.

Экран 4. Правильно настроенные методы Authentication Methods

На этом завершается подготовка IIS к приему запросов WebDAV для доступа к файл-серверу. Перед тем как открыть WebDAV-сервер для внешнего мира, необходимо убедиться, что на сервере установлены все исправления для системы безопасности IIS. Наконец, можно открыть соответствующий порт брандмауэра и приступить к работе на серверной стороне.

Активизация пользователей

Теперь остается лишь активизировать удаленных пользователей. Для этого нужно создать ярлык Add Network Place для пользователей, чтобы они могли получить доступ в My Network Places на своих клиентских компьютерах. Затем каждому пользователю необходимо обратиться в My Network Places, дважды щелкнуть на ярлыке Add Network Place и ввести URL-адрес узла WebDAV. При первом обращении к ярлыку в My Network Places программа Windows Explorer запрашивает учетные данные; впоследствии пользователи получают доступ к файл-серверу как к обычной общей папке.


Проблемы безопасности

Насколько безопасен этот метод? Удаленный доступ через WebDAV сопоставим по защищенности с VPN-доступом на основе пароля пользователя. Единственное различие — увеличенная площадь атаки WebDAV из-за открытого порта 443. Однако, чтобы воспользоваться HTTP для проникновения в систему, взломщикам требуется успешно пройти проверку подлинности. Чтобы усилить безопасность, можно внести элемент неизвестности, изменив номер HTTPS-порта Web-узла с 443 на более высокий. Следует иметь в виду, что при этом ограничивается доступ удаленных пользователей, находящихся за брандмауэром другой компании со строгими ограничениями для исходящих соединений. Лучший способ еще более надежно защитить любой тип Web-соединений — требовать клиентские сертификаты наряду с аутентификацией с применением пароля. Для получения сертификата удаленным пользователям достаточно пройти по нескольким Web-страницам.

Рэнди Франклин Смит — редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: rsmith@montereytechgroup.com

Поделитесь материалом с коллегами и друзьями

Возможно ли и как расшарить корень DFS через WebDAV на отдельностоящем IIS-сервере?

Можно. Нужно замапить корень DFS на IIS и опубликовать его через WebDAV. Да возможно с авторизацией будет костыль в виде — все работают под одной учёткой. Хотя может быть удастся заставить работать прозрачную авторизацию.

Я ведь правильно понял что вы делаете паблику вебдава с высокой доступностью? если да, то лучше смотреть на реализации rsynch и apache там всё надёжнее. Но это имхо.

Нет, высокая доступность тут не при чем. DFS у нас — «точка входа», хотелось бы отразить ее в виде webDAV. Да, вариант «все под одним пользователем» вполне работает, но в моем случае это плохо.

Касательно аутентификации — через NTLM это оказалось сделать невозможно, так как в этом случае я авторизуюсь на сервере, а сервер не можем прокинуть мои авторизационные данные дальше на сервер, подмаплнный через папку DFS.
Единственный вариант — использование Kerberos-авторизации, но мне это не подходит потому как этот доступ хотелось сделать именно для недоменных клиентов, имеющих учетные записи в AD.

Пока остановился на решении FTP over SSL через IIS с FileZilla в виде клиента.

Webdav authentication performance / alternatives

I am trying to find out how suitable Webdav is for a product by the company i am working at.

Our needs seem to exceed what Webdav has to offer and i’m trying to find out if my theory is correct and if so how we could work around it.

I am using the Webdav-package which you can install through the «add/remove windows features»-dialog.

The problem is that we want to be able to set permissions for each file and since we can access and change authoring-rules by code this is more or less possible.

Authoring-rules seem to apply to folders and not individual files but this could be worked around by giving each file it’s own folder (although it’s a bit ugly).

To me this solution seems very inefficient mainly because the authoring-rules are all placed in a list which means that for all file-requests the server has to loop through the entire list which gets larger for every file added to the server.

My thought is that we could build some kind of «proxy» that checks permissions in a more efficient way and if the user has permission to access the file we just forward the request to the webdav-server.

This might also be inefficient though since we have to have an application managing the connection between the user and the Webdav-server but at least the inefficiency isn’t exponential.

I guess this leads to the questions:

Is Webdav at all suitable for more complex permissions?

Is there some part of Webdav that i have missed which solves this problem?

If so, would it be better to go with the internal solution or should we do an external solution?

If not Webdav, is there a better solution? (We want all the nice file-locking, version-control and office-integration stuff)

Windows Server 2012/2020 и WebDAV

WebDAV (Web Distributed Authoring and Versioning) является расширением протокола HTTP / 1.1. и позволяет обращаться к файлам на удаленном сервере и выполнять с ними общие операции, такие как чтение, запись, копирование, удаление файлов и т.д. Как правило, этот протокол используется пользователями для совместной работы с удаленными файлами. Проще говоря, webdav — это общая сетевая папка, расположенная на веб-сервере. Для доступа к общим ресурсам WebDAV на клиентской стороне должен быть установлен клиент WebDAV.

Началось все с того, что на свежеустановленной Windows Server 2020 я не смог из коробки подключиться к WebDAV ресурсу — вылетала ошибка — сетевое имя не найдено. Перепроверил трижды вводимые ресурсы, использовал другие — одно и тоже. А оказалось, что в серверных операционных системах Microsoft отдельного клиента WebDAV нет. Например, в Windows Server 2008 R2,2012/2012 R2 клиент WebDAV входит в состав компоненты Desktop-Experience. Поэтому для доступа к WebDAV ресурсам на этих ОС необходимо установить это расширение.

А в Windows Server 2020 необходимо установить компонент webDAV-Redirector. Внимание! После установки сервер перезагрузится автоматически без дополнительных диалоговых окон и предупреждений!

Windows Server 2012 / 2012 R2:

Windows Server 2020:

После перезагрузки я рекомендую сразу выставить максимальный размер передаваемых файлов FileSizeLimitInBytes, потому как по умолчанию там всего 50Мбайт. Настройка производится в ветке реестра: HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

Я выставляю в шестнадцатеричном формате ffffffff, что соответствует 4294967295 байтам (чуть больше 4Гб). Этот нюанс просто необходимо знать, потому что если вы собираетесь копировать бэкапы, то они легко могут быть более 4Гб и придется разбивать на части.

После простейшей настройки нам требуется установить автозапуск двум службам, относящимся к работоспособности WebDAV, и запустить эти две службы.

Далее подключаем WebDAV-ресурс как сетевой диск.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Iis публикация средствами webdav

В прошлый раз мы разбирали один из возможных способов размещения шаблонов MS Office – в сети, на разделяемом ресурсе. Это во многих отношениях отличный способ – простой, надежный, не требующий специальных знаний и дополнительного ПО. Однако, требования корпоративных стандартов бывают очень различными и не редко использования протокола CIFS/SMB в корпоративной сети может быть очень ограниченным (я например, сталкивался с блокировкой SMB между филиалами).

Один из вариантов обхода такой проблемы предложил Андрей Подкин – размещать шаблоны во внешнем хранилище и использовать клиентское ПО с автоматической синхронизацией содержимого этого хранилища. Способ как минимум интересный! Но вновь есть подозрение, что для более-менее крупной компании он разойдется с корпоративной политикой.

Поэтому сегодня мы рассмотрим другой вариант – распространение шаблонов офиса поверх HTTP/HTTPS, которые, как правило, внутренними политиками не блокируются.

Как можно использовать HTTP для распространения шаблонов?

Мне известны как минимум два способа:

  1. Использование протокола WebDAV, реализующего file-styled операции поверх HTTP
  2. Создание каталога шаблонов, так, как описано в статье Deploy custom templates in Office 2010

Сегодня мы разберем первый вариант (сам протокол WebDAV мы несколько обойдем стороной, но, надеюсь, сможем вернуться к нему в дальнейшем).

Итак, для того чтобы развернуть решение на базе WebDAV, нам потребуется:

  • Сервер с поддержкой WebDAV. Из стандартного и/или доступного бесплатно ПО с нужным функционалом можно назвать:
    • SharePoint Foundation – для нашей задачи это слишком громоздкий вариант (да и в принципе, если переходить на использование SharePoint, лучше использовать его механизм работы с шаблонами)
    • Расширение WebDav Publishing для IIS (Internet Information Service).
  • Клиентская поддержка. Здесь мы обойдемся встроенным в Windows WebDAV-клиентом.

Развертывание IIS c поддержкой WebDAV

Сразу оговорюсь, что рассматривать далее мы будем IIS версии 7.x и старше, а значит ОС от Windows 2008 и старше (конкретно у меня скриншоты будут для Windows 2012 и IIS 8, но разница с младшими версиями не принципиальна).

  • Запускаем от имени администратора (важно!) Server Manager и выбираем пункт Add Roles and Features (Add Roles).

Вот так он выглядит в Server 2012

А вот так в 2008 R2:

  • В списке ролей выбираем Web Server (IIS):
  • На шаге выбора сервисов для Web Server Role выбираем 2 пункта: WebDAV Publishing и Windows Authentication
  • Запускаем установку и при необходимости перезагружаемся. В результате, в списке установленных ролей у нас появится IIS:

Настройка узла WebDAV с шаблонами

Прежде чем мы пройдём по шагам весь процесс хотелось бы обговорить один важный момент – какой адрес выбрать для размещения сайта с шаблонами?

По умолчанию, IIS предлагает использовать созданный по умолчанию сайт (Default Web Site), который доступен (если вы ничего не меняли в настройках) по адресу :80″>http:// :80 или просто «>http:// . Для нас это самый простой и подходящий вариант!

Однако (чисто теоретически – в реальности я не сталкивался с такими проблемами), модуль поддержки WebDAV может начать конфликтовать с другими приложениями, развернутыми на том же сайте. Тогда для распространения шаблонов придется создать отдельный сайт, который, чтобы не конфликтовать с Default Web Site должен иметь хотя бы один отличающийся параметр:


  • Host Name. При использовании собственного имени сайта с шаблонами, вам придется добавить его в список узлов вашего DNS-сервера
  • Port. В этом случае мы рискуем столкнуться с ситуацией, что выбранный нами порт также будет заблокирован политиками компании.

В общем, у каждого варианта свои особенности. Мы же далее рассмотрим самый первый – размещение на Default Web Site:

  • Запускаем Internet Information Services (IIS) Manager.
  • Выбираем узел Default Web Site и в контекстном меню пункт Add Virtual Directory…
  • Указываем имя виртуальной папки и её физическое расположение (если папки ещё нет, ее можно будет создать прямо из диалога):
  • Возвращаемся к узлу Default Web Site, выбираем настройку WebDAV Authoring Rules и в ней, на панели Actions, пункт Enable WebDAV
  • Затем переходим на узел Templates, выбираем настройку Authentication и в ней запрещаем анонимную аутентификацию и разрешаем Windows аутентификацию
  • Вновь выбираем узел Templates, затем – настройку WebDAV Authoring Rules и в ней, на панели Actions, пункт Add Authoring Rule
  • В открывшемся диалоге заполняем параметры правила:
    • любой контент (All content)
    • для всех пользователей (All users)
    • доступен на чтение (права Read и Source)
  • И наконец последний, но очень важный шаг – выдача прав на физическую папку, где будут лежать шаблоны. На самом деле, в данном конкретном примере этот шаг – лишний, т.к. права на чтение и так есть у доменной группы Users, но мы все равно дадим права группе Everyone

Осталось выложить в папку MS Office Templates заготовленные нами шаблоны и серверная часть окажется настроенной.

Настройка WebDAV на клиенте

Как уже было сказано ранее, для доступа к развернутому ранее WebDAV ресурсу мы будем использовать встроенные возможности Windows. Всю работу выполняют служба WebClient (или Веб-клиент в русской версии) и драйвер MRXDAV.SYS. Это сочетание позволяет получить очень интересный результат:

все обращения к сетевому ресурсу

будут заменяться на WebDAV-запросы к узлу

Наши шаблоны лежат на сервере с именем VM1, порт сайта 80, виртуальная папка называется Templates, а значит строка обращения будет такой

Этот путь мы укажем в настройках Office, так как делали это в предыдущей статье используя либо прямую правку реестра, либо настройки GPO (увы, по непонятной причине, указать такой путь через UI Office у меня не вышло):

Обновляем политику (или просто перелогиниваемся) и получаем наш законный результат:

Ура.

Неужели все получилось? В принципе, да, хотя имеется ряд потенциальных (и не только потенциальных) проблем… Но о них (и конечно, способах их решения) мы поговорим в следующей части – эта и так получилась очень большой.

Как мы выбрали и реализовали WebDAV в Яндекс.Диске

Уже в момент запуска Яндекс.Диск дал многим разработчиками возможность использовать его в своих приложениях и программах. И обеспечивает это то, что протоколом для десктопных клиентов Диска мы выбрали WebDAV.

Так как именно протокол определяет то, как общаются между собой программы и сервер, от его выбора зависит примерно всё. И то, как будут устроены клиенты, и то, какие возможности работы с файлами у них будут.

Сегодня мы хотим рассказать о причинах, которые остановили наш выбор именно на WebDAV и сделали его протоколом для клиентов Яндекс.Диска.

Благодаря API, реализованному на его базе, с нашим сервисом уже работают ABBYY FineScanner, Handy Backup 7, ES Проводник и неофициальный клиент Яндекс.Диска для Linux.

Перед тем как выбрать протокол, мы определили для себя важнейшие требования к нему:

  1. Скорость работы;
  2. Открытая лицензия;
  3. Возможность реализации всех необходимых действий: аутентификации, поддержки файловых операций, конкурентного доступа к файлам, докачки с сервера и возобновления закачки на сервер;
  4. Распространённость — он должен работать с целевыми операционными системами (в первую очередь Windows, Mac OS X, Linux) «из коробки» или с минимальными доработками.

Мы даже были готовы разрабатывать свой собственный протокол, если бы существующие нам не подошли. Изменение протокола после запуска потребовало бы много человекочасов работы, поэтому нужно было изучить разные варианты и выбрать лучше всего отвечающий нашим требованиям.

FTP. Этот протокол для удалённой работы с файлами проверен временем. Но создавался он без учёта требований информационной безопасности, что стало для нас его существенным недостатком. Помимо этого, он не поддерживает многие необходимые нам операции, например, передачу метаданных вместе с содержимым файла. И требует для подключения специальные приложения.

BitTorrent. Так как речь сразу шла о синхронизации между девайсами, то использовать соединение между ними без создания нагрузки на серверы было бы очень полезно, но это потребовало бы двойной работы по разработке клиента. Вдобавок возникли бы проблемы при работе через NAT-ы и firewall-ы, что сильно снизило бы пользу от использования этого протокола.

Amazon S3. Это хранилище использует свой собственный протокол, основанный на HTTP. Мы рассматривали возможность использования API S3, однако отказались от этой идеи из-за отсутствия в нём привычной работы с каталогами и из-за необходимости использовать специальные приложения для доступа.

WebDAV. Основанный на HTTP и XML и нетрудно расширяемый, он поддерживает в спецификациях практически все, что нам нужно. C ним достаточно хорошо работают предустановленные пакеты во всех целевых операционных системах. Кроме того отдел разработки десктопных клиентов Яндекс.Диска, занимавшийся XMPP-сервером Яндекса, на тот момент уже имел опыт работы с открытыми протоколами на базе XML.

Главной причиной, по которой нам не хотелось создавать свой собственный протокол, было то, что работать с ним смогут только наши приложения, а мы хотели открытости.

В итоге, из всех обсуждавшихся вариантов мы выбрали WebDAV. Единственное, чего не хватало в протоколе — это информирования клиента об изменениях на сервере, очень важной фичи синхронизации. Но так как протокол расширяем, это не стало проблемой.

После выбора протокола началась работа над прототипом Яндекс.Диска. Наш WebDAV-сервер мы написали на Erlang. В качестве фреймворка для веб-сервера был выбран mochiweb, достаточно легковесная и хорошо знакомая нашим разработчикам библиотека. Она же была использована в известной статье о подключении миллиона пользователей к одному серверу — A million user comet application. Также мы думали и об использовании веб-сервера Yaws, который можно сравнить с Apache. Это полноценный веб-сервер, умеющий отдавать статику, запускать CGI-скрипты, обрабатывать специальные страницы с серверными скриптами. Но это всё было нам не нужно. Если бы мы начинали делать проект сейчас, выбор пал бы на Cowboy, так как он предоставляет больше возможностей по определению проблем с соединением.

После изучения протокола WebDAV началась работа над операциями листинга файлов и каталогов на сервере. В качестве хранилища для прототипа использовались mysql-база данных, в которой хранилась мета-информация и обычная файловая система для хранения содержимого файлов. Масштабирования и высокой надёжности на этом этапе не требовалось.

Схема была довольно простой, так как это был прототип. Как обычно бывает с файловыми системами, встал вопрос ограничений на пути. Так как максимальная длина пути к ресурсу в протоколе не оговаривалась, было решено сделать длину компоненты пути в 255 символов, а количество уровней вложенности неограниченным. Примерно таблица хранилища файлов выглядела так:

id число, автоинкремент, уникальный идентификатор ресурса
uid пользователь, владелец ресурса
path строка длины 255, имя ресурса
type тип ресурса, файл или каталог
parent число, id владельца
depth число, уровень вложенности ресурса
использовалось для оптимизации запросов на выборку

Одной из первых нетривиальных задач стал листинг корня, в котором ничего нет. Сложность в том, что метод PROPFIND, кроме просто листинга, выполняет ещё и задачу чтения свойств ресурса. Необходимо было правильно разбирать запрос, понимать, что мы можем выдать, а что нет; формировать правильный ответ. В качестве первого клиента использовался встроенный в Ubuntu gvfs. Отладив работу с ним, мы решили проверить работу подключения из Windows 7 и обнаружили, что он с нами не работает. Исследование работы с другими серверами показало, что встроенные в Windows клиенты не обрабатывают пространство имён «DAV:», если оно объявлено дефолтным, без префикса. Другие стандартные клиенты оказались более терпимыми и легко переваривали выдачу, сформированную специально для клиентов Windows. К счастью, это была единственная несовместимость, которую нам удалось найти.

Когда работа над листингом была завершена, мы реализовали тривиальные операции создания каталогов и удаления ресусов.

Дальше требовалось научиться заливать файлы, но эта операция была не так проста. А почему — если эта тема будет вам интересна — мы расскажем в следующем посте.

WebDAV клиенты не могут загрузить в каталог на сервере файл размером более 30 Mb

Окружение: Windows Server 2008, IIS 7.0, расширение для IIS — WebDAV 7.5
Решение: Открываем на файловой системе сервера виртуальный каталог IIS в который необходимо разрешить загрузку больших файлов, там находим файл конфигурации web.config (если не находим — создаем).
В этот файл вносим следующие изменения:

Таким образом мы установим разрешение на загрузку в виртуальный каталог через WebDAV файлов размером до 100 Mb.
Можно также воспользоваться командой

%windir%system32inetsrvappcmd set config -section:system.webServer/security/requestFiltering -requestLimits.maxAllowedContentLength:104857600

Она установит данное разрешение на уровне сервера, что делать – далеко не во всех случая правильно.

Как удалить модуль WebDAV из IIS?

Я борюсь в течение нескольких дней, чтобы включить запрос PUT и DELETE для моего приложения PHP в MS Azure. Некоторые ответы, которые я нашел, предлагают удалить модуль WebDAV из IIS.

Как мне это сделать?

Я размещаю приложение PHP в Azure App Services, и я смог решить эту проблему, вручную создав файл с именем web.config и добавив его в корневой каталог моего веб-приложения.

Вот весь контент этого файла.

В разделе обработчиков вы заметите, что он ссылается на PHP56_via_FastCGI. Это относится к PHP 5.6. Если вы используете другую версию PHP, вам нужно будет обновить имя и путь к файлу, чтобы отразить эту версию.

Я думаю, что в предыдущей статье в stackoverflow уже есть решение для вашей проблемы.

Попробуйте это и, надеюсь, это поможет! qaru.site/questions/22748/.

Этот ответ хороший. В основном положил его в Web.config. Это то, что делает @shiitake.

Я использую это решение некоторое время, но его раздражает, потому что я должен поддерживать его в своем Web.config, когда остальные разработчики этого не делают. Поэтому я удалил его из IIS вместе.

  • Откройте IIS и перейдите на сайт, о котором идет речь.
  • Нажмите «Сопоставление обработчиков»
  • Найдите обработчик с именем «WebDAV»
  • Выберите его и удалите

С первой попытки я получил Error: Cannot write configuration file due to insufficient permissions . Полное раскрытие, мой коллега исправил его для меня и отправил следующие инструкции. (Возможно, кто-то может отредактировать и прояснить эти шаги.)

  • Остановить сайт
  • Добавьте себя в группу безопасности
  • Удалить обработчик.

Я потратил целый день на это и попробовал каждое решение, с которым я столкнулся, но ничто не помогло мне. В конечном итоге работала с отключением функции «WebDAV Publishing» в функции «Включить Windows». Это находится под:

Информационные службы Интернета \World Wide Web Services\Общие функции HTTP\Публикация WebDAV.

Илон Маск рекомендует:  Что такое код dbplus_setindexbynumber
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL