В PreRequestHandlerExecute определите имя класса в файле .asmx.

В конечном счете, я пытаюсь получить ссылку на веб-метод, который будет обрабатывать запрос, ДО того, как он обработает запрос, чтобы проверить его пользовательские атрибуты.

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

Если не считать открытия файла и его синтаксического анализа - есть ли способ, которым, учитывая путь запроса к файлу asmx, я могу получить ссылку либо на тип класса внутри, либо на имя типа класса внутри?

Довольно новичок в .NET, поэтому то, что я делаю, может быть глупым. Но в любом случае мне будет интересен ответ :)

РЕДАКТИРОВАТЬ: это не мой проект, и он заблокирован для использования веб-сервисов ASP.NET 3.5 и asmx.

РЕДАКТИРОВАТЬ: Цель состоит в том, чтобы предотвратить выполнение определенных веб-сервисов пользователями, не прошедшими проверку подлинности, без добавления кода аутентификации для каждого веб-метода. Моя идея состояла в том, чтобы использовать настраиваемый атрибут для веб-методов, помечая их как общедоступные, и только те, которые будут разрешены пользовательским HTTP-модулем или обработчиком для выполнения пользователем, не прошедшим проверку подлинности. Тип пользователя хранится в сеансе.


person David Q Hogan    schedule 06.07.2011    source источник


Ответы (1)


Прежде всего, я предлагаю вам переключиться на веб-службы WCF, поскольку asmx теперь считается устаревшей технологией (см. ="nofollow">MSDN). В конвейере WCF есть несколько точек расширения, которые должны соответствовать вашим целям.

Теперь сказал, что одним из хакерских решений может быть установка собственного обработчика или фабрики обработчиков для файлов asmx, а затем использование WebServiceParser.GetCompiledType, чтобы получить фактический тип службы asmx, проверьте свои атрибуты. Затем вы можете использовать WebServiceHandlerFactory.GetHandler для создания фактического обработчика и выполнения запроса.

Возможно, вам следует объяснить, что вы хотите делать с пользовательскими атрибутами, чтобы кто-то мог предложить вам лучшее решение.

EDIT: если вы хотите защитить весь asmx или каталог, это можно легко сделать с помощью встроенной авторизации, например:

<location path="secure.asmx">
 <system.web>
   <authorization>
     <allow users="*" />
     <deny users="?" />
   </authorization>
 </system.web>
</location>

Это разрешит доступ всем аутентифицированным пользователям и запретит анонимным пользователям.

Если вам нужен детальный контроль на уровне веб-метода, я предлагаю поместить всю логику во вспомогательный метод, скажем, EnforceSecurity (статический метод или метод экземпляра при вызове базового веб-сервиса для asmx) и вызывать вспомогательный метод в соответствующих веб-методах. Это более или менее эквивалентно тому, что вы хотите сделать - вместо того, чтобы украшать методы пользовательским атрибутом, вы вставите в него вызов метода.

person VinayC    schedule 06.07.2011
comment
Спасибо за WebServiceParser.GetCompiledType - это сделало один неприятный шаг из процесса. К сожалению, я слишком новый пользователь, чтобы голосовать за вас. Я обновил исходный вопрос, добавив больше информации о том, чего я пытаюсь достичь. Знаете ли вы что-то подобное, что разрешит сам веб-метод с учетом класса и контекста? Тем временем я решу использовать Request.PathInfo xor параметр op GET - person David Q Hogan; 06.07.2011
comment
@Смотри мое редактирование в ответе. Я считаю, что если вы можете разделить свои безопасные и небезопасные методы на разные asmx, то применение безопасности может быть намного проще. - person VinayC; 06.07.2011
comment
Единственное реальное преимущество этого подхода заключается в том, что я могу иметь поведение по умолчанию, требующее доступа на уровне пользователя, без необходимости вызывать метод EnforceSecurity, поэтому я могу поступить так, как вы предлагаете. Первоначально я начал с атрибутов, так как ошибочно предположил, что они похожи на декораторы Python, позволяя коду декоратора выполняться до и/или после декорированного метода. Я не использую встроенную структуру авторизации, поскольку серверы IIS могут быть не настроены в режиме веб-фермы, а балансировщик нагрузки не обязательно будет отправлять последовательные запросы от одного и того же пользователя на один и тот же сервер IIS. - person David Q Hogan; 06.07.2011
comment
@DavidQHogan, встроенная аутентификация и авторизация ASP.NET выполняет/не может передавать состояние на стороне сервера (токен аутентификации сохраняется в файле cookie), поэтому я не вижу никаких проблем в сценарии веб-фермы. Для аспектно-ориентированного программирования (АОП) в .NET вы должны полагаться на бесплатные/коммерческие библиотеки - они позволят вам иметь перехватчики методов до/после. См. этот пост в блоге для различных статей и инструментов: weblogs.asp.net/podwysocki/archive/2008/03/28/ - person VinayC; 07.07.2011