<div id="toc_container" role="navigation" aria-label="Table of Contents" data-nosnippet class="toc_white no_bullets toc_numbered toc_title_center">Sumário<ul class="toc_list"><ul><li><ul><li><a href="#ATENCAO-O-conteudo-apresentado-a-seguir-e-estritamente-tecnico-Nao-existem-estudos-sobre-os-danos-que-sua-leitura-pode-causar-aos-nao-programadores-No-entanto-ha-fortes-indicios-para-crermos-que-ela-faca-muito-bem-aos-entusiastas-de-aplicacoes-NET-Web">0.0.1. ATENÇÃO: O conteúdo apresentado a seguir é estritamente técnico. Não existem estudos sobre os danos que sua leitura pode causar aos não-programadores. No entanto, há fortes indícios para crermos que ela faça muito bem aos entusiastas de aplicações NET Web.</a></li></ul></li></ul></li><li><a href="#E-ai-comeca-o-problema8230">1. E aí começa o problema&#8230;</a></li><li><a href="#eu-compro-outro-computador-pro-meu-tio-mala-ou-quebro-a-cabeca-mais-um-pouco">2. eu compro outro computador pro meu tio mala ou quebro a cabeça mais um pouco?</a><ul><li><ul><li><ul><li><a href="#Por-Matheus-Araujo-e-Jessica-Saliba">2.0.0.1. Por: Matheus Araújo e Jéssica Saliba.</a></li></ul></li></ul></li></ul></li></ul></div>
<h4 style="text-align: justify;"><span id="ATENCAO-O-conteudo-apresentado-a-seguir-e-estritamente-tecnico-Nao-existem-estudos-sobre-os-danos-que-sua-leitura-pode-causar-aos-nao-programadores-No-entanto-ha-fortes-indicios-para-crermos-que-ela-faca-muito-bem-aos-entusiastas-de-aplicacoes-NET-Web">ATENÇÃO: O conteúdo apresentado a seguir é estritamente técnico. Não existem estudos sobre os danos que sua leitura pode causar aos não-programadores. No entanto, há fortes indícios para crermos que ela faça muito bem aos entusiastas de aplicações NET Web.</h4>
Quando analisamos o atual contexto do desenvolvimento Web, é bastante comum perceber que os sistemas estão distribuídos entre aplicações diferentes. Da mesma forma, estas aplicações também acabam alocando-se em servidores de domínios diversos.
Em um de nossos projetos, trabalhamos em um sistema legado que era distribuído entre duas aplicações diferentes, em servidores diferentes. De um lado havia um site SharePoint. Do outro, uma aplicação MVC padrão. Nosso desafio era criar a funcionalidade de usuário no sistema e mantê-lo logado ao mesmo tempo nas duas aplicações.
Para aplicações .NET, as informações de sessão do usuário ficam armazenadas nos servidores. No cliente (browser) é armazenado apenas o identificador da sessão (SessionID) em Cookie. [1]
<h2>E aí começa o problema&#8230;</h2>
A cada requisição que o cliente faz para o servidor, é necessário enviar o SessionID utilizado.
Nas requisições onde a página web está no mesmo domínio do servidor, essa informação é enviada normalmente, sem problemas. Você é feliz e nem percebe o que está acontecendo por trás disso tudo.
Para o cenário do nosso caso, em que o sistema está distribuído em aplicações diferentes, em domínios diferentes (parte em <a href="http://sharepoint.acme.com">http://sharepoint.acme.com</a> e outra parte em <a href="http://mvc.acme.com">http://mvc.acme.com</a>) existe uma solução bastante conhecida: as Requisições HTTP Cross-site [2].
O CORS funciona sem complicações. Dá um pouco de trabalho implementar, mas você consegue viver bem com ele&#8230;  Até o momento em que seu tio chato com o mesmo computador há dez anos precisa acessar o sistema pelo Internet Explorer 8.
Ele vai até entrar no <a href="http://sharepoint.acme.com">http://sharepoint.acme.com</a>, depois ver uns botões que eram quadrados agora um pouco mais arredondados, mas vai ver. O chato é que quando ele tentar fazer qualquer coisa que precise do <a href="http://mvc.acme.com">http://mvc.acme.com</a>.~~TCHARAM~~ seu sistema simplesmente não faz nada. E não adianta olhar no Fiddler, a requisição simplesmente não é feita.
Para o IE8, existe o XDomainRequest, uma alternativa para o CORS. A requisição chega a ser enviada, no entanto os cookies não são enviados, fato que não soluciona nosso problema inicial de manter a sessão.
Com isso você pensa:
<h2 style="text-align: justify;">eu compro outro computador pro meu tio mala ou quebro a cabeça mais um pouco? </h2>
Bom, você é programador (ou, se chegou até aqui, entusiasta pelo menos), não tem dinheiro e gosta de se divertir com esse tipo de coisa. Então, vamos pensar mais um pouco.
O princípio do CORS é fazer a comunicação entre duas aplicações em domínios diferentes através de requisições HTTP. Então você se lembra daquele professor de filosofia do ensino médio que te ensinava a rever seus princípios e descarta requisições HTTP.
Bom, qual seria a próxima opção então? COM+, Socket, OLE ou Sinal de Fumaça? Nada disso, vamos pelo que a gente já sabe e domina: JavaScript.
Sim, JavaScript! A linguagem oferece um recurso de comunicação entre aplicações rodando em domínios diferentes, o postMessage [3].
E como resolver o problema da requisição então? Nas requisições comuns, você envia uma mensagem pro servidor, espera um tempo e ele responde. Quando ele responde você faz uma alguma coisa, representando por um mini-diagrama:
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/08/diagrama01.jpg"><img fetchpriority="high" decoding="async" class=" wp-image-187 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/08/diagrama01.jpg" alt="diagrama01" width="853" height="212" /></a>
Voltando ao nosso sistema. FuncaoA() e funcaoB() estão no domínio <a href="http://sharepoint.acme.com">http://sharepoint.acme.com</a>, e enviam e recebem respostas do servidor no mesmo domínio. Então sem problemas, caminho feliz.
Caso você precisasse fazer uma requisição para o <a href="http://mvc.acme.com">http://mvc.acme.com</a>, via postMessage, o caminho seria mais ou menos assim:
<a class="lightbox" href="https://dtidigital.com.br/wp-content/uploads/2015/08/diagrama02.jpg"><img decoding="async" class=" wp-image-188 aligncenter" src="https://dtidigital.com.br/wp-content/uploads/2015/08/diagrama02.jpg" alt="diagrama02" width="915" height="394" /></a>
&nbsp;
Parece confuso, mas não é esse absurdo (diga lá, alguns algoritmos de programação dinâmica são bem piores). O que acontece aqui é que existe uma camada de comunicação no JavaScript entre as aplicações nos domínios diferentes.
Então, em vez de um JavaScript fazer uma requisição direta pra um servidor em outro domínio, ele faz a requisição para um outro JavaScript no domínio do segundo. O segundo JavaScript se encarrega de comunicar com o servidor: quando o servidor responde, ele simplesmente repassa a resposta para o Javascript que o chamou.
Pronto! Agora seu tio do IE8 pode usar seu sistema feliz.
Se ainda ficar com alguma dúvida, existe um exemplo bem legal de implementação dessa ideia nesse link: [4]
[1] <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies">https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies</a>
[2] <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS">https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS</a>
[3] <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage">https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage</a>
[4] <a href="http://blog.teamtreehouse.com/cross-domain-messaging-with-postmessage">http://blog.teamtreehouse.com/cross-domain-messaging-with-postmessage</a>
Boa sorte!
<h5 style="text-align: justify;">Por: Matheus Araújo e Jéssica Saliba.</h5>

Compartilhando sessão entre aplicações NET Web em domínios diferentes

Desbloqueie o futuro do seu negócio

Mais conteúdos como esse

Travessa Dona Zilda, 125, sala 203, São Gonçalo – Pelotas, RS. CEP: 96075-166

14841 Dallas Parkway, 8th Floor Addison, TX 75254

R. Levindo Lopes, 357, 5º e 12º Andar – Savassi, Belo Horizonte MG, 30112-010