Comment 90 for bug 44062

(In reply to comment #83)
> There would not be any workaround for that. The only way would be to use the
> same domain "www.google.com" for every part of the site - which is not always
> practical (ex. when the separate domains point to servers in different physical
> locations.)

I think usage of one domain per company is always better just because there is no need to buy multiple SSL certificates.

If they need authorization for others servers, why just not to enter password on each server? And I see workaround: they could make an iframe, in which they can do POST's with form.submit() to each server (servers view referrers to determine should they authorize request or not).

> I personally think a much better solution is either at the HTTP header level
> or, even better, the DNS level. Some provision in DNS to communicate
> permissions seems most logical, e.g. in a TXT record. This would be accessible
> before the request is sent, cache-able, and reasonably efficient.

Just remember that DNS is untrusted. DNS cache server owner can modify any record. And communication between client and DNS is not secure. It meens that we can't use it for SSL.

But about HTTP headers: there is a workaround you could add "; issued=https://www.bank.com/" parameter for cookies so server could check whether should it accept or not.

But I think it is incorrect solution to the problem because most web-programmers will not know that they should check additional cookie parameters. Just as now they don't know what is Cross-site request forgery (XSRF). It is easier to make companies like Google rewrite their webapps so they could work using one domain (or post to other domains inside an iframe) than to make people rewrite _all_ web sites and intranet portals to make them secure.