O componente JS do lado do cliente do Orbited (um servidor Comet) requer que se o servidor estiver sendo executado em um domínio ou porta diferente do próprio JS, você deve executar
document.domain = document.domain;antes que qualquer outro JS seja carregado. (Veja a documentação .)
O que isso faz? Parece um NOOP! (Eu verifiquei e é de fato necessário.)
Respostas:
Na verdade, escrevi este código.
Ao tentar fazer cross-subdomain / port cometa, o iframe precisa ter o mesmo document.domainvalor que o quadro pai. Infelizmente, o navegador armazena o nome de domínio E a porta internamente para o document.domainvalor original . Mas o getter e o setter em javascript não sabem nada sobre a porta. Portanto, o problema é este: se o quadro superior document.domainé ('example.com', 80), e o quadro inferior é ('comet.example.com', 80), como você faz com que o quadro inferior ('example.com', 80)também seja?
Você não pode, pois alterar a parte do nome do host necessariamente fará com que a porta seja configurada como null, portanto, o melhor que você pode fazer é ('example.com', null)no quadro inferior. Portanto, o quadro superior também precisa ser definido com esse valor, e a configuração document.domain=document.domainfaz exatamente isso. Ele muda a representação interna no navegador de ('example.com', 80)para ('example.com', null)e, em seguida, tudo coincide e a comunicação de quadro de porta cruzada / subdomínio funciona.
Os navegadores distinguem entre (a) document.domain quando não definido explicitamente e (b) document.domain quando definido explicitamente ... mesmo se retornarem o mesmo valor.
Definir explicitamente o valor indica a intenção de "cooperar" com um script em outro subdomínio (no mesmo domínio pai).
Se AMBOS a página pai E o script externo definirem explicitamente document.domain com o mesmo valor, a restrição de política de mesma origem pode ser ignorada e cada script pode acessar todos os objetos e propriedades (de outra forma restritos) dos contextos uns dos outros.
Encontrei as seguintes informações neste site: devguru . Mais concretamente, aqui está a citação:
Esta propriedade define ou retorna o nome de domínio do servidor de onde o documento se originou. O padrão é o nome de domínio do servidor do qual o documento foi recuperado, mas pode ser alterado para um sufixo (e apenas um sufixo) desse nome. Isso permite o compartilhamento de propriedades de script, permitindo a segurança, entre documentos entregues por servidores diferentes, desde que compartilhem o mesmo sufixo de domínio.
Parece-me que permite cross site scripting para o mesmo domínio (mesmo se o subdomínio for diferente).
Suponho que, se você não tocar em document.domain, o mecanismo js só permitirá outros javascripts do mesmo domínio. Com essa propriedade, você será capaz de implantar em outros subdomínios, como o estado de documentos orbitados.
document.domain = document.domain é um NOOP.
O document.domainpuxa um padrão do URL real se não for definido explicitamente. Os navegadores registrarão se document.domainveio como padrão da URL ou se foi definido explicitamente. Ambos devem ser um padrão para o mesmo domínio ou ambos devem ser explicitamente configurados para o mesmo domínio para que isso funcione. Se um for o padrão e o outro for explicitamente definido, ambos correspondentes se lidos, as duas páginas ainda serão proibidas de se comunicarem.
Vejo: https://developer.mozilla.org/en-US/docs/DOM/document.domain