Add support for X-domain long-polling with JSONP about signalr

[gyf19]

[davidfowl]

Are we still doing this for 0.4?

[dsosunov]

+1

[dsosunov]

+1

[wpoch]

+1

[yvbeek]

+1

Don't really need JSONP solution.
<add name="Access-Control-Allow-Origin" solution in web.config is fine.

However the /signalr/hubs script should be more flexible, the url /signalr shouldn't be hardcoded

[davidfowl]

@Zyphrax you can change it via $.connection.hub.url there isn't a good default other than the relative path and that works for 90% of the cases

[stevozilik]

+1

[davidemanske]

+1

[davidfowl]

This was implemented as a contribution (Thanks @codeputty).

To make this work with Persistent connections:

var connection = $.connection('http://somecrossdomainurl/echo')

connection.start({ transport: 'longPolling', xdomain: true });

We may tweak the api (i.e try to autodetect so you don't need to specify longpolling) but this is the current implementation.

[stevozilik]

Thanks for this! Does this mean though that xdomain only works with long polling and no other transport protocol? If so, is it technically possible for it to work with other protocols?

[davidfowl]

This feature is specifically about long polling. Other protocols aren't supported. You can check out CORS for an alternative to jsonp longpolling:

http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing
http://stackoverflow.com/questions/9984534/signalr-cross-domain-connections

[yvbeek]

The CORS solution is working quite well. It becomes problematic when you have signalr on a subdomain, more than one subdomain using it and using cookies.

The specification says that you can specify multiple domains for Access-Control-Allow-Origin, but that doesn't seem to work when you have Access-Control-Allow-Credentials set to true (for cookie support).

My workaround is (in Global.asax.cs of my SignalR hubs MVC website):

/// <summary>
/// Raises when the application processes a request.
/// </summary>
protected void Application_BeginRequest(object sender, EventArgs e) {
    string origin = Request.Headers["Origin"];
    Uri uri;

    // Validate the Request origin
    if (Uri.TryCreate(origin, UriKind.Absolute, out uri) &&
        uri.Host.EndsWith(FormsAuthentication.CookieDomain)) {
        Response.AddHeader("Access-Control-Allow-Origin", uri.Scheme + "://" + uri.Authority);
        Response.AddHeader("Access-Control-Allow-Credentials", "true");
    }
}

Another nice resource for CORS:
http://enable-cors.org/

[yvbeek]

In AspNetHandler.cs I see that you've implemented it like this:

// https://developer.mozilla.org/En/HTTP_Access_Control
string origin = context.Request.Headers["Origin"];
if (!String.IsNullOrEmpty(origin))
{
        context.Response.AddHeader("Access-Control-Allow-Origin", origin);
        context.Response.AddHeader("Access-Control-Allow-Credentials", "true");
}

This seems quite insecure. Now all origins are allowed. If you have a look at my code above you see that I compare the origin against the cookie domain. Could you implement something similar?

EDIT - one extra thing to note:
It would be better to somehow overwrite the Access-Control-Allow-Origin, instead of using AddHeader. Now if you have the Access-Control-Allow-Origin defined in your web.config, you'll end up with both values being sent to the client. Which will fail in almost all browsers (I think only Firefox supports that).

[davidfowl]

Insecure? Websockets has the same behavior as this by default. Also any
other random non browser client can call your service so im not sure
what you're protecting.

Also socket.io does the same. We want the experience to be as similar
to websockets as possible. If you have valid security concerns or
concrete evidence that what we're doing is insecure then I'd love to
know.

Sent from my Windows Phone
From: Zyphrax
Sent: 7/25/2012 3:19 AM
To: David Fowler
Subject: Re: [SignalR] Add support for X-domain long-polling with JSONP
(#6)
In AspNetHandler.cs I see that you've implemented it like this:

// https://developer.mozilla.org/En/HTTP_Access_Control
string origin = context.Request.Headers["Origin"];
if (!String.IsNullOrEmpty(origin))
{
        context.Response.AddHeader("Access-Control-Allow-Origin", origin);
        context.Response.AddHeader("Access-Control-Allow-Credentials", "true");
}

This seems quite insecure. Now all origins are allowed. If you have a
look at my code above you see that I compare the origin against the
cookie domain. Could you implement something similar?

---

Reply to this email directly or view it on GitHub:
#6 (comment)