Last post Jun 30, 2013 07:13 AM by Tyree_Jackson
Jun 29, 2013 01:55 PM|Tyree_Jackson|LINK
I'm hoping that someone could provide some insight as to how I can integrate SignalR with a custom application framework that we are using at my company. This is a two part question but the parts are related.
I've got a framework that has a custom authentication layer which is currently configured to use the Digest Access Authentication scheme for authenticating users. The code is implemented within a core HttpHandler which performs routing to services based
on the request url. The authentication occurs as part of the calls performed in the ProcessRequest method of the HttpHandler. The code generates an immutable token (immutable outside of the core http handler) that is created upon authentication and updated
on every request (it contains a nonce to prevent replay, and random component to cycle the encryption and a sliding timeout).
My situation is, I'm needing to route the incoming request for a persistent connection through this HttpHandler so that it can perform it's security functions, otherwise the connection is considered unauthenticated. Is there a virtual method in the SignalR
request pipeline that I can override to enable this functionality preferrably through implementing an intermediate base class derived from PersistentConnection which we could call ServicePersistentConnection. I would like to use a PersistentConnection derivative
base class so that I can add a MyUserToken property to it containing the immutable token generated by this framework's core HttpHandler.
The second part is related to the first. Services in this framework are derivatives of a class with the signature "public class Service<tService> where tService : Service<tService>". I'm wanting to nest this ServicePersistentConnection class within the
Service<tService> class so that each of the derivatives would have its own persistent connection class. I would then like to route requests to some url like DerivedService/__liveConnection where DerivedService routes to an instance of a subclass of Service<tService>
and __liveConnection routes to an instance of it's ServicePersistentConnection.
In otherwords, I'm wanting to leverage the custom routing already provided by this framework to dynamically create new persistent connection end points. How would I go about constructing the persistent connection and routing the HttpContext that I already
have access to, to the PersistentConnection? The thing that seems to be throwing me off is the deep integration with OWIN. Do I need to implement an OWIN host layer of some sort in order to work with SignalR especially given that this framework already handles
routing without the use of asp.net mvc routing? Would I have to host SignalR itself on top of such a layer?
I would very much like to use SignalR for this project. But after a week of looking at this issue in my spare time, I'm considering using Fleck instead.
Thanks in advanced.
Jun 30, 2013 04:24 AM|davidfowl|LINK
So to summarize, you want to host SignalR yourself. Before going into details about signalr hosting, you could move your auth logic to an HttpModule so that it runs of all requests. SignalR is an OWIN framework, which means you need an owin host to run it.
There's an OwinHttpRouteHandler and an
OwinHttpHandler that you can use to bootstrap an owin framework (including SignalR). If you can find a way to take advantage of those components it would be better.
If you want to look at a full blown owin host you can look at our in memory host https://github.com/SignalR/SignalR/tree/master/src/Microsoft.AspNet.SignalR.Hosting.Memory.
That should be enough to get started.
Jun 30, 2013 06:24 AM|Tyree_Jackson|LINK
Jun 30, 2013 06:33 AM|davidfowl|LINK
You don't have to lose an context by moving to a module, you can store per request lifetime state in HttpContext.Items and it will flow. SignalR since version 1.0 has been OWIN based. It may sound complicated but
OWIN is just an IDictionary<string, object> with known keys for an http request/response. Here's what our server side logic looks like:
Jun 30, 2013 07:13 AM|Tyree_Jackson|LINK