私はhttpsで保護された管理領域と安全なフロントエンド領域を必要とするサイトに取り組んでいます。私のユーザーログインの好みは、サイトのすべてのページに表示できるAjax対応のウィジェットですが、送信されたフォームデータをセキュリティで保護されていないページからログインページに渡すときは機能しません。
私は、 Login With Ajax プラグインを使用することから始めました。これは、いくつかの変更を加えれば、ほとんどの場合SSLでうまく機能します。 FORCE_SSL_ADMINがオフになっているときはうまく機能します。しかし、FORCE_SSL_ADMINをオンにしてセキュリティで保護されていないページのウィジェットからログインしようとすると、サーバーから応答がありません。
この問題を解決する既存のプラグインはありますか?そうでなければ、誰もが解決策を持っている?セキュリティ保護されたフォームをiframeに埋め込むことがこれまでの最善の策かもしれません…もっと簡単な方法があるはずだと考えるだけで。
私はまだ興味があるのでこの質問に賞金を追加しています。私は自分のプロジェクトで、ウィジェットをあきらめてwp-loginページへのリンクを表示することによって回避しました。しかし、安全ではないページに安全なログインフォームを埋め込むことができれば、はるかに良い解決策になります。それを実現するのに役立つコードを見せることができる人なら誰にでも賞金を授与するか、またはすでにこれを行っているプラグインを私に指摘します。
Hhtpやhttps、およびデフォルトのAJAX関数を使ってWPを呼び出すと、AJAX登録フォームが可能になります。たぶん、あなたはこのチュートリアルからのプラグインフォームを見るでしょう: http://www.wpajax.com/code/ /私はこれがあなたのための解決策であると思います。
私は同じような問題を抱えていました、そしてそれはすべて関数wp_signon( $credentials, $secure_cookie )
がどのように呼ばれたかに依存していました。
サインオン後は自分のサイト上のすべてのものがhttpsになるようにしたいので、セキュリティで保護されていないクッキーを使用することをお勧めします。
Ssl以前の私のコードでは:wp_signon($ credentials、false)
だから私は変更しました:
wp_signon( $credentials, false )
に
wp_signon( $credentials, true )
これにより安全なクッキーが作成され、今ではすべて問題ありません。
私は、プラグイン開発者が安全なクッキーを設定するためにFORCE_SSL_ADMIN
に頼ることを試みることを想像することができます。あなたのケースではwp_signon( $credentials, false )
を使ってみてください。私はそれが問題を解決することを願っています。
それをする方法があります。 このように 例えば。 Ajaxでログインすると、この記事で説明されているすべての手法が使用されるわけではなく、ブラウザのセキュリティ機能によってブロックされていると考えられます。その記事へのポインタで、開発者と連絡を取り、改善点を提案してみてください。
プラグインは見ていませんが、AjaxリクエストでhttpsなしでログインURLをハードコーディングしているのではないかと思います。 wpログインフォームはhttpsを使用しないように設定されているフォームアクションとともに、その非httpsバージョンでは正常に機能するため、Ajaxが機能しない理由はよくわかりません。
プラグインを変更することが選択肢ではない場合は、以下の方法を試すことができます。
1つはwp_footerフックのいくつかのjqueryの良さでしょう。ログインフォームのIDを検索し、そのURLを変更します。例:$(ID).attr('action', newValue);
(フォームのメソッドやアクションを変更するときにフォームタグのjquery coughingを漠然と思い出したので、私は100ではありません。)
URLがログインフォームのHTMLには表示されているがAjax呼び出しには表示されない場合の2番目の方法は、出力バッファをwp_head
に開始し、そのURLをstr_replace()
にすることです。
3番目のアプローチは、実際のURLがパラメータとしてjsスクリプトにある場合、wpで使用される画像のURLの自動シックボックスプラグインで行われているように、wp_footerの値を上書きすることです。
最後の選択肢は、スクリプトが関数呼び出し内でハードコーディングされたログインURLを持つ厄介なスパゲッティコードである場合、wp_dequeue_script()
を使用してそれをデキューし、それを置き換えるためにあなた自身のバージョンをエンキューすることです。あなたがこれをするならば、優先順位を気にしてください:あなたのwp_print_scripts
アクションは、明らかに、プラグインのそれの後に起こるべきです。
私はAJAXプラグインで同様の問題を抱えていました。
https://stackoverflow.com/questions/6301076/wordpress-single-page-ssl に関する提案の後、これをwp-config.phpファイルに追加しました:
if( !empty($_SERVER['HTTPS']) ) {
define( 'WP_SITEURL', 'https://yourdomain.com' );
define( 'WP_HOME', 'https://yourdomain.com' );
}
それから、私は特定のページ(AJAXを含むもの)をhttps://のみにすることを強制しました(そのためのプラグインがあります)。