- このトピックには23件の返信、2人の参加者があり、最後に
により1年前に更新されました。
-
投稿
-
【お使いの Snow Monkey のバージョン】20.0.1
【お使いの Snow Monkey Member Post のバージョン】6.0.2### 発生している問題
ログインURLを変更している際の、ログインと登録の不具合と、専用ディレクトリのまま表示している場合の不具合。### 試したこと
下記の通り検証を行った。いつもお世話になっております。Snow Monkey Member Postのショートコードによるログインフォームと登録フォームでの不具合が確認できたので、ご報告いたします。
■検証内容
専用ディレクトリにインストールして、ルート表示している場合と専用ディレクトリのまま表示している場合の2種類で検証した結果、以下のような不具合が確認できました。CASE-A 専用ディレクトリ→ルート表示
専用ディレクトリ : https://example.com/wp
トップページ URL : https://example.com/CASE-B 専用ディレクトリ→そのまま表示
専用ディレクトリ : https://example.com/wp
トップページ URL : https://example.com/wp■CASE-AとCASE-Bともに不具合あり
ログインURLを「wp-login.php」から「xyzlogin.php」等に変更している場合
・ログインフォーム：404になってログインできず
・登録フォーム：404になって登録できず■CASE-Aのみ問題なし
ログインURLを「wp-login.php」のままにしている場合
・ログインフォーム：問題なし OK
・登録フォーム：問題なし OK■CASE-Bのみ不具合あり
ログインURLを「wp-login.php」のままにしている場合
・ログインフォーム：ログインはできているが、https://example.com/wp/wp/と、専用ディレクトリの部分がもう一度付与されるURLにリダイレクトされるため、404になる。
・登録フォーム：登録はできているが、https://example.com/wp/wp/?checkemail=registeredと、上記同様に付与されたURLにリダイレクトされるため、404になってしまう。以上です。ご確認のほど、よろしくお願い申し上げます。
いいねをした人: 居ません早々にお返事いただきありがとうございます！
現在イントラシステムを設計している中で気がついた問題でしたので、すぐに動いていただけるのは本当にありがたく、非常に助かります。
ログインURLはプラグインを用いて変更しています。
今回試したプラグインは「Login rebuilder」と「XO Security」の2種類でしたが、どちらで変更した場合にも同じ挙動になることを確認しています。ご確認、ご対応のほど、よろしくお願い申し上げます。
いいねをした人: 居ませんどちらのプラグインもログイン URL を
site_urlフィルターフックで書き換えているようなのですが、Member Post のログインフォームのactionも<?php echo esc_url( site_url( 'wp-login.php', 'login_post' ) ); ?>とsite_urlを使っているんですよね…まだ詳しくデバッグできていないので、更に詳しく調べてみます。いいねをした人: 居ませんお忙しい中、早速ありがとうございます。
キタジマさんのコメントを受けて、プラグインを使わずにURLを変更する方法でも試してみましたが、しくみは同じことになるためでしょうね、やはりダメでした…。
お手数ですが、よろしくお願いいたします！
いいねをした人: 居ませんご返信ありがとうございます。今回は以下の方法で試してみました。
●ログインURLを henkou-login.php とする場合
henkou-login.phpを作成し、下記を記述。
<?php define( 'LOGIN_CHANGE', sha1( 'keyword' ) ); require_once './wp-login.php'; ?>My Snow Monkeyに下記を記述。
define( 'LOGIN_CHANGE_PAGE', 'henkou-login.php' ); add_action( 'login_init', 'login_change_init' ); add_filter( 'site_url', 'login_change_site_url', 10, 4 ); add_filter( 'wp_redirect', 'login_change_wp_redirect', 10, 2 ); if ( ! function_exists( 'login_change_init' ) ) { function login_change_init() { if ( !defined( 'LOGIN_CHANGE' ) || sha1( 'keyword' ) != LOGIN_CHANGE ) { wp_redirect( home_url() ); exit; } } } if ( ! function_exists( 'login_change_site_url' ) ) { function login_change_site_url( $url, $path, $orig_scheme, $blog_id ) { if ( ( $path == 'wp-login.php' || preg_match( '/wp-login\.php\?action=\w+/', $path ) ) && ( is_user_logged_in() || strpos( $_SERVER['REQUEST_URI'], LOGIN_CHANGE_PAGE ) !== false ) ) $url = str_replace( 'wp-login.php', LOGIN_CHANGE_PAGE, $url ); return $url; } } if ( ! function_exists( 'login_change_wp_redirect' ) ) { function login_change_wp_redirect( $location, $status ) { if ( strpos( $_SERVER['REQUEST_URI'], LOGIN_CHANGE_PAGE ) !== false ) $location = str_replace( 'wp-login.php', LOGIN_CHANGE_PAGE, $location ); return $location; } }以上です。よろしくお願い申し上げます。
いいねをした人:コードありがとうございます！ XO Security のものとほぼ同じ実装のようでした。
ちょっと試してみたいたのですが、どうも WordPress コアのログイン・ログアウトブロックの場合でも送信先の URL が
wp-login.phpのままになってしまうようでした。
なのでこのログイン URL を変更するコード自体に何らかの問題があるのでは？という気がしました。Member Post のほうを、このコードに合わせる形で何らかの変更を入れることができないか、もう少し調査してみます。
いいねをした人:日曜日ですのに、ありがとうございます。
なるほど、コアの方でもそうなるのですね。。
原因が特定できたかも…という感じですので、あとはキタジマさんがきっと解決してくださるだろうと、すでに勝手に安心しています。笑お手数ですが、よろしくお願いいたします！
いいねをした人: 居ませんすみません、ちょっと無理そうな気がしてきました…。コードを追っていくと下記の部分があるのですが、
/** * Get the login URL. * * @param string $url URL. * @param string $loginfile Login filename. */ private function get_login_url( $url, $loginfile ) { if ( is_user_logged_in() ) { return str_replace( 'wp-login.php', $loginfile, $url ); } if ( empty( $_SERVER['REQUEST_URI'] ) ) { return $url; } if ( false !== strpos( $_SERVER['REQUEST_URI'], $loginfile ) ) { // phpcs:ignore WordPress.Security.ValidatedSanitizedInput $url = str_replace( 'wp-login.php', $loginfile, $url );既にログイン済みの場合か、変更後のログインページを開いているときにログイン URL の書き換えがおこなわれるようです。つまり、ログイン済みか今からログインしようとログイン画面を開いているときのみ書き換えが行われるということで、Member Post のフォームは非ログイン時しか表示されないので書き換えがおこなわれないということになります…。なぜこの条件指定になっているのかがよくわからなかったのですが、何か理由があるのかもしれませんね…。
いいねをした人:ご確認等々、ありがとうございます。
おぉ…そうなのですね。キタジマさんでも難しいとなると、仕方ないですね。。
サブディレクトリ問題の方は解決しそうでもありますし、今のままでもリダイレクトをかければ機能することが確認できたので、何とかなりそうですね。
ちなみにサブドメインのルート表示でも試したのですが、この場合も通常のルート表示同様に大丈夫でした。Member Postのフォームが見栄えもよくて使い勝手もよいため、何とか使いたいところですが、ログインURLの変更とのトレードオフとなると考えないといけませんね。
私の方でも、もう少し検証や調査をしてみたいので、しばらくトピックはこのままにさせてくださいませ。
何か別の手法との組み合わせでも機能させられないものか、考えてみたいと思います。いいねをした人: 居ません書き換え側で対処してもらわないと完全な対応は難しいので、とりあえず XO Security が有効化されている場合は Member Post 側で XO Security の設定値を読み込み、フォームのログイン URL を書き換えるようにします（XO Security の変更を追っているわけではないので、XO Security 側で変更があった場合は正しく動作しなくなる可能性はあります）。
サブディレクトリの対応についてはもうしばしお待ちを…。
いいねをした人: 居ませんキタジマさん
早々に調査やご対応検討などいただき、ありがとうございます。
XO Securityを使用した際の対策について、承知しました。
ひとつ教えてください。
もし、XO Securityを使用せず、さきほど示した独自の方法の場合だと（コア側の変更は別として）、「変更があった場合の正しい動作不安」もなく使い続けられる可能性が高まる、ということでしょうか。
あるいは、XO Securityの設定値を読み込み、URL書き換えの処理を行う方法が現時点では最適解、といった背景があってのことでしょうか。
そのあたり理解が追いついておらず申し訳ないのですが、ご教示いただけますと幸いです。
サブディレクトリ対応につきましても、承知しました。
お手数ですが、よろしくお願いいたします！
いいねをした人: 居ませんもし、XO Securityを使用せず、さきほど示した独自の方法の場合だと（コア側の変更は別として）、「変更があった場合の正しい動作不安」もなく使い続けられる可能性が高まる、ということでしょうか。
あるいは、XO Securityの設定値を読み込み、URL書き換えの処理を行う方法が現時点では最適解、といった背景があってのことでしょうか。
うーんそうですね、人によって考えは違うかもしれませんが、「XO Securityの設定値を読み込み、URL書き換えの処理を行う方法」は（XO Security のアップデートで互換性が崩れることがある可能性を除けば）利用者側は難しいことを特に考えなくて良いというのがメリットです。
独自の方法だと好きに書き換えができるわけですが、XO Security や Login rebuilder が同じような条件下でのみ書き換えを許可していることを考えると、なんでもかんでもフックで書き換えるのが良くない、という可能性もあるのかなと（ちょっとこの辺は僕は詳しくないです）。もし本当にそうだったとしたら、フックでかきかえるのはあまり良くない方法なのかもしれません。
今↓のように
site_url( 'wp-login.php', 'login_post' )と URL を書いているところを、$action = site_url( 'wp-login.php', 'login_post' ); if ( class_exists( '\XO Security' ) ) { // XO Security で URL 書き換え設定が有効化されている場合は $action を書き換え $action = str_replace( ... ); } ?> <form action="<?php echo esc_url( $action ); ?>" ...>のようにすれば、フックで書き換えているわけではないので、影響が及ぶ範囲を Member Post のフォームだけに限定でき、大問題には発展しないのかなという感じです。
いいねをした人:
- トピック「Snow Monkey Member Post ショートコードによるログインと登録時の不具合」には新しい返信をつけることはできません。