I was looking for a way to route http://www.example.com/WebService.asmx to http://www.example.com/service/ using only the ASP.NET 3.5 Routing framework without needing to configure the IIS server.
Until now I have done what most tutorials told me, added a reference to the routing assembly, configured stuff in the web.config, added this to the Global.asax:
protected void Application_Start(object sender, EventArgs e)
{
RouteCollection routes = RouteTable.Routes;
routes.Add(
"WebService",
new Route("service/{*Action}", new WebServiceRouteHandler())
);
}
...created this class:
public class WebServiceRouteHandler : IRouteHandler
{
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
// What now?
}
}
...and the problem is right there, I don't know what to do. The tutorials and guides I've read use routing for pages, not webservices. Is this even possible?
Ps: The route handler is working, I can visit /service/ and it throws the NotImplementedException I left in the GetHttpHandler method.
Just thought I would round off this question with a bit more of a detailed solution based on the answer given by Markives that worked for me.
Firstly here is the route handler class which takes the virtual directory to your WebService as its constructor param.
public class WebServiceRouteHandler : IRouteHandler
{
private string _VirtualPath;
public WebServiceRouteHandler(string virtualPath)
{
_VirtualPath = virtualPath;
}
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
return new WebServiceHandlerFactory().GetHandler(HttpContext.Current,
"*",
_VirtualPath,
HttpContext.Current.Server.MapPath(_VirtualPath));
}
}
and the actual usage of this class within the routey bit of Global.asax
routes.Add("SOAP",
new Route("soap", new WebServiceRouteHandler("~/Services/SoapQuery.asmx")));
This is for anyone else who wants to do the above. I found it incredibly difficult to find the information.
In the GetHttpHandler(byVal requestContext as RequestContext) as IHttpHandler Implements IRouteHandler.GetHttpHandler method (my version of the above)
This is for Webforms 3.5 by the way (mine's in VB).
You cant use the usual BuildManager.CreateInstanceFromVirtualPath() method to invoke your web servce that's only for things that implement iHttpHandler which .asmx doesn't. Instead you need to:
Return New WebServiceHandlerFactory().GetHandler(
HttpContext.Current, "*", "/VirtualPathTo/myWebService.asmx",
HttpContext.Current.Server.MapPath("/VirtualPathTo/MyWebService.aspx"))
The MSDN documentation says that the 3rd parameter should be the RawURL, passing HttpContext.Current.Request.RawURL doesn't work, but passing the virtual path to the .asmx file instead works great.
I use this functionality so that my webservice can be called by any Website configured in anyway (even a virtual directory) that points (in IIS) to my application can call the application web service using something like "http://url/virtualdirectory/anythingelse/WebService" and the routing will always route this to my .asmx file.
You need to return an object that implements IHttpHandler, that takes care of your request.
You can check out this article on how to implement a webservice using that interface: http://mikehadlow.blogspot.com/2007/03/writing-raw-web-service-using.html
But this is probably closer to what you want http://forums.asp.net/p/1013552/1357951.aspx (There is a link, but it requires registration, so I didnt test)
Related
I'm trying to implement an VirtualPathProvider for SharePoint 2010/2013 (Server and Foundation). So far I've implemented subclasses of System.Web.Hosting.VirtualPathProvider, System.Web.Hosting.VirtualFile and System.Web.Hosting.VirtualDirectory.
I wanted to use a feature with FeatureReceiver class to register the new VPP with the HostingEnvironment. But since I have implemented the line
HostingEnvironment.RegisterVirtualPathProvider(new MyVPProvider());
into the FeatureActivated method, VisualStudio's debug deployment fails with:
Error occurred in deployment step 'Activate Features': Operation is not valid due to the current state of the object.
I have no idea what I am doing wrong. Maybe a FeatureReceiver is the wrong place to register the VPP?
I've already searched the web for an tutorial or example but I didn't find any suitable. Any hint on how to develop a VirtualPathProvider for SharePoint is much appreciated! Thanks in advance.
--
Robert Vogel
You need to write an IHttpModule implementation which registers your virtual path provider ones.
Maybe this link helps you: SharePoint 2007 as a WCF host - Step #4, Write a Virtual Path Provider
using System.Web;
public class MyVirtualPathProviderRegisterModule : IHttpModule
{
static bool _Initialized = false;
static object _Lock = new object();
public void Init(HttpApplication app)
{
if (!_Initialized)
lock(_Lock)
if(!_Initialized)
{
HostingEnvironment.RegisterVirtualPathProvider(new MyVirtualPathProvider());
_Initialized = true;
}
}
public void Dispose() {}
}
I need to do routing in an existing asp.net app - not an asp.net mvc (yeah I know I should convert but let's say it's not possible right now so don't tell me :) ) - how can I do routing to a normal class instead of an aspx page as all sample code I see is always with aspx page like here:
http://msdn.microsoft.com/en-us/magazine/dd347546.aspx
To precise, I want to do a bit like in MVC Controller routing : the controller for example product is a pure class you access through http://domain.com/product
ASP.NET MVC and ASP.NET Web Forms share the same routing infrastructure in that both frameworks ultimately need to come up with an IHttpHandler to handle the HTTP request:
The IHttpHandler interface has been a part of ASP.NET since the
beginning, and a Web Form (a System.Web.UI.Page) is an IHttpHandler.
(From the MSDN article linked in the question)
In ASP.NET MVC the System.Web.Mvc.MvcHandler class is used, which then delegates to a controller for further handling of the request. In ASP.NET Web Forms usually the System.Web.UI.Page class that represents an .aspx file is used, but a pure IHttpHandler associated with .ashx file can also be used.
So you can route to an .ashx handler as an alternative to an .aspx Web Forms page. Both implement IHttpHandler (as does MvcHandler), but with the former that's all it does. And that's as close as you can get to a 'pure class' handling a (routed) request. And since the handler part is just an interface, you are free to inherit from your own class.
<%# WebHandler Language="C#" Class="LightweightHandler" %>
using System.Web;
public class LightweightHandler : YourBaseClass, IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
context.Response.ContentType = "text/plain";
context.Response.Write("Hello world!");
}
public bool IsReusable { get { return false; } }
}
Notice that an IRouteHandler just needs to return an instance of IHttpHandler:
public IHttpHandler GetHttpHandler(RequestContext requestContext);
You may need to jump through some hoops to instantiate your handler using the BuildManager* if you use .ashx files. If not, you can just new up an instance of your class and return it:
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
// In case of an .ashx file, otherwise just new up an instance of a class here
IHttpHandler handler =
BuildManager.CreateInstanceFromVirtualPath(path, typeof(IHttpHandler)) as IHttpHandler;
// Cast to your base class in order to make it work for you
YourBaseClass instance = handler as YourBaseClass;
instance.Setting = 42;
instance.DoWork();
// But return it as an IHttpHandler still, as it needs to do ProcessRequest
return handler;
}
See the answers to this question for much more in-depth analysis of routing pure IHttpHandlers: Can ASP.NET Routing be used to create “clean” URLs for .ashx (IHttpHander) handlers?
**I'm not entirely sure about the BuildManager example, someone please correct me if I got that part wrong*
If you can't switch to ASP.NET MVC and routing .ashx handlers doesn't meet your requirements, you may want to look into Nancy, a 'lightweight web framework'.
Here's an example from the introduction (see link in previous paragraph):
public class Module : NancyModule
{
public Module() : base("/foo")
{
Get["/"] = parameters => {
return "This is the site route";
};
Delete["/product/{id}"] = parameters => {
return string.Concat("You requested that the following product should be deleted: ", parameters.id);
};
}
}
This class will handle requests to /foo and /foo/product/42. You can also use views with this framework to render a more complex (HTML) response.
If you can update from 3.5 to 4.0, WebForms supports routing better. In Global.asax, you only need to do things like this:
void Application_Start(object sender, EventArgs e)
{
RouteTable.Routes.MapPageRoute("default", string.Empty, "~/default.aspx");
}
I don't really understand the "pure class" part, but hopefully if updating to 4.0 is an option this can get you going.
I'm just getting started with ServiceStack and, as a test case, I am looking to rework an existing service which is built using standard ASP.Net handlers. I've managed to get it all working as I want it but have certain aspects which make use of the ASP.Net Session object.
I've tried adding IRequiresSessionState into the service interface:
public class SessionTestService : RestServiceBase<SessionTest>, IRequiresSessionState {
public override object OnPost(SessionTest request) {
// Here I want to use System.Web.HttpContext.Current.Session
}
}
The trouble is I can't seem to get it to work as the Session object is always null.
I've done a lot of Googling and have puzzled over https://github.com/mythz/ServiceStack/blob/master/tests/ServiceStack.WebHost.IntegrationTests/Services/Secure.cs and similar but I can't find any example code which does this (which surprises me). Can anyone explain why the above doesn't work and advise what I need to do to get it working?
Note: Ultimately I'll probably look to replace this with Redis or will try to remove any serverside session requirement, but I figured that I'd use the ASP.Net implementation for the time being, to get things working and to avoid reworking it more than is necessary at this point.
Using ServiceStack ISession
ServiceStack has a new ISession interface backed by ICacheClient that lets you share same ISession between MVC Controllers, ASP.NET base pages and ServiceStack's Web Services which share the same Cookie Id allowing you to freely share data between these web frameworks.
Note: ISession is a clean implementation that completely by-passes the existing ASP.NET session with ServiceStack's own components as described in ServiceStack's MVC PowerPack and explained in detail in the Sessions wiki page.
To easily make use of ServiceStack's Session (Cache & JSON Serializer) have your Controllers inherit from ServiceStackController (in MVC) or PageBase (in ASP.NET)
There is also new Authentication / Validation functionality added in ServiceStack which you can read about on the wiki:
Authentication and authorization
Validation
Using ASP.NET Session
Essentially ServiceStack is just a set of lightweight IHttpHandler's running on either an ASP.NET or HttpListener host. If hosted in IIS/ASP.NET (most common) it works like a normal ASP.NET request.
Nothing in ServiceStack accesses or affects the configured Caching and Session providers in the underlying ASP.NET application. If you want to enable it you would need to configure it as per normal in ASP.NET (i.e. outside of ServiceStack) see:
http://msdn.microsoft.com/en-us/library/ms178581.aspx
Once configured you can access the ASP.NET session inside a ServiceStack web service via the singleton:
HttpContext.Current.Session
Or alternatively via the underlying ASP.NET HttpRequest with:
var req = (HttpRequest)base.RequestContext.Get<IHttpRequest>().OriginalRequest;
var session = req.RequestContext.HttpContext.Session;
Although because of the mandatory reliance on XML config and degraded performance by default, I prefer to shun the use of ASP.NET's Session, instead opting to use the cleaner Cache Clients included with ServiceStack.
Basically the way Sessions work (ASP.NET included) is a cookie containing a unique id is added to the Response uniquely identifying the browser session. This id points to a matching Dictionary/Collection on the server which represents the browsers' Session.
The IRequiresSession interface you link to doesn't do anything by default, it simply is a way to signal to either a Custom Request Filter or base web service that this request needs to be authenticated (i.e. two places where you should put validation/authentication logic in ServiceStack).
Here's a Basic Auth implementation that looks to see if a web service is Secure and if so make sure they have authenticated.
Here's another authentication implementation that instead validates all services marked with an [Authenticate] attribute, and how to enable Authentication for your service by adding the Attribute on your Request DTO.
New Authentication Model in ServiceStack
The above implementation is apart of the multi-auth provider model included in the next version of ServiceStack. Here's the reference example showing how to register and configure the new Auth model in your application.
Authentication Strategies
The new Auth model is entirely an opt-in convenience as you can simply not use it and implement similar behaviour yourself using Request Filters or in base classes (by overriding OnBeforeExecute). In fact the new Auth services are not actually built-into ServiceStack per-se. The entire implementation lives in the optional ServiceStack.ServiceInterfaces project and implemented using Custom Request Filters.
Here are different Authentication strategies I've used over the years:
Mark services that need authentication with an [Attribute]. Likely the most idiomatic C# way, ideal when the session-id is passed via a Cookie.
Especially outside of a Web Context, sometimes using a more explicit IRequiresAuthentication interface is better as it provides strong-typed access to the User and SessionId required for Authentication.
You can just have a 1-liner to authenticate on each service that needs it - on an adhoc basis. A suitable approach when you have very few services requiring authentication.
That's a great and comprehensive answer by #mythz. However, when trying to access the ASP.NET session by HttpContext.Current.Session within a ServiceStack web service, it always returns null for me. That's because none of the HttpHandlers within ServiceStack are adorned with the IRequiresSessionState interface, so the .NET Framework does not provide us with the session object.
To get around this, I've implemented two new classes, both of which use the decorator pattern to provide us with what we need.
Firstly, a new IHttpHandler which requires session state. It wraps the IHttpHandler provided by ServiceStack and passes calls through to it...
public class SessionHandlerDecorator : IHttpHandler, IRequiresSessionState {
private IHttpHandler Handler { get; set; }
internal SessionHandlerDecorator(IHttpHandler handler) {
this.Handler = handler;
}
public bool IsReusable {
get { return Handler.IsReusable; }
}
public void ProcessRequest(HttpContext context) {
Handler.ProcessRequest(context);
}
}
Next, a new IHttpHandlerFactory which delegates the responsibility for generating the IHttpHandler to ServiceStack, before wrapping the returned handler in our new SessionHandlerDecorator...
public class SessionHttpHandlerFactory : IHttpHandlerFactory {
private readonly static ServiceStackHttpHandlerFactory factory = new ServiceStackHttpHandlerFactory();
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated) {
var handler = factory.GetHandler(context, requestType, url, pathTranslated);
return handler == null ? null : new SessionHandlerDecorator(handler);
}
public void ReleaseHandler(IHttpHandler handler) {
factory.ReleaseHandler(handler);
}
}
Then, it's just a matter of changing the type attributes in the handlers in Web.config to SessionHttpHandlerFactory instead of ServiceStack.WebHost.Endpoints.ServiceStackHttpHandlerFactory, ServiceStack, and your web services should now have the ASP.NET session avaialble to them.
Despite the above, I fully endorse the new ISession implementation provided by ServiceStack. However, in some cases, on a mature product, it just seems too big a job to replace all uses of the ASP.NET session with the new implementation, hence this workaround!
Thanks #Richard for your answer above. I am running a new version of service stack and they have removed the ServiceStackHttpFactory with HttpFactory. Instead of having
private readonly static ServiceStackHttpHandlerFactory factory = new ServiceStackHttpHandlerFactory();
You need to have
private static readonly HttpHandlerFactory Factory = new HttpHandlerFactory();
Here is updated code for this service
using ServiceStack;
using System.Web;
using System.Web.SessionState;
namespace MaryKay.eCommerce.Mappers.AMR.Host
{
public class SessionHttpHandlerFactory : IHttpHandlerFactory
{
private static readonly HttpHandlerFactory Factory = new HttpHandlerFactory();
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
var handler = Factory.GetHandler(context, requestType, url, pathTranslated);
return handler == null ? null : new SessionHandlerDecorator(handler);
}
public void ReleaseHandler(IHttpHandler handler)
{
Factory.ReleaseHandler(handler);
}
}
public class SessionHandlerDecorator : IHttpHandler, IRequiresSessionState
{
private IHttpHandler Handler { get; set; }
internal SessionHandlerDecorator(IHttpHandler handler)
{
Handler = handler;
}
public bool IsReusable
{
get { return Handler.IsReusable; }
}
public void ProcessRequest(HttpContext context)
{
Handler.ProcessRequest(context);
}
}
}
As of ServiceStack 4.5+ the HttpHandler can also support Async. Like so:
namespace FboOne.Services.Host
{
public class SessionHttpHandlerFactory : IHttpHandlerFactory
{
private static readonly HttpHandlerFactory Factory = new HttpHandlerFactory();
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
var handler = Factory.GetHandler(context, requestType, url, pathTranslated);
return handler == null ? null : new SessionHandlerDecorator((IHttpAsyncHandler)handler);
}
public void ReleaseHandler(IHttpHandler handler)
{
Factory.ReleaseHandler(handler);
}
}
public class SessionHandlerDecorator : IHttpAsyncHandler, IRequiresSessionState
{
private IHttpAsyncHandler Handler { get; set; }
internal SessionHandlerDecorator(IHttpAsyncHandler handler)
{
Handler = handler;
}
public bool IsReusable
{
get { return Handler.IsReusable; }
}
public void ProcessRequest(HttpContext context)
{
Handler.ProcessRequest(context);
}
public IAsyncResult BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
{
return Handler.BeginProcessRequest(context, cb, extraData);
}
public void EndProcessRequest(IAsyncResult result)
{
Handler.EndProcessRequest(result);
}
}
}
I'm trying to get Session enabled in the GettHttpHandler method of my IRouteHandler classes but session is always null. Could someone tell me what I'm doing wrong?
In global.asax I have
RouteTable.Routes.Add("All", new Route("{*page}", new MyRouteHandler()));
The MyRouteHandler class where Session is null looks like this:
public class MyRouteHandler : IRouteHandler, IRequiresSessionState
{
public System.Web.IHttpHandler GetHttpHandler(RequestContext requestContext)
{
string test = HttpContext.Current.Session["test"].ToString();
return BuildManager.CreateInstanceFromVirtualPath("~/Page.aspx", typeof(Page)) as Page;
}
}
I made a small test app that shows the problem.
Could someone tell me what I'm doing wrong?
Edited to add:
Yes, I really need session data in the route handler. There are many reasons but one easily explainable is when the user can switch to browse the site in preview mode.
The site consists of a hierarchy of dynamic pages (/page1/page2...) in the database that can be published normally or to preview. A content producer browsing the site can choose to view just normal pages or also those published to preview. The browsing mode is stored in the user's session so therefor the route handler needs to know the browsing mode to be able to solve the requested page.
So I really need the session already at that stage.
I have explained reason behind this problem in this answer. And now I have found a solution to the problem!
You create a custom HttpHandler class:
class MyHttpHandler : IHttpHandler, IRequiresSessionState
{
public MyRequestHandler RequestHandler;
public RequestContext Context;
public MyHttpHandler(MyRequestHandler routeHandler, RequestContext context)
{
RequestHandler = routeHandler;
Context = context;
}
public void ProcessRequest(HttpContext context)
{
throw new NotImplementedException();
}
public bool IsReusable
{
get { throw new NotImplementedException(); }
}
}
It is important to add IRequiresSessionState interface, otherwise IIS does not load session for this request. We do not need to implement logic of ProcessRequest and IsReusable, but class must implement the IHttpHandler interface.
You change your RouteHandler implementation:
public class MyRequestHandler : IRouteHandler
{
public IHttpHandler GetHttpHandler(RequestContext requestContext)
{
return new MyHttpHandler(this, requestContext);
}
public IHttpHandler DelayedGetHttpHandler(RequestContext requestContext)
{
// your custom routing logic comes here...
}
}
You simply move your original, Session dependent logic to DelayedGetHttpHandler function and in the GetHttphandler function you return an instance of the helping MyHttpHandler class.
Then, you hook your handling logic to the HttpApplication.PostAcquireRequestState event, e.g. in the Global.asax:
public class Global : HttpApplication
{
public override void Init()
{
base.Init();
PostAcquireRequestState += Global_PostAcquireRequestState;
}
}
For more reference, check this page: https://msdn.microsoft.com/en-us/library/bb470252(v=vs.140).aspx. It explains the request lifecycle and why I use the PostAcquireRequestState event.
In the event handler, you invoke your custom RouteHandling function:
void Global_PostAcquireRequestState(object sender, EventArgs e)
{
if (HttpContext.Current.Handler is MyHttpHandler) {
var handler = HttpContext.Current.Handler as MyHttpHandler;
HttpContext.Current.Handler = handler.RouteHandler.DelayedGetHttpHandler(handler.Context);
}
}
And that's it. Works for me.
I am not sure that you can do this (although I may be wrong). My recollection is that IRequiresSessionState indicates that an HttpHandler needs session state, rather than the route handler (which is responsible for giving you a handler appropriate to the route).
Do you really need the session in the route handler itself and not the handler it gives out?
Well I know this is old thread but just putting up the answer here if anyone like me falls in the same scenario, I found an answer here
What you do is just add a runAllManagedModulesForAllRequests="true" attribute to your modules tag in web.config like below
<system.webServer>
.....
<modules runAllManagedModulesForAllRequests="true">
........
</modules>
......
</system.webServer>
However this is not a good solution as it calls managed module everytime, i am using
<remove name="Session" />
<add name="Session" type="System.Web.SessionState.SessionStateModule"/>
add it in modules section of web.config, this a better solution than the previous one.
I am implementing a dynamic ASMX web service via a custom HttpHandler, and my web service has recently stopped generating WSDL automatically. When I use ?WSDL on the asmx url, I get the following error:
System.InvalidOperationException: XML Web service description was not found.
at System.Web.Services.Protocols.DiscoveryServerProtocol.WriteReturns(Object[] returnValues, Stream outputStream)
at System.Web.Services.Protocols.WebServiceHandler.WriteReturns(Object[] returnValues)
at System.Web.Services.Protocols.WebServiceHandler.Invoke()
This worked fine a while ago, so I'm wondering if there's a file permission problem somewhere.
A Google search does not return any reference to this particular situation.
I doubt that my code is relevant to the problem; it has not changed:
[WebService(Description = "...", Namespace = "...")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[ToolboxItem(false)]
public class MyWebService : System.Web.Services.WebService
{
[WebMethod]
void MyWebMethod() {}
}
public class VirtualWebServiceFactory : IHttpHandlerFactory
{
public IHttpHandler GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
WebServiceHandlerFactory wshf = new WebServiceHandlerFactory();
MethodInfo coreGetHandler = wshf.GetType().GetMethod("CoreGetHandler", BindingFlags.NonPublic | BindingFlags.Instance);
IHttpHandler handler = (IHttpHandler)coreGetHandler.Invoke(wshf, new object[] { typeof(MyWebService), context, context.Request, context.Response });
return handler;
}
}
Decompiling System.Web.Services.Protocols.DiscoveryServerProtocol.WriteReturns() reveals that it looks up the XML service description in a dictionary created somewhere else.
I was hoping that someone familiar with the DiscoverServerProtocol etc. might know under what circumstances the XML service description might fail to be built.
The following works just fine:
ServiceDescriptionReflector reflector = new ServiceDescriptionReflector();
reflector.Reflect(typeof(MyWebService), "...");
Navigating to MyWebService.asmx shows all the functions and allows testing them. But using ?WSDL gives the exception above.
Just for fun, try making your WebMethod public.
However, the real answer is to not screw around with .NET Framework code that's not meant to be called. What's wrong with just calling GetHandler? What are you trying to accomplish here that can't be accomplished without messing around in the internals of an obscure class?
Hmm, after many months, found out that the URL was being re-written to include other parameters than the ?WSDL, which made the private function choke.