2011-04-08 3 views
8

Каковы потенциальные решения проблемы перенаправления, возникающие при попытке сделать вызовы AJAX защищенному CAS, зашифрованным SSL-ресурсом, расположенным на сервере, отличном от сервера CAS?Как преодолеть междоменные проблемы для Ajax-вызовов для CAS-защищенных ресурсов?

Сервер CAS используется для аутентификации и ведет себя так, как было разработано. Эта проблема, по-видимому, специфична для ajax.

Существует аналогичный вопрос here, но мы не можем использовать тот же домен/сервер/порт для сервера CAS и ресурсного ресурса.

В списках рассылки JASIG CAS упоминается использование JSESSIONID.

Другим возможным подходом является изменение фильтра CAS, чтобы изменить поведение по умолчанию с истекшим билетом на нечто более надежное.

Какой шаблон дизайна вы бы использовали для преодоления этой проблемы?

ответ

0

Я никогда не слышал о CAS, но в целом: Javascript имеет какое-то ограничение, называемое «той же политикой происхождения». Видимый ressource также не отображается автоматически для Javascript. Вы пытались получить доступ к ressource, используя обратный прокси, чтобы сделать его доступным в том же домене? Вы также можете подумать о том, чтобы указать свой домен на отдельный веб-сервер и включить оба сервера в качестве обратных прокси (для Tomacat, JKmounts предпочтительнее) здесь.

1

Я 2 предложения:

  • вы можете настроить прокси-скрипт на том же домене как тот, который содержит код JS? Таким образом, прокси-скрипт будет запрашивать CAS и возвращать желаемые результаты.
  • вы можете включить JSONP? этот тип запроса не ограничивается политикой безопасности (но тогда любой может использовать эту услугу)
+0

+1 но для меня в этом случае возможен только прокси-скрипт. –