Path.GetTempFileName — недопустимое имя каталога
https://stackoverflow.com/questions/55411
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Сталкиваемся с проблемой, когда на определенных серверах мы получаем сообщение об ошибке, что имя каталога недопустимо при использовании Path.GetTempFileName .Дальнейшее расследование показывает, что он пытается записать файл в c:\Documents и устанавливает\имя_компьютера\aspnet\локальные настройки emp (найдено с помощью Path.GetTempPath).Эта папка существует, поэтому я предполагаю, что это должно быть проблемой с разрешениями в отношении учетной записи asp.net.
Некоторые мне говорили, что Path.GetTempFileName должен указывать на C:\Windows\Microsoft.NET\Framework\v2.0.50727 emporaryasp.net files.
Мне также сказали, что эта проблема может быть связана с порядком установки IIS и .NET на сервере.Я выполнил типичный 'aspnet_regiis -i' и проверил безопасность папок и т.д.На этом этапе я застрял.
Кто-нибудь может пролить некоторый свет на это?
** Обновление:** Оказывается, что предоставление доступа 'IUSR_ComputerName' к папке делает свое дело.Это правильная процедура?Кажется, я не припоминаю, чтобы делал это в прошлом, и, очевидно, хочу следовать лучшим практикам для поддержания безопасности.В конце концов, это часть процесса загрузки файла.
Решение
Вероятно, это комбинация олицетворения и несовпадения различных методов аутентификации.
Там много фрагментов;Я постараюсь рассмотреть их один за другим.
Олицетворение это метод "временного" переключения учетной записи пользователя, под которой запущен поток.По сути, поток на короткое время получает те же права и доступ - ни больше, ни меньше - что и учетная запись, за которую выдают себя.Как только поток завершает создание веб-страницы, он "возвращается" обратно к исходной учетной записи и готовится к следующему вызову.Этот метод используется для доступа к ресурсам, доступ к которым имеет только пользователь, вошедший на ваш веб-сайт.Задержитесь на этой концепции на минуту.
Теперь по умолчанию ASP.NET запускает веб-сайт под локальной учетной записью под названием ASPNET.Опять же, по умолчанию запись в эту папку может осуществляться только учетной записью ASPNET и членами группы администраторов.Ваша временная папка находится в ведении этой учетной записи.Это вторая часть головоломки.
Олицетворение не происходит само по себе.Это должно быть намеренно включено в вашем web.config.
<identity impersonate="true" />
Если параметр отсутствует или имеет значение false, ваш код будет выполняться чисто и просто под учетной записью ASPNET, упомянутой выше.Учитывая ваше сообщение об ошибке, я уверен, что у вас есть олицетворение = true.В этом нет ничего плохого!Олицетворение имеет преимущества и недостатки, которые выходят за рамки данного обсуждения.
Остался один вопрос:когда вы используете олицетворение, какая учетная запись будет олицетворена?
Если только вы не укажете учетную запись в web.config (полный синтаксис элемента identity приведен здесь), олицетворяемая учетная запись - это та, которую IIS передал ASP.NET.И это зависит от того, как пользователь прошел аутентификацию (или нет) на сайте.Это ваша третья и последняя работа.
Учетная запись IUSR_ComputerName - это учетная запись с ограниченными правами, созданная IIS.По умолчанию эта учетная запись является учетной записью, под которой выполняется веб-вызов если пользователь не смог пройти аутентификацию.То есть пользователь заходит как "аноним".
Таким образом, это то, что происходит с вами:
Ваш пользователь пытается получить доступ к веб-сайту, и IIS по какой-то причине не смог аутентифицировать этого человека.Поскольку включен анонимный доступ (иначе вы бы не увидели, что IUSRComputerName обращается к папке temp), IIS разрешает пользователю входить в любом случае, но как обычному пользователю.Ваш ASP.NET код запускается и выдает себя за эту общую учетную запись IUSR___имя_компьютера "guest";только теперь код не имеет доступа к вещам, к которым имела доступ учетная запись ASPNET, включая ее собственную временную папку.
Предоставление IUSR_ComputerName доступа на ЗАПИСЬ к папке устраняет ваши симптомы.
Но это только симптомы.Вам нужно просмотреть почему человек приходит как "Аноним / Гость"?
Есть два вероятных сценария:
a) Вы намеревались использовать IIS для проверки подлинности, но настройки проверки подлинности в IIS для некоторых ваших серверов неверны.
В этом случае вам необходимо отключить анонимный доступ на этих серверах, чтобы были задействованы обычные механизмы аутентификации.Обратите внимание, что вам все равно может потребоваться предоставить вашим пользователям доступ к этой временной папке или использовать вместо нее другую папку, к которой у ваших пользователей уже есть доступ.
Я работал с этим сценарием много раз, и, откровенно говоря, отказ от временной папки доставляет вам меньше головной боли;создайте выделенную папку на сервере, установите соответствующие разрешения и укажите ее местоположение в web.config.
б) Вы все равно не хотели аутентифицировать людей, или вы хотели использовать ASP.NET Проверку подлинности в формах (которая использует анонимный доступ IIS для обхода проверок в IIS и позволяет ASP.NET обрабатывать аутентификацию напрямую)
Этот случай немного сложнее.
Вам следует зайти в IIS и отключить все формы аутентификации, кроме "Анонимного доступа".Обратите внимание, что вы не можете сделать это в поле разработчика, поскольку для включения отладчика требуется встроенная аутентификация.Таким образом, ваше окно отладки будет вести себя немного иначе, чем реальный сервер;просто осознайте это.
Затем вам нужно решить, следует ли отключить олицетворение или, наоборот, указать учетную запись для олицетворения в web.config.Выполните первое, если вашему веб-серверу не нужны внешние ресурсы (например, база данных).Сделайте последнее, если вашему веб-сайту действительно необходимо работать под учетной записью, имеющей доступ к базе данных (или какому-либо другому внешнему ресурсу).
У вас есть еще два варианта указать учетную запись для олицетворения.Во-первых, вы могли бы зайти в IIS и изменить "анонимную" учетную запись, чтобы она имела доступ к ресурсу, а не к той, которой IIS управляет за вас.Вторая альтернатива - сохранить учетную запись и пароль в зашифрованном виде в реестре.Этот шаг немного сложен и к тому же выходит за рамки данного обсуждения.
Удачи вам!
Другие советы
Я столкнулся с этой ошибкой при диагностике консольного приложения, которое записывало данные во временные файлы.В одной из моих тестовых итераций я удалил все файлы / каталоги из temp для запуска "с чистого листа".Я решил эту проблему, созданную самим собой, выйдя из системы и вернувшись снова.
Вы можете использовать Path.GetTempPath() чтобы выяснить, в какой каталог он пытается выполнить запись.
У меня была такая же проблема с одним из моих приложений ASP.Net.Я начинал понимать Path.GetTempPath() но это было исключение из:
"Не удалось выполнить запись в файл "C:\Windows emp\somefilename", исключение:Доступ к пути "C:\Windows emp\somefilename" запрещен".
Я попробовал несколько предложений на этой странице, но ничего не помогло.
В конце концов, я пошел на веб-сервер (сервер IIS) и изменил разрешения на сервере директории "C:\Windows emp" отдать "все" пользовательское полные разрешения на чтение-запись.
И вот, наконец, исключение исчезло, и мои пользователи смогли загружать файлы из приложения.Фух!
