Системная ошибка 1790 webdav

Почему дайджест-проверка подлинности не выполняется в мини-перенаправителе Windows 7

2 июня 2014 г.

Вот проблема: у вас есть сервер WebDAV, он работает практически со всеми клиентами WebDAV, кроме мини-перенаправителя Windows 7 при использовании дайджест-аутентификации.

Следует признать, что выбор Digest Authentication и использование мини-перенаправителя Windows 7 само по себе может быть спорным. В этой статье не обсуждаются такие варианты дизайна, как этот. Его цель — поделиться тем, что я узнал, борясь с клиентом Microsoft WebDAV, чтобы другие люди не заплатили цену в будущем.

Обычный способ подключения к серверу WebDAV из Win7 — это открыть окно проводника Windows, сопоставив сетевой диск с URL-адресом сервера. Если сервер защищен дайджест-аутентификацией, вам будет предложено ввести имя пользователя и пароль. Вы вводите, отправляете, и появляется другое окно, снова запрашивая учетные данные. Вы продолжаете вводить правильные учетные данные 3 раза, и Windows не позволит вам продолжать попытки.

Это проблема, с которой я столкнулся. Делая вещи более интересными, проблема может быть замаскирована, когда присутствует веб-отладчик Fiddler. То есть всякий раз, когда Фиддлер — человек посередине, это работает; в противном случае он перестает работать.

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

Я сделал большой шаг вперед, когда обнаружил, что у Fiddler есть две опции, связанные с подключением: «Повторное использование клиентского подключения» и «Повторное использование подключения к серверу», оба из которых включены по умолчанию, как я полагаю, по причине производительности. Рабочие / не рабочие сценарии, которые я описал ранее, могут быть воспроизведены путем включения / выключения «Повторное использование клиентского подключения» без полного отключения Fiddler.

Сравнивая шаблоны соединения моего сеанса с сеансом между клиентом Win 7 и Apache, выяснилось, что различие заключается в том, что мой сервер WebDAV всегда разрывает соединение, особенно при возврате кода состояния HTTP серии 400, например 401
Unauthorized. Исправление простое, поддержание связи на 401 немедленно решает проблему.

Мой коллега, опытный разработчик, сказал мне, что это древняя ошибка Microsoft, которая существовала более 12 лет, но они так и не исправили ее. Клиент запускает TCP-соединение C, а затем отправляет простой HTTP-запрос, сервер генерирует ответ 401 вместе с заголовком «WWW-Authenicate», включая информацию дайджеста, отправляет его обратно клиенту. В этот конкретный момент сервер может либо сохранить соединение, либо сбросить его, независимо от того, что было сказано ранее в заголовке «Соединение», «Поддерживать активность». Скажем, сервер решил разорвать соединение, когда ответ 401 попадет в клиент win 7, он вычислит заголовок «Авторизация», необходимый для дайджест-аутентификации, однако клиент win 7 настаивает на отправке этого заголовка через соединение C, созданное ранее. Если C разорван, он установит новое соединение, C ‘, отправит простой запрос БЕЗ заголовка «Авторизация». На этом этапе вы должны быть в состоянии предсказать, что произойдет дальше, и объяснить, почему многократные проблемы со входом существуют когда-либо.

Подводя итог вышеупомянутому процессу, клиент Win 7 ТОЛЬКО отправит заголовок «Авторизация» при двух условиях: 1. сразу после отправки учетных данных, т.е. когда заголовок «Авторизация» был создан впервые; 2. соединение было тем же соединением, через которое он отправил исходный простой запрос и получил ответ 401.

HTTP является протоколом без сохранения состояния, ни клиент, ни сервер не должны полагаться на какие-либо состояния, такие как состояние соединения. Надежный сервер, такой как Apache с включенным модулем WebDAV, или надежный клиент, такой как Cadaver, способен справиться с жестким клиентом, таким как клиент win 7, или жестким сервером, таким как мой сервер.

В WebDAV с Digest сложно разобраться, я только что видел, как два сервера сделали это правильно, один — популярный модуль Apache DAV, другой — мой сервер после исправления этой ошибки.

Поддержка Win 7 WebDAV действительно дрянная. Есть много других вариантов для ваших клиентов. Cadaver — это отличный WebDAV-клиент с открытым исходным кодом на платформах Linux/Unix, Mac имеет встроенную поддержку WebDAV, и сторонние клиенты, такие как Cyber ​​Duck, BitKinex и т. Д., Являются хорошим выбором. Однако, если большая часть ваших клиентов по-прежнему полагается на платформу Windows, поэтому мини-перенаправитель Win7 по-прежнему является их наиболее удобным способом доступа к их серверу WebDAV, возможно, вам все равно придется заставить его работать для клиентов. Вот некоторые другие возможные причины, по которым дайджест-аутентификация не работает.

1. Ваша логика аутентификации реализована неправильно, поэтому она не будет принимать даже правильные учетные данные
2. В теле ответа DAV используется пространство имен по умолчанию. Дополнительные сведения см. В ссылках ниже: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html https://issues.apache.org/bugzilla/show_bug.cgi?id=49428
3. Если вы отправляете заголовок «Authentication-Info», убедитесь, что он работает. Если> все отправляют заголовок «Authentication-Info», убедитесь, что он работает

Если все это не поможет вам, вот несколько подходов, которые я нашел полезными при поиске основной причины: 1. Используйте Fiddler, ngrep для захвата и изучения трафика 2. Используйте клиенты и серверы с открытым исходным кодом в качестве базовой ссылки. Вы можете узнать механизм процесса, читая код; код хорошо протестирован и надежен 3. Расширьте свои перспективы. Если HTTP-связь не работает, причиной может быть трафик (контент), тайм-аут (время), соединение (контекст) и т. Д.
4. Помните старый факт: HTTP не имеет состояния. Не следует делать никаких предположений, основываясь на добавленных состояниях. 5. Внимательно читайте RFC и не стесняйтесь задавать вопросы онлайн.

В заключение, Digest Authentication — это схема, более надежная, чем Basic.
Basic буквально не обеспечивает защиты с точки зрения современных технологий безопасности, а Digest по своей природе уязвим для человека в средней атаке. Пожалуйста, тщательно продумайте, в каком контексте безопасности вы их используете.

I have created a WebDAV share over https (self-signed) on an Ubuntu server using Apache2.

When I try to add it as a network location (on Windows 10) it fails saying the folder is not valid.

I tried to map it to a drive using net use p: https://example.com/webdav but it fails saying System error 1790 has occurred. The network logon failed.

My Apache config is:

Alias /webdav /var/www/webdav
<Directory /var/www/webdav>
DAV On
AuthType Digest
AuthName "webdav"
AuthUserFile /etc/apache2/users.password
Require valid-user
RewriteEngine off
Satisfy all
Order allow,deny
Allow from all
ForceType application/octet-stream
Options Indexes
</Directory>

Cyberduck can connect to the drive using https.

When I switch back to http, it all works. Is there a problem with Windows accepting self-signed certificates?