Proxies reversos e AJAX

Question

Um cliente nosso está usando o IBM / Tivoli WebSEAL, um servidor proxy reverso para alguns de seus usuários internos. Nosso aplicativo da web (asp.net 2.0) e é um aplicativo web / banco de dados bastante simples.

Atualmente, nossos usuários clientes que estão passando pelo proxy do WebSEAL estão tendo problemas com o controle de terceiros do .NET. Os usuários que não estão passando pelo proxy não têm problemas. O controle de terceiros nada mais é do que uma árvore dinâmica AJAX que, em cada clique, solicita todos os nós para cada folha.

Agora, nossos clientes afirmam que, uma vez que os usuários clicam em um nó no controle, o próprio controle congela de tal forma que eles não vêem nada sendo preenchido. Os usuários veem a mensagem "Carregando ...", mas não há novas atividades. Eles precisam sair da página e voltar para a página original para visualizar os novos nós.

Eu nunca trabalhei com um proxy reverso antes, então eu pesquisei um pouco sobre o assunto até mesmo encontrei um artigo no SF. IBM / Tivoli mencionou este problema antes, mas isso é tudo o que eles mencionam em todos. Embora o documento da IBM seja muito útil, todo nosso AJAX é do controle de terceiros. Eu tentei solucionar problemas usando o Firebug, mas por não estar por trás do proxy reverso, não consigo replicar o problema.

Minha pergunta é: alguém tem experiência com proxies reversos e problemas com sites AJAX? Como posso provar qual é o problema exato? Atualmente, estamos negociando o acesso remoto, portanto, suponha que, na maior parte, eu tenha acesso a uma máquina que esteja usando o proxy do WebSEAL.

P.S. Eu percebo que essa pergunta pode balançar no debate sobre a jurisdição StackOverFlow / ServerFault, mas estou tentando investigar a partir da perspectiva dos sistemas. Não tenho experiência com proxies reversos (e não estou claro sobre os benefícios) e pouco com proxies de encaminhamento.

    

Answer 1

Depois de obter acesso ao site de nosso cliente (por meio do WebSEAL) e criar um caso de teste, temos uma resposta. De acordo com a documentação da IBM sobre AJAX e WebSEAL , no muito final na seção de cookies Junction há um parágrafo que diz:

Potential solution.

If the response from an AJAX request is not to be rendered as HTML, the response should not be sent with a content type of "text/html". A more appropriate content type should be used, for example, "text/plain". WebSEAL does not add the junction cookie code to responses that do not have a content type of "text/html"

Para nosso aplicativo ASP.NET, era uma condição simples para adicionar ao evento Page_Load que usava o controle.

   protected void Page_Load(object sender, EventArgs e)
   {

     Response.Clear();

     Response.ContentType = (Page.IsCallback) ? "text/plain" : "text/html";

     //does same thing as line above
     //if (Page.IsCallback)
     //   Response.ContentType = "text/plain";
     //else
     //   Response.ContentType = "text/html";

   }

Tenho certeza de que outras linguagens (PHP, JSP, RoR, etc.) possuem maneiras de alterar o tipo de conteúdo. Em termos de ASP.NET, não tenho certeza se há um método de evento de ciclo de vida melhor para colocar isso em (PreInit?), Mas essa é uma solução eficaz para esse problema específico com cookies de junção de proxy reverso AJAX e IBM WebSEAL.

    

Answer 2

Pode depender de como seu aplicativo funciona - se ele usa URIs absolutos em locais, e esses apontam para algo que os usuários por trás do proxy não conseguem acessar - esse pode ser o seu problema.

Digamos que você tenha o proxy P, o servidor S e o usuário. o servidor tem um determinado nome de host (possivelmente mais) e um deles provavelmente está associado ao servidor web (vamos chamá-lo server1). Os usuários podem ou não conseguir fazer solicitações diretamente ao servidor1. Com toda a probabilidade, com um proxy reverso, eles precisam fazer solicitações ao proxy, e isso, por sua vez, consulta o seu servidor.

Eles vêem o link - enquanto o aplicativo realmente mora no link (ou algum outro caminho arbitrário). Se o seu aplicativo estiver configurado de modo a fazer referência direta ao link , o proxy não atenderá e modificará o código que é enviado ao usuário para que direcione para link , ele irá quebrar a funcionalidade.

Meio que uma facada no escuro aqui, mas me deparei com um problema semelhante com o Sharepoint.

    

Answer 3

Com o WebSEAL e outros proxies reversos, sua melhor aposta é usar apenas URLs relativas. O maior problema com o AJAX e outros métodos de codificação da Web 2.0 é que eles adoram enviar informações de volta ao cliente para o cliente criar o lado absoluto do cliente de URLs. Não há como o proxy reverso filtrar isso, se necessário. por exemplo.    retorno é da forma    backendserver.com8443https

URL = protocolo + ": //" + host + porta + "/somebackendURL/item.html"

URLs absolutas são filtradas se e somente se passarem pelo proxy reverso como

link e isso corresponde a um servidor com junção.

Os cookies de junção criam um grande número de problemas, mesmo se você não estiver codificando assim.

Se você tiver uma página html com uma chamada para um arquivo .js dentro de uma tag de script, se o arquivo .js tiver o cookie adicionado, você receberá tags de script aninhadas e as barfs do navegador.

por exemplo. test.html é Olá

Em seguida, são 2 solicitações para o WebSEAL. Se eles passarem por um cruzamento com os cookies de junção definidos A última página parece algo como.

        set cookie IV_JCT = nome da junção      

> Olá