Использование Datazen в iframe с внешней аутентификацией

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

Внешняя аутентификация в Datazen выглядит примерно так:

User-Agent         |  Proxy               |  Server
-------------------|----------------------|------------------------------------
1. /viewer/home   --> 2.  Append header  --> 3.  Check cookie (not present)
                  <-- 5.  Forward        <-- 4.  Redirect to /viewer/login

6. /viewer/login  --> 7.  Append header  --> 8.  Append cookie
                  <-- 10. Forward        <-- 9.  Redirect to /viewer/home

11. /viewer/home  --> 12. Append header  --> 13. Check cookie (valid)
                  <-- 15. Forward        <-- 14. Give content

16. .................. Whatever the user wanted ..........................

Таким образом, даже если вы работаете с прокси-сервером с заголовком, вы все равно получаете файл cookie, который он использует.

Это просто контекст.

Мое предположение, исходя из вашего описания симптомов, состоит в том, что myHttpWebResponse должен иметь набор файлов cookie (я полагаю, DATAZEN_AUTH_TOKEN), но по сути он выбрасывается - вы нигде его не используете.

Вам нужно будет указать клиенту вашего браузера добавлять этот файл cookie к любым последующим (на основе iframe) запросам к домену вашего сервера Datazen, но я не верю, что это возможно из-за ограничений безопасности. Однако я не очень много знаю о CORS, поэтому может быть способ разрешить это.

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

По сути, если вы хотите встроить Datazen в iframe, я бы отказался от внешней аутентификации. Я бы уклонился от этого в любом случае, но особенно там.

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

Единственный способ, которым я могу думать, чтобы заставить эту работу работать, - это поместить все в один и тот же домен:

• www.example.com
• datazen.example.com (вероятно, это ваш прокси)

Затем вы можете установить файл cookie из своего ответа, который хранит некоторую зашифрованную (и, вероятно, истекающую) форму Session("Email") и передает ее обратно в ваш html.

Это делает ваш iframe относительно простым, потому что вы можете просто сказать ему загрузить программу просмотра домой. Кое-что по эффекту:

<iframe src="//datazen.example.com/viewer/home"></iframe>

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

Это может быть упрощено в паре мест, но это должно максимально соответствовать вашей исходной реализации, если вы можете возиться с настройками DNS.

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

Итак, если у вас было что-то вроде:

var emailEncrypted = encrypt(Session("Email") + ":somesalt:" + DateTime.UtcNow.ToString("O"));

Затем используйте любой язык шаблонов, который вы хотите настроить для своего iframe:

<iframe src="//{{ customDomain }}/viewer/home?emailkey={{ emailEncrypted }}"></iframe>

Затем ваш прокси обнаружил этот параметр emailkey, расшифровал его и проверил срок действия, что может сработать.

Теперь у вас будет выбор, как поступить с этим, потому что Datazen даст вам 302 на /viewer/login, чтобы получить файл cookie, и вам нужно убедиться, что вы передаете правильный emailkey через него.

1. Что бы я сделал, вы могли бы принять этот параметр emailkey в своем прокси, установить совершенно новый файл cookie самостоятельно, а затем следить за этим файлом cookie при последующих запросах.

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

   Но вам не пришлось бы. Если вы не хотите это менять, вы можете просто проверить файл cookie и превратить его в заголовок.

2. Вы должны сделать (1), но на всякий случай я не уверен в одном: можете ли вы передавать пользователей напрямую в /viewer/login, чтобы получить файл cookie от Datazen. Обычно вы бы этого не сделали, но, похоже, вы должны быть в состоянии.

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

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

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

document.domain ='basedomain.com';

в javascript на обоих сайтах, чтобы получить доступ к содержимому iframe, иначе вы столкнетесь с междоменными проблемами.