SSL и аутентификация через несколько доменов
Я создаю приложение с Ruby on Rails, который позволяет пользователям подписываться и создавать свой собственный субдомен:
joebloggs.myapp.com
Так по крайней мере мне нужен подстановочный сертификат SSL для обработки, когда пользователи передают уязвимые данные (аутентификация, оплата и т.д.).
Кроме того, мы позволяем пользователям, которые хотят, отобразить их собственный домен на их учетную запись, как:
www.joebloggs.com
Который внезапно создает обширную головную боль. Я предполагаю, что никакой продукт SSL не существует, чтобы служить этой цели (т.е., потенциально использоваться по неограниченным доменам)?
Приложением является по существу CMS, таким образом, оно имеет общедоступный веб-сайт и администраторский бэкэнд. Важно, чтобы общедоступная сторона веб-сайта вещей имела средство, которое будет отображено на домене пользователя. Однако я менее обеспокоен администраторской областью и вполне счастливо вынудил бы пользователей войти в систему и администрировать свой сайт через их субдомен.
Однако, пока для большинства веб-сайта действительно не имеет значения, зарегистрирован ли пользователь или нет, я ДЕЙСТВИТЕЛЬНО хочу смочь знать, зарегистрирован ли пользователь так, я могу подать немного отличающееся содержание к, вошел в систему пользователи. Я предполагаю, что это собирается вызвать меня проблема, потому что cookie не может использоваться по нескольким доменам (или может он?). Я использую Authlogic для аутентификации.
Таким образом, действительно я просто задаюсь вопросом, столкнулся ли кто-либо с такой ситуацией прежде? Если так, какой подход Вы проявили для обхода нескольких проблем здесь?
1 ответ
Возможно, это не решение ваших проблем. Но на ваш вопрос не было ответа 6 часов, поэтому я решил предложить пару альтернативных идей. Возможно, это подтолкнет других читателей к творчеству. :)
Они отсортированы в том порядке, в котором я лично считаю их удобными.
Всегда имейте поддомен, даже если у пользователя есть собственный
Следуя вашему примеру, вы можете обслуживать исключительно статические страницы на www.joebloggs.com со ссылками для входа, которые ведут на joebloggs.myapp.com . Если пользователь уже вошел в систему, фактический шаг входа в систему можно пропустить, поскольку в этом случае файлы cookie становятся доступными.
Это потребует, чтобы все пользователи имели поддомен, даже если они указали свой собственный домен.
Обслуживайте статические страницы и используйте межсайтовый AJAX.
Существует относительно новый проект стандарта под названием Cross-Origin Resource Sharing , который разрешает запросы AJAX между доменами. Firefox поддерживает его начиная с версии 3.5, и есть несколько более читаемых (чем спецификация W3) примеров того, как это работает на практике, в Mozilla Developer Center .
Помимо Firefox 3.5, это, похоже, поддерживается в IE 8. Это в более новых версиях Chrome и Safari, но я не могу точно определить, с какой версии. (Набор изменений Webkit # 41046.) Я не могу найти ничего окончательного об Opera.
Также обратите внимание, что запросы, не связанные с GET, имеют дополнительные накладные расходы по сравнению с «предполетным» запросом.
Обслуживайте динамические части с помощью iframe
Iframe можно хорошо скрыть с помощью некоторого CSS и заставить плавно отображаться на странице. Вы можете обслуживать динамические части своей страницы, используя фреймы, указывающие на myapp.com . Это будет работать достаточно хорошо, если динамическая часть представляет собой просто часть заголовка страницы с некоторой информацией об учетной записи и, например, ссылками.
Если вы планируете скрывать контент на основе привилегий пользователя, вы можете пойти дальше и использовать всю область контента страницы как iframe.
Обратной стороной является то, что некоторые браузеры могут жаловаться на смешанный простой и защищенный контент.
Классический трюк «прятаться за невидимым фреймом»
На многих сайтах, которые раньше размещались на таких платформах, как Geocities, были бесплатные домены .tk , которые «скрывают» сайт за красивым URL-адресом в адресной строке. Хитрость заключалась в том, что .tk обслуживает набор фреймов с невидимым фреймом и другой фрейм, покрывающий все окно, которое будет обслуживать сайт Geocities.
Это некрасиво , конечно, но я должен был упомянуть об этом. Это означает, что адресная строка не будет обновляться навигацией по ссылкам на вашем сайте и всегда будет отображать корневой URL. Также игнорируются многие возможные преимущества наличия отдельного домена. И у него даже может быть тот же недостаток, что и у предыдущего трюка с фреймами.