Я хочу перенаправить https://sub.domain.com к https://sub.otherdomain.com без изменения адресной строки пользователя.
Возможно ли это даже технически? Я могу представить какие-то проблемы с сертификатом?
Кстати, мы используем Apache на Linux.
Спасибо!
-
Некоторая справочная информация;
Мы запускаем веб-приложение, которое реселлеры могут предложить своим клиентам, желательно «расположенное» на их собственном доменном имени, но размещенное у нас. Поэтому, когда клиенты переходят на app.reseller.com, они фактически используют app.ourcompany.com. Это сделано для того, чтобы минимизировать риск утечки кода и полностью контролировать выполнение обновлений и исправлений.
Если вы не хотите изменять адресную строку, вам либо нужно использовать фрейм HTML, либо вам нужно настроить свой сервер в качестве прокси. Так что запросы, которые достигают https://sub.domain.com проксируются на https://sub.otherdomain.com
Вы не можете выполнить перенаправление HTTP без изменения адресной строки.
Существует небольшая вероятность, что вы можете заставить что-то работать, но вам придется начать с сертификата с подстановочным знаком, который поддерживает оба доменных имени.
Один из способов сделать это - иметь прокси-сервер Apache, который обслуживает групповой сертификат с несколькими соединителями и использует мод-прокси. В этой конфигурации клиент может переключаться между доменами и не сталкиваться с ошибкой «проверить этот сертификат».
Затем передний прокси-сервер будет интеллектуально пересылать запросы на внутренний HTTP-сервер (например, экземпляр tomcat), используя mod-proxy, mod-ajp и / или mod-rewrite, где внутренний сервер работает на отдельный порт для каждого сайта сервера. Ваши правила перезаписи мода могут обрабатывать все детали выбора способа маршрутизации.
1) У вас может быть точка DNS sub.domain.com на IP-адрес / сервер, которым вы управляете. Тогда у вас будет установлен сертификат ssl для sub.domain.com. 2) Если вы ограничены IP-адресами, вы можете получить Многодоменные сертификаты. Go Daddy ограничивает вас 99 доменами, и это может быть сложной перетасовкой для каждого добавляемого домена. 3) Вы также можете сделать так, чтобы клиент получил сертификат ssl и должен действовать как прокси, подключающийся к вашему сайту.
Исправление вашего приложения для использования window.history.pushstate.
У ваших клиентов есть веб-сервер в app.clientdomain.tld, который обслуживает iframe вашего сайта.
Надеюсь, что пользователи вашего клиента используют совместимые браузеры (и у них включен javascript).
Тем не менее, первая идея Кристофера Эванса (перенаправление на уровне DNS) лучше всего, если вы можете. (Используйте CNAME, чтобы ваши клиенты могли запустить и забыть.) Однако, поскольку ни один объект не должен иметь возможность получать действительный сертификат для другого, многодоменные сертификаты не помогут, если у одного клиента не более одного домена. Ваши клиенты должны будут создать действительные сертификаты и передать вам сертификаты и связанные ключи. (Ключи должны передаваться надежно.)
Или вы могли бы подождать http://www.ietf.org/rfc/rfc2817.txt (Не надо! Это правда, но бесполезно).
Редактировать:
Вариант, который не требует затрат на IP-адреса (по крайней мере, пока у вас не закончатся легкодоступные порты), заключается в том, чтобы ваш веб-сервер обслуживал каждый сертификат клиента на альтернативном порту, а не на альтернативном IP-адресе. например ссылка клиентов https: //app.client.tld: 7703 /
Вам все равно придется заняться DNS.