0

Ultimately, i'm trying to obtain a reference to the webmethod that will handle a request, BEFORE it handles the request, in order to check its custom attributes.

Currently, I have it working by appending the request path to the project namespace, removing the .asmx extension and replacing slashes with dots. However, this assumes that the class namespace hierarchy matches the request path hierarchy, and there's no reason why it should.

Short of opening the file and parsing it - is there a way that given a request path to an asmx file I can retrieve a reference to either the class type within or the name of the class type within?

Pretty new to .NET so what i'm doing might be silly. But either way, i'd be interested in the answer :)

EDIT: It's not my project, and it's locked in to using ASP.NET 3.5 and asmx webservices

EDIT: The aim is to be able to prevent certain webservices from being executed by unauthenticated users, without adding authentication code to every webmethod. My idea was to use a custom attribute on webmethods marking them as public, and only those will be allowed by a custom HTTP module or handler to be executed by an unauthenticated user. The type of user is stored in the session.

David Hogan
  • 549
  • 6
  • 6

1 Answers1

1

First of all, I will suggest that you switch to WCF web services because asmx is now considered as legacy technologies (see MSDN). WCF has several extension points in its pipe-line that should meet your goals.

Now said that, one of the hack solution could be to put your own handler or handler factory for asmx files and then use WebServiceParser.GetCompiledType method to get actual asmx service type, inspect your attributes. You can then use WebServiceHandlerFactory.GetHandler to create actual handler and execute the request.

Perhaps, you should explain what you want to do with custom attributes so that someone can provide you with the better solution.

EDIT: In case you want to secure the entire asmx or directory then it can be easily possibly using built-in authorization - for example:

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

This will allow access to all authenticated users and deny to anonymous users.

If you want a granular control at web method level then I will suggest to put the entire logic in a helper method - say EnforceSecurity (static method or instance method on base web service call for asmx) and invoke the helper method in relevant web methods. Its more or less equivalent from what you wish to do - instead of decorating methods with custom attribute, you will insert a method call into it.

VinayC
  • 47,395
  • 5
  • 59
  • 72
  • Thanks for WebServiceParser.GetCompiledType - it's taken one nasty step out of the process. Sadly i'm too new a user to vote you up. I've updated the original question with more information about what I am trying to achieve. Do you know of something similar that will resolve a the webmethod itself given the class and the context? In the meantime i'll resolve using the Request.PathInfo xor the op GET parameter – David Hogan Jul 06 '11 at 12:13
  • @See my edit in answer. I believe if you can separate your secure and un-secure methods into different asmx then applying security can be a lot simpler. – VinayC Jul 06 '11 at 12:35
  • The only real advantage of this approach is that I can have the default behaviour to require user level access without needing to invoke the EnforceSecurity method, so I may do as you suggest. I originally started with attributes as I mistakenly assumed that they were like Python decorators in allowing decorator code to run before and/or after the decorated method. I'm not using the inbuilt authorization framework as the IIS servers might not be configured in web farm mode, and the load balancer will not necessarily send consecutive requests from the same user to the same IIS server. – David Hogan Jul 06 '11 at 13:11
  • @DavidQHogan, in-built ASP.NET authentication & authorization does/may not relay on server side state (authentication token gets stored in cookie) - so I don't see any issue in web farm scenario. For aspect oriented programming(AOP) in .NET, you have to rely on free/commercial libraries - those will allow you to have pre/post method hooks. See this blog post for various articles & tools: http://weblogs.asp.net/podwysocki/archive/2008/03/28/understanding-aop-in-net.aspx – VinayC Jul 07 '11 at 04:22