Path.GetTempFileName - имя каталога неверно - PullRequest
9 голосов
/ 11 сентября 2008

Встречается проблема, когда на определенных серверах мы получаем ошибку, что имя каталога недопустимо при использовании Path.GetTempFileName. Дальнейшее расследование показывает, что он пытается записать файл в c: \ Documents and Setting \ computername \ aspnet \ local settings \ temp (найденный с помощью Path.GetTempPath). Эта папка существует, поэтому я предполагаю, что это проблема с правами доступа к учетной записи asp.net.

Некоторые говорили мне, что Path.GetTempFileName должен указывать на файлы C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ временный .p.net.

Мне также сказали, что эта проблема может быть связана с тем, в каком порядке IIS и .NET установлены на сервере. Я сделал типичный «aspnet_regiis -i» и проверил безопасность папок и т. Д. На данный момент я застрял.

Кто-нибудь может пролить свет на это?

** Обновление: ** Оказывается, что предоставление доступа к папке «IUSR_ComputerName» делает свое дело. Это правильная процедура? Кажется, я не помню, чтобы делал это в прошлом, и, очевидно, хочу следовать передовым методам обеспечения безопасности. В конце концов, это часть процесса загрузки файла.

Ответы [ 5 ]

18 голосов
/ 13 сентября 2008

Вероятно, это сочетание олицетворения и несовпадения различных методов аутентификации.

Есть много штук; Я постараюсь пройтись по ним один за другим.

Олицетворение - это метод "временного" переключения учетной записи пользователя, под которой запущен поток. По сути, поток на короткое время получает те же права и доступ - не больше и не меньше - как учетная запись, которая олицетворяется. Как только поток завершает создание веб-страницы, он «возвращается» к исходной учетной записи и готовится к следующему вызову. Этот метод используется для доступа к ресурсам, к которым имеет доступ только пользователь, вошедший на ваш веб-сайт. Задержись на минутку.

Теперь по умолчанию ASP.NET запускает веб-сайт под локальной учетной записью с именем ASPNET . Опять же, по умолчанию только учетная запись ASPNET и члены группы «Администраторы» могут писать в эту папку. Ваша временная папка находится в компетенции этой учетной записи. Это вторая часть головоломки.

Олицетворение не происходит само по себе. Его нужно включить намеренно в вашем файле web.config.

<identity impersonate="true" />

Если параметр отсутствует или имеет значение false, ваш код будет выполняться чисто под простой учетной записью ASPNET, упомянутой выше. Учитывая ваше сообщение об ошибке, я уверен, что у вас есть олицетворение = true. Там нет ничего плохого! Олицетворение имеет свои преимущества и недостатки, которые выходят за рамки этого обсуждения.

Остается один вопрос: когда вы используете олицетворение, какая учетная запись олицетворяется ?

Если вы не укажете учетную запись в файле web.config ( полный синтаксис элемента удостоверения личности здесь ), олицетворенная учетная запись будет передаваться IIS ASP.NET. И это зависит от того, как пользователь прошел аутентификацию (или нет) на сайте. Это ваш третий и последний кусок.

Учетная запись IUSR_ComputerName - это учетная запись с ограниченными правами, созданная IIS. По умолчанию эта учетная запись является учетной записью, под которой выполняется веб-вызов , если пользователь не может пройти проверку подлинности . То есть пользователь входит как «аноним».

Подводя итог, вот что с вами происходит:

Ваш пользователь пытается получить доступ к веб-сайту, и IIS по какой-то причине не может аутентифицировать человека. Поскольку анонимный доступ включен, (или вы не увидите, чтобы IUSRComputerName обращался к временной папке), IIS разрешает пользователю вход в любом случае, но в качестве общего пользователя. Ваш код ASP.NET запускается и олицетворяет эту общую учетную запись гостя IUSR___ComputerName; только теперь код не имеет доступа к тем вещам, к которым имел доступ учетная запись ASPNET, включая собственную временную папку.

Предоставление IUSR_ComputerName WRITE доступа к папке устраняет симптомы.

Но это только симптомы. Вам необходимо просмотреть почему человек приходит как "Аноним / Гость"?

Существует два вероятных сценария:

a) Вы намеревались использовать IIS для аутентификации, но настройки аутентификации в IIS для некоторых ваших серверов неверны.

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

Я много раз работал с этим сценарием, и, откровенно говоря, он дает вам меньше головной боли, чтобы отказаться от папки Temp; создайте выделенную папку на сервере, установите соответствующие разрешения и укажите ее местоположение в web.config.

b) Вы все равно не хотели проверять подлинность людей или хотели использовать проверку подлинности с помощью форм ASP.NET (которая использует анонимный доступ IIS для обхода проверок в IIS и позволяет ASP.NET напрямую обрабатывать проверку подлинности)

Этот случай немного сложнее.

Вам необходимо зайти в IIS и отключить все формы аутентификации, кроме «Анонимный доступ». Обратите внимание, что вы не можете сделать это в окне разработчика, потому что для отладчика требуется встроенная аутентификация. Таким образом, ваш блок отладки будет вести себя немного иначе, чем реальный сервер; просто знайте об этом.

Затем вам нужно решить, следует ли отключить олицетворение или, наоборот, указать учетную запись для олицетворения в файле web.config. Сделайте первое, если вашему веб-серверу не нужны внешние ресурсы (например, база данных). Сделайте последнее, если ваш веб-сайт должен работать под учетной записью, имеющей доступ к базе данных (или другому внешнему ресурсу).

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

Удачи!

2 голосов
/ 11 сентября 2008

Возможно, потому что IIS_WPG не имеет доступа к временной папке. Если вы считаете, что это проблема с разрешениями, запустите Procmon на рабочем процессе asp.net и проверьте наличие ошибок AccessDenied.

1 голос
/ 25 июля 2017

Я столкнулся с этой ошибкой при диагностике консольного приложения, которое записывало во временные файлы. В одной из моих тестовых итераций я удалил все файлы / каталоги в temp для запуска «чистого листа». Я решил эту проблему самостоятельно, выйдя из системы и снова войдя в нее.

0 голосов
/ 07 февраля 2013

У меня была такая же проблема с одним из моих приложений ASP.Net. Я получаю Path.GetTempPath () , но выдается исключение:

"Не удалось записать в файл" C: \ Windows \ Temp \ somefilename ", исключение: доступ к пути" C: \ Windows \ Temp \ somefilename "запрещен."

Я попробовал несколько предложений на этой странице, но ничего не помогло.

В конце концов я зашел на веб-сервер (сервер IIS) и изменил разрешения в каталоге «C: \ Windows \ Temp» на сервере, чтобы предоставить пользователю «Все» полные права на чтение и запись.

И, наконец, исключение исчезло, и мои пользователи могли загружать файлы из приложения. Уф!

0 голосов
/ 11 сентября 2008

Вы можете использовать Path.GetTempPath () , чтобы узнать, в какой каталог он пытается записать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...