(now obsolete) FX vs IE --> cross domain scripting with same host and different ports

Dario Crivelli

In the usual deployment scenario, Lightstreamer Server and the Web Server are deployed on different hosts
(or, at least, they are accessed by the clients through different hostnames, as push.mycompany.comand www.mycompany.com )
and the pages coming from the two servers can interoperate thanks to the domain setting, which can refer to a common superdomain (as mycompany.com).

Let's suppose, on the other hand, that Lightstreamer Server and the Web Server are deployed on the same host, listening on different ports,
(or, at least, that they are accessed by the clients through the same hostname, as www.mycompany.com).
Note that this is not recommended as a production configuration, because only port 80 (or 443 for https) is ensured to be reached by any client browser.
Nevertheless, the pages from the two servers can still interoperate thanks to the domain setting, provided that you can enlarge it to be a superdomain (as mycompany.com).

In some test environments, you may only have a hostname that doesn't allow a legal superdomain (as localhost) and you may wish to try to have your page still interoperate.
This is possible, but strongly browser dependent.
Sticking to the most common cases:

On Internet Explorer, the domain should be left at its default; in terms of Lightstreamer javascript APIs, you can also issue setDomain(null)
On Firefox, the domain should be explicitly set to be the same as the hostname (as in setDomain("localhost")).

Because of this browser-dependent behavior, the recommended way of testing when Lightstreamer Server and the Web Server are on the same host and no suitable hostname is available is to assign fake hostnames of the correct format directly on the client machine, by playing on the "hosts" file.

Another consequence is that you can't use hostnames like mycompany.comfor the Web Server and push.mycompany.com for Lightstreamer Server, because using mycompany.com as the common superdomain is not supported by all browsers. Hence, this case is officially not supported by the Web client APIs.

nicknack

can you be more explicit about what the solution is please?
I'm running both servers on one host. I've specified the hostname/ip in the hosts file. IE allows the connection to Lightstreamer, but Firefox won't. You appear to offer a solution but it isn't clear what it is. What is the 'domain setting' for example?

Dario Crivelli

Sorry, I could have made a more explicit mentioning of the javascript document.domain property.
Hence, the "domain setting" is a javascript feature and setting the domain to a value, like "lightstreamer.com", means issuing

document.domain = "lightstreamer.com";

According to the previous post, in order to have Lightstreamer working on Firefox in your scenario,
both your Push-page and Lightstreamer-generated data page should, in principle, issue:

document.domain = myHostname;

where myHostname is the name with which you access both the Web Server and Lightstreamer Server.

But note that you have no control on Lightstreamer-generated data page.
You can achieve all the above by using the setDomain method from Lightstreamer API, i.e. issuing:

pushPage.context.setDomain(myHostname);

which both sets the domain on the local Push-page and makes the LS Server do the same on its generated data page.

Dario Crivelli

I have wholly revised the first post, because some key points were wrong or missing.

nicknack

@DarioCrivelli, Wrote:
Because of this browser-dependent behavior, the recommended way of testing when Lightstreamer Server and the Web Server are on the same host and no suitable hostname is available is to assign fake hostnames of the correct format directly on the client machine, by playing on the "hosts" file.

Another consequence is that you can't use hostnames like mycompany.comfor the Web Server and push.mycompany.com for Lightstreamer Server, because using mycompany.comas the common superdomain is not supported by all browsers. Hence, this case is officially not supported by the Web client APIs.

Thanks for making this clearer, however I'm still unclear on a few things:
1)what do you mean about the superdomain not supported by all browsers? Earlier you say this is the way to do it in production then you end by saying it isn't the way to do it.
2)In your second post you refer to the Lightstreamer API. Are you referring to the javascript API? Please can you be clear about this as it is very confusing.
3)should I be checking the browser name and setting pushPage.context.setDomain(null) for IE and pushPage.context.setDomain(domain) in firefox?
thanks in advance

Mone

1)what do you mean about the superdomain not supported by all browsers? Earlier you say this is the way to do it in production then you end by saying it isn't the way to do it.

Not supported are cases where one of the two hostnames is equal to the superdomain.
So, if you use
push.mydomain.com as host for your Lightstreamer server
and
mydomain.com as host for your webserver
this is not supported.

Bu if you use
push.mydomain.com as host for your Lightstreamer server
and
www.mydomain.com as host for your webserver
than that's ok [and you'll use setDomain("mydomain.com")].

2)In your second post you refer to the Lightstreamer API. Are you referring to the javascript API? Please can you be clear about this as it is very confusing.

We refer to Lightstreamer javascript API (this forum section is about javascript API).
Other APIs have different (Flex, Silverlight) or no restrictions about host names.

3)should I be checking the browser name and setting pushPage.context.setDomain(null) for IE and pushPage.context.setDomain(domain) in firefox?

only if you are in the situation highlighted by the first post and you don't want/you can't apply the hosts-file-workaround proposed.

Note that in a production environment you should use two different hostnames for your webserver and your lightstreamer server so that this thread will not apply.