現在、Azure WebサイトではカスタムSSL証明書は許可されていませんが、*。azurewebsites.netドメインでワイルドカードSSLが有効になっています。Webアプリに安全なログインフォームが必要ですが、カスタムSSLがないため、SOLであるように見えます。
これに対する回避策はありますか？どういうわけか、https：//mydomain.azurewebsites.netにログインフォームを作成して、 http：//mydomain.comで機能するフォーム認証チケットを作成することは可能でしょうか。
数か月前、まったく同じ問題が発生しました。つまり、アプリケーションはAzure Webサイトで構築され、以外のカスタムドメインで実行する*.azurewebsites.net必要があり、安全なログインプロセスを許可する必要がありました。
私たちが使用した回避策は、カスタムドメイン（例）の非安全ページにiframeを（例：安全なプロトコルと.azurewebsites.netドメイン名を使用して）埋め込むことでした。そして、ログインプロセス全体がiframeで実行されました。https://oursite.azurewebsites.net/loginhttp://mysite.com/login
注意すべき点が1つあります。つまり、多くの顧客が、資格情報を提供するページが安全な接続を使用しているかどうかを確認します。私たちの場合、セキュリティで保護されていないページのセキュリティで保護されたiframeは、多くの顧客からの苦情を引き起こしていました。この問題の回避策は、ログインプロセスが安全な接続を使用していることを確認するメッセージを表示することでした。メッセージにはいくつかの改善がありましたが、それでも一定数の顧客からの苦情が残っていました。
それがお役に立てば幸いです。
これは実際にはあなたの質問に対する答えではありませんが、MicrosoftはWebサイトにカスタムマップされたSSLがAzure Webサイトで最も要求されている機能の1つであることを非常に認識しており、取り組んでいると言っています。 スコットハンゼルマン自身がここでそれを確認します
それまでの間、トムの答えは完全に有効な回避策です。
しかし、私が非常に警戒することの1つは、トムが提起するものです。それは、ブラウザーが表示するセキュリティ警告です。そのメッセージを見て、それ以上先に進まない人の数に驚かれることでしょう。私たちはかなり活発なeコマースサイトを持っており、SSLページで誤って安全でない画像パスを使用したことがあり、私たちのサイトがハッキングされたかどうかを尋ねる電子メールを常に受け取っています！トムが言及する免責事項は良い考えですが、それでも一部の人々を先延ばしにするだろうと思います。
私は現在、WAWSチームと直接協力して、このための公開ガイダンスを作成しています。要件を含むGitHubリポジトリは現在、チームによって評価されています（文字通り、1時間前にGitHubリポジトリに送信しました）。うまくいけば、ソリューションは数週間以内に承認され、公開されるでしょう。
私はこれを言うことができます-回避策は完全にはサポートされないか、リポジトリと付属のドキュメントを除いて、その使用法について多くのカスタムガイダンスが提供されます。SSLは、文字通り、製品の最優先事項であり、何百人もの人々が、すべての人にSSLを実現するために非常識な時間で働いています。この回避策は、完全なSSL機能が起動されると不要になるため、一時的なものと見なす必要があります。