Мы используем Microsoft SCCM 2007 для развертывания программных пакетов в нашей сетевой среде. Один из пакетов (MathType, на случай, если кому-то интересно) содержит множество имен файлов со знаком плюса. + в них.
Когда пакет загружается на клиентский компьютер, файлы извлекаются с сервера точки распространения через http. Точка распространения запускает IIS, который не обрабатывает + подписывает URL-адреса. В результате клиент SCCM получает от сервера сообщение 404 и не может завершить загрузку или установку пакета.
Я бы просто переименовал все файлы с + в них, но установщик ожидает определенных имен файлов, поэтому нам нужно сохранить исходную схему именования. Из-за того, как настроена наша сетевая среда, у нас нет прямого контроля над сервером точки распространения, поэтому мы не можем вносить какие-либо изменения в IIS, которые позволили бы + символы в URL.
Как мы можем распространять пакеты, которые включают файлы с + символ без нарушения SCCM?
Я подумал о следующих обходных путях, но хотел бы найти более элегантное решение, которое не требует ручной настройки какого-либо пакета с помощью + символы:
files+with+plusses к files_with_plusses, затем вручную измените их на исходное имя в пакетном файле установки после их загрузки в локальный кеш.Есть ли решение, которое действительно устраняет проблему, а не работает над ней?
Is there a solution that actually fixes the problem, rather than working around it?
Все зависит от того, как вы определяете «проблему». На мой взгляд, «проблема» в том, что кто-то решил, что было бы неплохо включить специальные символы в путь к файлу своего программного обеспечения, хотя это было плохой идеей. (Он не одинок, если от этого вам станет лучше ... или хуже.) В результате вы не можете просто передать эти пути в IIS, потому что он по умолчанию отклоняет пути с определенными символами в качестве меры безопасности (чтобы защитить от злонамеренно созданных URL-адресов).
В общем случае возможным «исправлением» этого, которое не требует переименования файлов, является отключение этой функции безопасности в веб-конфигурации приложения (разрешить двойное экранирование). Но поскольку это сделает вас уязвимыми для злонамеренно созданных URL-адресов, я не уверен, что вижу в этом исправление, а скорее как обходной путь с большой дырой в безопасности. Поскольку вы не можете этого сделать, все равно это в основном академическое.
Ваши основные параметры - изменить настройки IIS, чтобы разрешить пути, содержащие +, или как-то удалить / скрыть + в пути. Поскольку вы не можете сделать первое, вам остается только второй вариант. Как бы то ни было, создание самораспаковывающегося архива из проблемного приложения звучит так, как будто его было бы проще автоматизировать, так что я бы пошел с этим.