В настоящее время на веб-сайтах Azure не разрешены настраиваемые сертификаты SSL, но для домена * .azurewebsites.net включен SSL с подстановочными знаками. Мне нужна безопасная форма входа в мое веб-приложение, но без настраиваемого SSL, похоже, я SOL.
Есть ли какое-нибудь обходное решение для этого? Возможно ли каким-то образом иметь форму входа на https://mydomain.azurewebsites.net, которая создает аутентификацию с помощью форм билет, который затем будет работать на http://mydomain.com?
Пару месяцев назад у меня была точно такая же проблема, то есть приложение было создано на веб-сайтах Azure, должно было работать в пользовательском домене, отличном от *.azurewebsites.net, и должно было разрешить безопасный процесс входа в систему.
Обходной путь, который мы использовали, заключался в том, чтобы встроить iframe (с использованием безопасного протокола и .azurewebsites.net доменного имени, например, https://oursite.azurewebsites.net/login) в незащищенную страницу в личном домене (например, http://mysite.com/login). И весь процесс входа в систему был выполнен в iframe.
Есть одна вещь, о которой вам следует знать, а именно, многие клиенты проверяют, использовала ли страница, на которой они предоставляют свои учетные данные, безопасное соединение или нет. В нашем случае безопасный iframe на незащищенной странице вызывал множество жалоб клиентов. Обходной путь для этой проблемы заключался в том, чтобы поместить сообщение, подтверждающее, что процесс входа в систему использует безопасное соединение. В сообщение были внесены некоторые улучшения, однако определенное количество жалоб клиентов все еще оставалось.
Надеюсь, это поможет.
На самом деле это не ответ на ваш вопрос, но Microsoft прекрасно понимает, что настраиваемое сопоставление SSL с веб-сайтами является одной из наиболее востребованных функций для веб-сайтов Azure, и они заявили, что работают над этим. Скотт Это подтверждает и сам Гензельман
А пока ответ Тома - вполне допустимый обходной путь.
Однако я бы очень осторожно подумал о том, что Том поднимает: предупреждение системы безопасности, которое будет отображать браузер. Вы будете удивлены, как много людей сходят с ума, увидев это сообщение, и не идут дальше! У нас есть довольно активный сайт электронной коммерции, и были случаи, когда мы случайно использовали небезопасный путь к изображениям на странице SSL, и мы всегда получали электронные письма от клиентов, спрашивающих, был ли наш сайт взломан или что-то подобное! Заявление об отказе от ответственности, о котором упоминает Том, - хорошая идея, но я думаю, что это все равно оттолкнет некоторых людей.
Я работаю напрямую с командой WAWS прямо сейчас, чтобы подготовить некоторые публичные рекомендации по этому поводу. Репозиторий GitHub с требованиями в настоящее время оценивается командой (я отправил его им буквально час назад). Надеюсь, решение будет одобрено и обнародовано в течение нескольких недель.
Я могу сказать следующее - обходной путь не будет полностью поддерживаться, и не будет дано много настраиваемых инструкций по его использованию, кроме репозитория и сопроводительной документации. SSL - это буквально приоритет №1 для продукта, и сотни людей работают безумно много часов, чтобы сделать это возможным для всех. Этот обходной путь также следует рассматривать как временный, поскольку он вам больше не понадобится после запуска полной функциональности SSL.
