Как я понимаю: по умолчанию в XP веб-сервис работает под пользователем ASPNET. Вот у меня есть веб-сервис, который должен копировать файлы, а также удалять файлы. С копированием проблем не возникает, а вот с удалением всё не так просто: если файлы создавались из под вебсервиса, то их удалить можно, ну а если из под какого-то другого пользователя, тогда возникает исключение access is denied. Каким образом решить данную проблему? Не красиво было бы давать ASPNET пользователю слишком много прав, мало ли...
Hello, "SpeedLover" > Как я понимаю: по умолчанию в XP веб-сервис работает под пользователем > ASPNET. Вот у меня есть веб-сервис, который должен копировать файлы, а > также удалять файлы. С копированием проблем не возникает, а вот с > удалением всё не так просто: если файлы создавались из под вебсервиса, то > их удалить можно, ну а если из под какого-то другого пользователя, тогда > возникает исключение access is denied. Каким образом решить данную > проблему? Не красиво было бы давать ASPNET пользователю слишком много > прав, мало ли...
Запустите веб сервис под пользователем отличным от ASPNET
Posted via RSDN NNTP Server 2.0
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, SpeedLover, Вы писали:
SL>Как я понимаю: по умолчанию в XP веб-сервис работает под пользователем ASPNET. Вот у меня есть веб-сервис, который должен копировать файлы, а также удалять файлы. С копированием проблем не возникает, а вот с удалением всё не так просто: если файлы создавались из под вебсервиса, то их удалить можно, ну а если из под какого-то другого пользователя, тогда возникает исключение access is denied. Каким образом решить данную проблему? Не красиво было бы давать ASPNET пользователю слишком много прав, мало ли...
Для решения подобных проблем в ASP.NET существует имперсонация. Управляется тэгом <identity> в web.config. По умолчанию она выключена (поэтому и исполняется все от имени ASPNET). Есть два способа имперсонации. Первый от имени одной конкретной учетной записи. Второй — от имени учетной записи клиента сделавшего запрос. Очень все доступно написано в MSDN
Здравствуйте, stump, Вы писали:
S>Для решения подобных проблем в ASP.NET существует имперсонация. Управляется тэгом <identity> в web.config. По умолчанию она выключена (поэтому и исполняется все от имени ASPNET). Есть два способа имперсонации. Первый от имени одной конкретной учетной записи. Второй — от имени учетной записи клиента сделавшего запрос. Очень все доступно написано в MSDN
Значит так, у меня по умолчанию <identity impersonate="false"/> и используется ASPNET пользователь и права у него обрезаны. Пробую так <identity impersonate="true"/>, то в данном случае будет использоваться пользователь с под которого запущен сервис, то есть IUSR_WS25. Если сделаю так <identity impersonate="true" userName="domain\me" password="my_password" />, то при обращении к веб-сервисам будет использоваться моя учётная запись (администратор)? Если да, то третий вариант как бы подходит, но стоит ли давать так много прав веб-сервисам? Можно было бы и пользователя ASPNET добавить в группу админов и все проблемы зразу ж б решились. Тут хочется всего навсего дать возможность веб-сервисам удалять файлы и копировать и не больше...
Может я в чём-то ошибаюсь или не так понимаю?
Здравствуйте, SpeedLover, Вы писали:
SL>Здравствуйте, stump, Вы писали:
S>>Для решения подобных проблем в ASP.NET существует имперсонация. Управляется тэгом <identity> в web.config. По умолчанию она выключена (поэтому и исполняется все от имени ASPNET). Есть два способа имперсонации. Первый от имени одной конкретной учетной записи. Второй — от имени учетной записи клиента сделавшего запрос. Очень все доступно написано в MSDN
SL>Значит так, у меня по умолчанию <identity impersonate="false"/> и используется ASPNET пользователь и права у него обрезаны. Пробую так <identity impersonate="true"/>, то в данном случае будет использоваться пользователь с под которого запущен сервис, то есть IUSR_WS25. Если сделаю так <identity impersonate="true" userName="domain\me" password="my_password" />, то при обращении к веб-сервисам будет использоваться моя учётная запись (администратор)? Если да, то третий вариант как бы подходит, но стоит ли давать так много прав веб-сервисам? Можно было бы и пользователя ASPNET добавить в группу админов и все проблемы зразу ж б решились. Тут хочется всего навсего дать возможность веб-сервисам удалять файлы и копировать и не больше... SL>Может я в чём-то ошибаюсь или не так понимаю?
Нет. Все не так.
<identity impersonate="false"/> — используется ASPNET или LocalSystem (в зависимости от настройки в machine.config)
<identity impersonate="true"/> — используется IUSR_xx если разрешен анонимный доступ, а если анонимный доступ запрещен то используется учетная запись клиента вызвавшего сервис.
<identity impersonate="true" userName="domain\me" password="my_password" /> — используется учетная запись "domain\me" (не обязательно доменная, может быть локальная)
В чем отличие первого варианта от третьего? В первом варианте одна учетка (ASPNET) используется для всех web приложений на сервере и если ты повышаешь ей привелегии, то эти привелегии становятся доступны всем приложениям на этом сервере.
В третьем случае ты настраиваешь учетную запись для конкретного web приложения и повышаешь полномочия для конкретного приложения.
Во втором случае, права будут зависеть от того, кто вызвал сервис. Т.е. один пользователь сможет записывать файлы с помощью web сервиса, а другой получит ошибку. Все зависит от прав конкретного пользователя вызвавшего сервис.
Выбирай что тебе лучше подходит.
Здравствуйте, stump, Вы писали: S>Нет. Все не так. S><identity impersonate="false"/> — используется ASPNET или LocalSystem (в зависимости от настройки в machine.config) S><identity impersonate="true"/> — используется IUSR_xx если разрешен анонимный доступ, а если анонимный доступ запрещен то используется учетная запись клиента вызвавшего сервис. S><identity impersonate="true" userName="domain\me" password="my_password" /> — используется учетная запись "domain\me" (не обязательно доменная, может быть локальная) S>В чем отличие первого варианта от третьего? В первом варианте одна учетка (ASPNET) используется для всех web приложений на сервере и если ты повышаешь ей привелегии, то эти привелегии становятся доступны всем приложениям на этом сервере.
Замечу, что начиная с IIS 6.0 это не совсем так. В нем (если не включен старый режим изоляции) приложения живут в пулах, и для каждого пула можно указать identity независимо. По умолчанию ASP.NET будет работать под Network Service, а не ASP.NET. Можно поместить свое приложение в отдельный пул, и запустить его под идентити произвольного пользователя — эффект будет тот же, как от твоего третьего варианта.
S>В третьем случае ты настраиваешь учетную запись для конкретного web приложения и повышаешь полномочия для конкретного приложения. S>Во втором случае, права будут зависеть от того, кто вызвал сервис. Т.е. один пользователь сможет записывать файлы с помощью web сервиса, а другой получит ошибку. Все зависит от прав конкретного пользователя вызвавшего сервис. S>Выбирай что тебе лучше подходит.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Замечу, что начиная с IIS 6.0 это не совсем так. В нем (если не включен старый режим изоляции) приложения живут в пулах, и для каждого пула можно указать identity независимо. По умолчанию ASP.NET будет работать под Network Service, а не ASP.NET. Можно поместить свое приложение в отдельный пул, и запустить его под идентити произвольного пользователя — эффект будет тот же, как от твоего третьего варианта.
Абсолютно согласен. Только в начальном посте речь шла про XP и IIS 5.1. В этом контексте я и описываю ситуацию.
Вообще для IIS 6.0 актуален случай ><identity impersonate="true"/>. Остальные обеспечиваются пулом приложений.
Здравствуйте, stump, Вы писали:
S>Нет. Все не так. S><identity impersonate="false"/> — используется ASPNET или LocalSystem (в зависимости от настройки в machine.config) S><identity impersonate="true"/> — используется IUSR_xx если разрешен анонимный доступ, а если анонимный доступ запрещен то используется учетная запись клиента вызвавшего сервис. S><identity impersonate="true" userName="domain\me" password="my_password" /> — используется учетная запись "domain\me" (не обязательно доменная, может быть локальная) S>В чем отличие первого варианта от третьего? В первом варианте одна учетка (ASPNET) используется для всех web приложений на сервере и если ты повышаешь ей привелегии, то эти привелегии становятся доступны всем приложениям на этом сервере. S>В третьем случае ты настраиваешь учетную запись для конкретного web приложения и повышаешь полномочия для конкретного приложения. S>Во втором случае, права будут зависеть от того, кто вызвал сервис. Т.е. один пользователь сможет записывать файлы с помощью web сервиса, а другой получит ошибку. Все зависит от прав конкретного пользователя вызвавшего сервис. S>Выбирай что тебе лучше подходит.
В теории кажется всё понятно, но вот на практике не всё так просто.
Делаю следующее:
1. В настройках веб-приложения убираю галочку анонимного доступа.
2. Прописываю <identity impersonate="true"/>, то есть хочу использовать учётную запись клиента, вызвавшего какой-то сервис.
3. Вызываю сервис и получаю Unauthorized.
Вопрос: как происходит проверка учётной записи пользователя? Какие флаги должны быть установлены в настройках веб-приложения связанные с аутентификацией?
SL>В теории кажется всё понятно, но вот на практике не всё так просто. SL>Делаю следующее: SL>1. В настройках веб-приложения убираю галочку анонимного доступа. SL>2. Прописываю <identity impersonate="true"/>, то есть хочу использовать учётную запись клиента, вызвавшего какой-то сервис. SL>3. Вызываю сервис и получаю Unauthorized.
Замечательно! Это говорит о том что все идет по плану!
Теперь надо передать данные учетной записи с клиента. Передаются они с всойстве Credentials клиентсткого прокси класса сервиса, за что некоторые ушлые программеры называют их "кредами"
SL>Вопрос: как происходит проверка учётной записи пользователя? Какие флаги должны быть установлены в настройках веб-приложения связанные с аутентификацией?
Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как?
Здравствуйте, stump, Вы писали:
S>Здравствуйте, SpeedLover, Вы писали:
SL>>В теории кажется всё понятно, но вот на практике не всё так просто. SL>>Делаю следующее: SL>>1. В настройках веб-приложения убираю галочку анонимного доступа. SL>>2. Прописываю <identity impersonate="true"/>, то есть хочу использовать учётную запись клиента, вызвавшего какой-то сервис. SL>>3. Вызываю сервис и получаю Unauthorized. S>Замечательно! Это говорит о том что все идет по плану! S>Теперь надо передать данные учетной записи с клиента. Передаются они с всойстве Credentials клиентсткого прокси класса сервиса, за что некоторые ушлые программеры называют их "кредами" S>
SL>>Вопрос: как происходит проверка учётной записи пользователя? Какие флаги должны быть установлены в настройках веб-приложения связанные с аутентификацией?
S>Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как?
Ну расскажи, познавание нового никогда не мешало.
А я тем временем попробую реализовать передачу данных учётной записи.
S>>Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как? SL>Ну расскажи, познавание нового никогда не мешало. SL>А я тем временем попробую реализовать передачу данных учётной записи.
Это вопрос из FAQ-а. В web.config пишешь:
Здравствуйте, stump, Вы писали:
S>Здравствуйте, SpeedLover, Вы писали:
S>>>Надо чтоб был выставлен флаг "Integrated windows authentication". Флаг "Anonymous access" можно снять а можно придушить его в web конфиге. Рассказывать как? SL>>Ну расскажи, познавание нового никогда не мешало. SL>>А я тем временем попробую реализовать передачу данных учётной записи. S>Это вопрос из FAQ-а. В web.config пишешь: S>
S><authorization> S> <deny users="?" /> S></authorization> S>
S>Будет заворачивать анонимов независимо от состояния флажка "Anonymous access" в настройках web directory
Спасибо!
И так, у меня практически всё получилось, но есть ещё такая ситуация: захожу я под локальной записью (администратор) всё работает нормально, при запросе веб-сервиса через броузер выпадает окно, где ввожу имя, пароль и в ответ получаю список функций. Доступ есть — это хорошо. Другая ситуция возникает, когда я пытаюсь ввойти под удаллённой записью (админ): всё так же получаю Unauthorized. С чем это может быть связано?
Здравствуйте, SpeedLover, Вы писали:
SL>Здравствуйте, stump, Вы писали:
S>>Здравствуйте, SpeedLover, Вы писали: SL>И так, у меня практически всё получилось, но есть ещё такая ситуация: захожу я под локальной записью (администратор) всё работает нормально, при запросе веб-сервиса через броузер выпадает окно, где ввожу имя, пароль и в ответ получаю список функций. Доступ есть — это хорошо. Другая ситуция возникает, когда я пытаюсь ввойти под удаллённой записью (админ): всё так же получаю Unauthorized. С чем это может быть связано?
Имя домена надо указывать.