Вопросы Теги

Обратные прокси и Ajax

Любой достойный противоугонный должен быть интегрирован в ноутбуке, иначе это было бы к тяжелому и непрактичному для использования. Единственной противоугонной, интегрированной по умолчанию в ноутбуках, является блокировка Kensington. Существует еще некоторая усовершенствованная версия их, как, например, которые имеют предупреждение.

Некоторые бизнес-ноутбуки имеют удаленное шифрование диска, которое могло быть активировано в случае воровства. Но это для случая, где Вы волнуетесь по поводу физической безопасности данных, не самих аппаратных средств.

2
задан 13 April 2017 в 15:14
3 ответа

Много позже получения доступа к сайту нашего клиента (через WebSEAL) и создание тестового сценария, у нас есть ответ. Согласно документации IBM относительно Ajax и WebSEAL, в самом конце на разделе cookie Соединения существует абзац, который читает:

Потенциальное решение.

Если ответ от запроса Ajax не должен быть представлен как HTML, ответ не должен быть отправлен с типом контента "текста/HTML". Более соответствующий тип контента должен использоваться, например, "текст/плоскость". WebSEAL не добавляет код cookie соединения к ответам, которые не имеют типа контента "текста/HTML"

Для нашего приложения ASP.NET это было простое условие добавить в событие Page_Load, которое использовало управление. 

   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";

   }

Я уверен, что другие языки (PHP, JSP, RoR, и т.д.) у всех есть способы изменить тип контента. С точки зрения ASP.NET я не уверен, существует ли лучший метод события жизненного цикла, чтобы вставить это (PreInit?), но это - эффективное обходное решение для этого конкретного вопроса с Ajax и cookie соединения прокси реверса IBM WebSEAL.

3
ответ дан 3 December 2019 в 09:54

Это может зависеть от того, как Ваше приложение работает - если это использует абсолютный URIs в местах, и они указывают на что-то, что пользователи позади наклона прокси добираются до - который может быть Вашей проблемой.

Скажите, что у Вас есть прокси P, сервер S и пользователь. сервер имеет данное имя хоста (возможно больше), и один из тех, вероятно, связан с веб-сервером (позволяет, называют это server1). Пользователи могут или не мочь выполнять запросы непосредственно к server1. По всей вероятности, с обратным прокси, они должны выполнить запросы к прокси, и это в свою очередь запрашивает Ваш сервер.

Они видят http://P/YourAppHere - в то время как приложение на самом деле живет по http://server1/YourAppHere (или некоторый другой произвольный путь). Если Ваше приложение будет настроено таким способом как, чтобы сделать прямую ссылку на http://server1/YourAppHere/foo.asp, и прокси не берет на этом и изменяет код, который отправляется пользователю к тому, так, чтобы это направило к http://P/YourAppHere/foo.asp, то это повредит функциональность.

Своего рода нанесите удар в темноте здесь, но я столкнулся с подобной проблемой с Sharepoint.

1
ответ дан 3 December 2019 в 09:54
  • 1
    Да, пути URL, кажется, проблема, но я don' t знают, как пути URL создаются в стороннем управлении. Был бы, ступая посредством использования шоу Firebug проблема пути? –  osij2is 28 July 2009 в 23:25
  • 2
    если проблема состоит в том, поскольку я положил здесь, да. код был бы на клиентской машине в форме, которая перестанет работать, когда запрос будет выполнен. я даже не думаю, что Вам был бы нужен поджигатель, если Вы знаете/, что вероятные кандидаты на название сервера - просто ищут это. альтернативно, любой URI, который не запускается с http://P –  Devnull 28 July 2009 в 23:35
  • 3
    Спасибо за предложение. I' ll должны исследовать ту идею и видеть то, что я могу вскопать. –  osij2is 28 July 2009 в 23:51

С WebSEAL и другими обратными Прокси Ваш лучший выбор состоит в том, чтобы только использовать относительные URL. Самая большая проблема с Ajax и другими методами кодирования web 2.0 - то, что они отвечают передающей информации взаимностью клиенту для клиента для создания абсолютной стороны клиента URL. Нет никакого пути к Обратному прокси для фильтрации этого в случае необходимости. например, возврат имеет форму backendserver.com8443https

URL = протокол + "://"+host+port + "/somebackendURL/item.html"

Абсолютные URL фильтрованы, если и только если это проходит Обратный прокси как

https://бэкенд server.com:8443/и это соответствуют junctioned серверу.

Cookie соединения создают большое количество проблем, даже если Вы не кодируете как это.

Если у Вас есть страница HTML с вызовом в .js файл в теге script затем, если .js файл добавил cookie к нему, Вы получаете вложенные теги script, и браузер блюет.

например, test.html привет

Затем это - 2 запроса к WebSEAL. Если они проходят перекресток с настройками куки соединения, заключительная страница смотрит что-то как.

cookie набора IV_JCT=junctionname

> привет

1
ответ дан 3 December 2019 в 09:54

Теги

Похожие вопросы