У меня есть сервер Dav с PHP SabreDav (code.google.com/p/sabredav/wiki/Windows) на Cherokee по защищенному URL-адресу HTTPS. Он настроен на использование https и использует дайджест-аутентификацию. Я могу войти в систему с помощью нескольких браузеров и нескольких сторонних клиентов (BitKinex и Java AnyClient также могут подключаться и просматривать, оговорки ниже).
Однако при попытке войти в систему с Windows 7 (сюрприз, сюрприз) он дважды запрашивает мой пароль, а затем сообщает мне, что моя папка недействительна.
Все безрезультатно; Windows продолжает дважды запрашивать мой пароль, а затем заявляет, что «Введенная вами папка недействительна. Выберите другую».
Командную строку попробовать? Конечно:
Лучшее, что я могу сказать на данный момент, - это «ХАХА, НЕТ WEBDAV ДЛЯ ВАС НА WINDOWS 7», что было бы хорошо, кроме всех, кто будет использовать это приложение ... использует Windows 7. И большинство из них не так настойчивы и драчливы, как я.
Мне кажется, я прожигал все случайные предложения, которые находил где-либо на первых 10 страницах Google, по каждому поисковому запросу, который мог придумать. Любые идеи? Мне нужно, чтобы это был Webdav, мне нужно, чтобы он работал по HTTPS, и мне действительно нужен способ доступа к нему из Windows 7.
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ:
Однако "сторонние" программы, которые я пробовал, были либо глючными, либо неполными, либо имели глупые ... "глюки". Например, BitKinex, похоже, фиксирует любые отправленные коды ошибок http, поэтому, если есть сбой при чтении каталога, BAM, этот каталог всегда отображается пустым. Длинные списки каталогов также отображаются как пустые, даже если панель передачи показывает, что список каталогов все еще выполняется.
В любом случае BitKinex бесполезен для целей разработки по указанным выше причинам. И, кроме того, я создаю это для других людей, кроме себя, для людей, которые захотят, чтобы эта папка dav работала «обычным способом».
Я ненавижу WebDAV.
Я заработал эту ненависть в процессе получения поддержки WebDAV в моем кластере обслуживания файлов. Это основано на Server 2008 / IIS7 с подключаемым модулем WebDAV для IIS. Это неудобно, и каждый отдельный клиент WebDAV ожидает, что сможет разговаривать с сервером WebDAV по своему собственному индивидуальному сочетанию следующего:
http://davhost.example.com/, он должен подключиться к http://davhost.example.com/root/WinXP и Win7 ведут себя по-разному. Ранние версии WinXP вообще не могут поддерживать HTTPS. Некоторые версии Windows, я забыл, которые на данный момент отслеживают сеансы только через HTTP-заголовки. Поскольку в моей среде много OSX, все версии 10.3, 10.4, 10.5 и 10.6 слегка меняют то, что они поддерживают, с точки зрения возможностей сервера. И, конечно же, у Gnome есть свои требования, которые беспокоят наших немногих пользователей Linux.
Я просто. Не могу. Выиграть.
Прямо сейчас у меня Windows 7 и WinXP отлично работают при обслуживании WebDAV из IIS7. Лома ушло много, но работает. OSX работает в основном с более новыми версиями. Все остальные рискуют.
Windows ожидает, что будут доступны определенные команды WebDAV. Проверьте, что получают ваши клиенты Win7, когда они пытаются подключиться, и отследите ошибку. Если они его не получают, это признак того, что хосту Windows по какой-то причине не нравится среда; возможно, вам нужно изменить методы отслеживания сеансов или убедиться, что хосты DAV находятся в правильной зоне безопасности IE. Просмотр журналов доступа - это то, что позволило мне вернуться к тому, что Windows ожидала от сервера WebDAV.
Вы могли подумать, что сделать WebDAV из IIS для клиентов Windows будет просто, но вы ошибаетесь, как и я.
Я столкнулся с той же проблемой и решил ее. Проще говоря, есть несколько распространенных причин проблемы.
Я подробно объяснил эту проблему на мой блог :
Почему дайджест-аутентификация не работает в мини-перенаправителе Windows 7
2 ИЮНЯ 2014 ГОДА
Вот проблема: у вас есть сервер WebDAV, он работает почти со всеми клиентами WebDAV, кроме мини-перенаправителя Windows 7 при использовании дайджест-аутентификации.
По общему признанию, почему выбор дайджест-аутентификации и использование мини-перенаправителя Windows 7 сам по себе может вызывать споры. В этой статье не обсуждаются такие варианты дизайна, как этот. Его цель - поделиться тем, что я узнал, борясь с клиентом Microsoft WebDAV, чтобы другие люди не заплатили за это в будущем.
Обычный способ подключения к серверу WebDAV из Win7 - открыть окно проводника Windows и сопоставить сетевой диск с URL-адресом сервера. Если сервер защищен дайджест-аутентификацией, вам будет предложено ввести имя пользователя и пароль. Вы вводите, отправляете, и появляется другое окно, снова запрашивая учетные данные. Вы продолжаете вводить правильные учетные данные 3 раза, и Windows не позволит вам продолжать попытки.
Это проблема, с которой я столкнулся. Что еще интереснее, проблема может быть замаскирована, когда присутствует веб-отладчик Fiddler. То есть, когда Скрипач находится посередине, это работает; в противном случае он перестает работать.
Я пытался подойти к этой проблеме со многих сторон, о которых я расскажу позже в этом посте, но не все решало проблему.
Я сделал большой шаг вперед, когда обнаружил, что у Fiddler есть две опции, связанные с подключением: «Повторное использование клиентского подключения» и «Повторное использование подключения к серверу», которые, я полагаю, включены по умолчанию из соображений производительности. Сценарии работы / неработоспособности, которые я описал ранее, можно воспроизвести, включив / выключив «Повторное использование клиентского соединения» без полного выключения Fiddler.
Сравнивая шаблоны подключения моего сеанса с сеансом между клиентом Win 7 и Apache, оказалось, что мой сервер WebDAV всегда разрывает соединение, особенно при возврате 400 серий кода состояния HTTP, например, 401 Unauthorized. Исправление простое, поддержание соединения при 401 решает проблему немедленно.
Мой коллега, опытный разработчик, сказал мне, что это древняя ошибка Microsoft, которая существует более 12 лет, но они так и не исправили ее. Клиент запускает TCP-соединение, C, а затем отправляет простой HTTP-запрос, сервер сгенерирует ответ 401 вместе с заголовком «WWW-Authenicate», включая информацию Digest, отправит его обратно клиенту. В этот конкретный момент у сервера есть выбор: либо поддерживать соединение, либо разрывать его, независимо от того, что говорилось ранее в заголовках «Соединение», «Keep-Alive». Скажем, сервер решил разорвать соединение, когда клиент win 7 получит ответ 401, он вычислит заголовок «Авторизация», необходимый для дайджест-аутентификации, однако клиент 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, вам все равно может потребоваться заставить его работать для клиентов. Вот еще несколько возможных причин, по которым дайджест-проверка подлинности не работает.
- Ваша логика аутентификации реализована неправильно, поэтому она не принимает даже правильные учетные данные
- В теле ответа DAV используется пространство имен по умолчанию. Дополнительные сведения см. По ссылкам ниже: http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html#issue-namespace-handling https://issues.apache.org/bugzilla/show_bug.cgi?id=49428
- Если вы отправляете заголовок «Authentication-Info», убедитесь, что он работает. Если> все отправляют заголовок «Authentication-Info», убедитесь, что он работает.
Если все это вам не помогает, вот несколько подходов, которые я нашел полезными при поиске первопричины: 1. Используйте Fiddler, ngrep для захвата и изучения трафика 2. Используйте клиенты и серверы с открытым исходным кодом в качестве базового справочника. Вы можете узнать механизм процесса, прочитав код; код хорошо протестирован и надежен 3. Расширьте свои перспективы. Если HTTP-соединение не работает, причиной может быть трафик (контент), тайм-аут (время), соединение (контекст) и т. Д. 4. Помните старый факт: HTTP не имеет состояния. Не следует делать никаких предположений на основе любых добавленных состояний 5. Внимательно прочтите RFC и не стесняйтесь задавать вопросы в Интернете.
Подводя итоги, дайджест-аутентификация - это схема более сильная, чем базовая. Базовый уровень буквально не обеспечивает защиты с точки зрения современных технологий безопасности, а Digest по своей природе уязвим для человека в середине атаки. Пожалуйста, подумайте, в каком контексте безопасности вы их используете.
WebDAV отлично работает, за исключением того, что клиенты Windows WebDAV не работают. Например, дайджест-проверка подлинности Windows Mini Redirector нарушена. Почему-то кажется, что можно отобразить клиента из командной строки.
На следующей странице это подробно объясняется: http://barracudaserver.com/products/BarracudaDrive/tutorials/mapping_windows_drive.lsp
Используйте другой клиент WebDAV или сервер WebDAV, например BarracudaDrive, который реализует URL-адреса сеанса. Вы входите в систему с помощью браузера и используете URL-адрес сеанса, предоставленный браузером, при сопоставлении диска.
На microsoft.com есть kb, в котором говорится, есть ли в URL-адресе дочерний каталог, например https://www.example.com/webdav это webdav, но родитель не является webdav win7, и win server 08 попытается аутентифицироваться против родителя, который НЕ является webdav. исправление здесь: http://support.microsoft.com/kb/2560598
Я подтвердил, что при такой настройке он работает должным образом. Я думаю, что другим вариантом было бы использовать поддомен webdav, например https://webdav.example.com это указывает на ваш каталог webdav.
BitKinex - единственная программа, которую я обнаружил, которая выполняет webdav для самоподписанного сертификата в Windows 7. Я надеялся на Cyberduck, но обнаружил, что у него та же проблема, запрашивает пароль еще дважды и умирает. По-видимому, люди из BitKinex раскрыли какой-то глубокий темный секрет win7 webdav с самоподписью, который выдается только некоторым членам тайных обществ. LOL BitKinex отлично справляется со своей задачей и имеет планировщики и все такое.
Я пробовал как базовую, так и дайджест-аутентификацию (через https), и ничего не смог заставить работать с клиентом Windows 7.
До сих пор я нашел единственный способ заставить это работать в Windows 7 без стороннего клиента - отказаться от аутентификации по имени пользователя и паролю и заменить ее аутентификацией по сертификату клиента. Раздел моего каталога теперь выглядит так:
<Directory /dav/dir>
AllowOverride None
Options Indexes -Includes FollowSymLinks
DirectoryIndex None
SSLRequireSSL
SSLVerifyClient require
SSLVerifyDepth 10
SSLRequire %{SSL_CLIENT_S_DN_O} eq "Org 1" or \
(%{SSL_CLIENT_S_DN_O} eq "Org 2" and %{SSL_CLIENT_S_DN_OU} eq "Org Unit 1")
DAV On
</Directory>
Раздел SSLRequire должен быть модифицированный согласно вашим собственным требованиям.
Как только это будет сделано, установите сертификат на стороне клиента. Я генерирую и распространяю свои собственные сертификаты, используя TinyCA2. Или просто используйте сторонний центр сертификации.
у нас есть https webdav на сервере за обратным прокси-сервером Apache. и служба веб-клиента в Windows не запускается, сбой монтирования с сетевым именем 0x80070043 ...
мы решили эту проблему, переписав ответ первого запроса vom windows explorer на 200 OK вместо 302 редиректа. Тогда веб-клиент запустится и монтирование завершится успешно.
Пример правил apache:
RewriteEngine On
RewriteCond %{REQUEST_URI} ^(/)$ [NC]
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]
Обновление: у нас была такая же проблема с двойным входом в систему, и я решил ее, добавив следующее в конфигурацию Apache vhost (на обратном прокси):
DefaultType None