投稿者アーカイブにクエリパラメータでアクセスしたときに発生するリダイレクト

Question

http://example.com/?author=1のようなURLにアクセスしたときにhttp://example.com/author/adminのようなユーザー名を含むURLにリダイレクトしてしまうので、これをユーザーIDを参照する形にしようと思いリライトルールを書き換えて管理画面から更新してみたのですが、依然としてユーザー名へのリダイレクトが発生します。

function edit_wp_rewrite() {
  global $wp_rewrite;

  $wp_rewrite -> add_rewrite_tag( '%author%', '([0-9]+)', 'author=' );
}
add_action( 'init', 'edit_wp_rewrite', 0 );

また、投稿者アーカイブのリライトルールを削除して投稿者アーカイブを無くしてもこのリダイレクトは発生します。

// 投稿者アーカイブのリライトルールを削除
add_filter( 'author_rewrite_rules', '__return_empty_array' );

このリダイレクトの処理は一体どこで行われているのでしょうか…？

Answer 1

404にはなりますが、確かにユーザー名が出ますね。
未検証ですが、下記のような解決方法を見つけました。（明日試してみます）

add_filter( 'author_rewrite_rules', '__return_empty_array' );
function disable_author_archive() {
	if( $_GET[ 'author' ] || preg_match( '#/author/.+#', $_SERVER[ 'REQUEST_URI' ] ) ){
		wp_redirect( home_url( '/404.php' ) );
		exit;
	}
}
add_action( 'init', 'disable_author_archive' );

【投稿者アーカイブを無効化してWordPressのユーザ名を隠す方法 | ウェブコンテンツウェブコンテンツ】
http://www.webcontent.jp/no-author-archive/

---

追記：

投稿者アーカイブが利用できなくなるのは避けたいので、
author/admin ではなく author/1 にリダイレクトする

これでは？

function only_my_author_archive() {
	if( $_GET[ 'author' ] && $_GET[ 'author' ] > 0 ){
		wp_redirect( home_url( '/author/'.intval( $_GET[ 'author' ] ) ) );
		exit;
	}
}
add_action( 'init', 'only_my_author_archive' );

---

追記2：

カノニカル時に利用されているであろう '%author%' を使っている（記述がある）のが get_author_posts_url get_permalink の2つのみで、「Edit_Author_Slug」が使用しているのが get_author_posts_url 内の author_link フックなので、ひとまずこれでいけそう。

add_filter( 'author_rewrite_rules', '__return_empty_array' );
function my_author_link( $link = '', $user_id = 0 ) {
	if ( $user_id > 0 ) {
		$link = home_url( user_trailingslashit( '/author/'.$user_id ) );
	}
	// Return the link.
	return $link;
}
add_filter( 'author_link', 'my_author_link', 20, 2 );

（参考）

【get_author_posts_url() | Function | WordPress Developer Resources】
https://developer.wordpress.org/reference/functions/get_author_posts_url/

【get_permalink() | Function | WordPress Developer Resources】
https://developer.wordpress.org/reference/functions/get_permalink/

Comments

[flat]

回答して下さりありがとうございます。
私もリダイレクトでアクセスできなくするという情報は目にしていたのですが、投稿者アーカイブが利用できなくなるのは避けたいので、このリダイレクトのパーマリンク構造を制御して author/admin ではなく author/1 にリダイレクトするパーマリンク構造に書き換えることができたらいいなと考えています。

[flat]

追記での対応ありがとうございます。
新たにリダイレクトしてしまうのもひとつの手ですね。
ただ、今回はできれば元のリダイレクトに設定されているパーマリンク構造そのものを制御したいと考えています。
考えすぎだと言われるとそれまでなのですが、元のリダイレクトが有効になる可能性を完全に潰しておきたいのです。

[kei344]

/author/1 ⇒ リライトルール ⇒ ?author=1 ⇒ redirect_canonical ⇒ /author/me というような処理系だったような。同じ記事に対して複数のURLが可能で、それらを正規化する目的だったと思います。

今から調べることはちょっと難しいので、明日以降見てみます。WordPress のパスの動きの制御は今とても興味があるので･･･。

【#WordPress 特定のカノニカルリダイレクトを拒否する（どちらでもお好みで） · GitHub】
https://gist.github.com/hissy/5283729

[manabufukai]

横から失礼いたします。
author=1を別のauthorへ、というリダレクトという訳ではありませんが
> 今回はできれば元のリダイレクトに設定されているパーマリンク構造そのものを制御したいと考えています。
という一文から、こういった処理はプラグインでやってしまうほうがいいかな…と。
「Edit Author Slug」という便利なプラグインがあります。
https://ja.wordpress.org/plugins/edit-author-slug/
実質的にどういった処理をすれば良いか、もプラグインの中を解読すれば分かると思います。中を読めば分かると思いますが、結構色々な処理を経由しなければなりません。
ご参考までに。

[kei344]

To: manabufukai
「Edit Author Slug」便利ですよね。最初これが ?author=1 を適切にリダイレクトしてくれるか確認できればそれでいいかな、とも思ったのですが、解決を急いでしまいました。
なんとなくWP自体のコードを追いそうになっていたので、まずこちらを追ってみます、助かりました。

[manabufukai]

Re: kei344さん
ああ、いえいえ、割り込み失礼しました。。
前に自分も自前で実装しようと思ってやってみたらうまく行かなかった=>したい処理・似たような処理が実現されているプラグインの中を覗いたら、間に色々処理を挟まなければならなかった
ということが多々あったので…というくらいです。

WordPressはプラグインが本当に豊富でたいていのことは網羅されているので、そこから学ぶのが早いし確実かなーと（WordPressを作成している方々がチェックされているものでもありますし）個人的には考えています。

[flat]

To: kei344
redirect_canonical
はじめて知りましたが、これがURLを正規化していたんですね。
リライトルールばかり見ていたので全然気付きませんでした…。
コアファイルのcanonical.phpと、manabufukaiさんのコメントにあるプラグインのコードも見てみようと思います。

To: manabufukai
助言して下さりありがとうございます。
どうしてもダメだったときは私もそのプラグインを利用しようと思っていたのですが、処理内容を参考にするという考えが頭から抜け落ちていたので早速これから見てみようと思います。

ちなみに、私はプログラミング歴が1年足らずでプログラミングに使える時間も多くないので、無精してコピペプログラマーになってしまわないようになるべくプラグインを使わず、可能な限り自分で実装してみる(または既存のコードの処理を追って確認しながらきちんと理解する)という方針を取っています。
質問内容に「プラグインを使用しないことが前提」と書いておくべきだったのかもしれませんが、もし書いていたらmanabufukaiさんからコメントをもらえなかったかもしれないと思うと書いておかなくてラッキーだったと言うほかありません:)
コメントを頂けたことに感謝致します。

[manabufukai]

Re: flatさん
「なるべくプラグインを使わずに」というのはとても良い心がけだと思います。
自分も可能な限り自前で実装をしていますが、ケースによってはプラグインを使うほうが良い場合がある、というものかなとも考えています。

ここからはちょっと色々先走りでしたが…
クライアントワークではテーマに全て依存させると色々と不便なケースが多々あるので（リニューアル等でテーマ変更した際に不具合など…）
機能の切り分けを行ったほうが良い=>プラグイン化=>（あ、同じ機能のプラグインがある…）
ということも少なくないので、

・無ければ自作orスクラッチ
・中でどういう処理をしているのか知りたければコードを読めばいい
・自前でつくったほうが効率化できるなら、読んで学んだコードを模倣

というのを慣例にしてしまっていたところがありましたね。。

「プラグインを使用しないことが前提 ≠ プラグインのコードを読まない」
かな、と個人的には考えています。

> 不精してコピペ…
ならないように、自分も気を引き締めます…苦笑
ちょっと怠け癖がついてきているので、いい薬になる一言をありがとうございます。

・・・ここからは頭のほんの片隅にでも・・・（本当に参考程度の意見として）
自分の中ではユーザー情報の秘匿というのは重要度が高い項目なので
（IDのみといえど、これはセキュリティに関わる箇所かなと考えています※IDくらい知られたところでというところでもありますが、基本としてログインに関わる情報はすべて秘匿する、というのが自分のポリシーなので）

そういった箇所は下手に独自実装せず、安定性などが実証されているものを使っておいて、
そこで「どんな処理が」「何のために」行われているのかを理解し、その上で改良できるなら自前で作成してみる、という考え方もあるかな…と。

いくつかのWordPressサイトを管理させてもらっていますが、本当に予想だにしていなかった手法でクラックを試みる輩もいるので、自前でそれらをすべてブロックできるのなら…というところでもあるのかなと考えます。

[kei344]

（自己紹介にコピペプログラマーと書いたバカがここに居るとかとても言えない）
私も、「なるべくプラグインを使わずに」というのはとても良い心がけだと思います。プラグインの動きを把握するためにはプラグインを作るのが一番早いと思うからです。

ただ、自作プラグイン以上に公式で公開されているプラグインはさまざまな環境での使用/テストに耐えた歴戦の勇士であること（そうでもないものも有るけど）、WPのコアがアップデートするたびに独自コードのテストが必須であることなど、長く運用するにあたっては信頼性のより高いほうを選択するため、基本的に公式プラグインから探すことをします。
その上でコードを確認し、問題があれば自分で管理していく（導入したクライアントについてのみですが）など考える感じですね。まぁ自作のプラグインを公式に公開することでバグとアップデートと戦う覚悟を決めるというのもひとつ方法かな、とは思います。

[flat]

Re: manabufukai
> ケースによってはプラグインを使うほうが良い
そのまま使えるものがある場合は素直にそれを使った方が良い事が多々あるというのは確かにそうですね。
そして、そういったものが沢山あるのもWordPressの良いところだと感じています。
「勉強を兼ねて」という目的があったのでプラグインの利用を避けていましたが、本番環境では結果が大事なので、プラグインの利用も積極的に考えていこうと思います。

> プラグインを使用しないことが前提 ≠ プラグインのコードを読まない
「自力で！」という意識が先行しすぎて完全に頭から抜け落ちていました。
できることが増えてくると、それが楽しくてつい… XD

> ユーザー情報の秘匿
仰っていることには完全に同意します。
私も同じ考えで「Edit Author Slug」と、これとは別に「SF Author Url Control」というプラグインにも辿り着きました。
しかし、これらのプラグインを使用しても /?author=1 から投稿者アーカイブ(Author Baseやカスタムスラッグは設定したものになっている)へのリダイレクトは発生するんです。
つまり /?author=1 というクエリが機能している以上はユーザーIDを隠すことはできないんですよね。
不正なアクセスの多くは手作業ではなく自動化された処理ですし、このクエリがある以上はユーザーIDの確認なんてすぐできてしまうと思うので、隠せないのならユーザーIDベースの投稿者アーカイブでも良いかなと考えたのです。

> 独自実装
私も処理の目的とその内容の理解という点はとても大事なことだと考えているので、それらを理解した上で安全性を損なわない丁寧なコードを書くということはしっかり意識していこうと思います。
今回の質問にある処理の目的はセキュリティの強化なので、セキュリティに対する考え方という話はとても参考になります :)

[flat]

To: kei344
> 自己紹介にコピペプログラマーと書いた
処理内容を理解できればコピペでも大丈夫なはずです X)

> 公開されているプラグイン
プラグインの公開は一大決心が必要ですよね。
保守・更新をしっかりと継続しているプラグインは本当に重宝しますし、非常に有難い存在です。
私も流石にすべてを自前で用意することは難しいので、基本的には公式にあるプラグインを利用します。
その中から必要な機能のみに絞れそうな場合や、ちょっと機能が不足していたり痒い所に手が届かないような場合に自作してみるというのが現状ですね。

> 自作のプラグインを公式に公開
私はプラグインを作って公開するにはまだまだレベルが足りません XD

[manabufukai]

To: kei344 さん
（…消しておけばバレないかと←）
プラグインに関するお考えには完全に同意です。
確かにWordPressは更新頻度が高いので、プラグイン化するとどうしてもバグチェックに追われたりすることもありますね…。（簡単な機能のものなら以外と数年単位更新いらない、なんてこともありますが）
自分も公式プラグインは作成していないので大きなことは言えません。。。

Re: flat さん
> これらのプラグインを使用しても /?author=1 から投稿者アーカイブ(Author Baseやカスタムスラッグは設定したものになっている)へのリダイレクトは発生するんです〜クエリが機能している以上はIDを隠すことはできないんですよね。

ええと…リダレクトそのものは発生しますが、
「httpリクエスト上は飛ばない＋userまわりのクエリのレスポンス結果そのものを変える」で生IDは秘匿できたはずかと？（推測されやすいIDを使っているなら意味合いは弱まりますが）

> プラグインの利用も積極的に考えていこうと思います。
いくつも作成してくると「何だか毎回書いてる気がする…」というスニペットが出てくるかと思います。そんな時はプラグインを利用するのも一つかなと思います。
また、自前の関数やクラス等でよく使うものを一まとめにしてプラグインにしておくと、結構便利です。

[flat]

Re: manabufukai
> 生IDは秘匿できたはず
私の考えているIDと、manabufukaiさんの考えているIDの認識が異なっている気がします。
manabufukaiさんの仰っているIDは、get_userdata()で取得できるuser_loginやuser_nicenameの値のような情報のことですよね…？(違ったらごめんなさい)

私の言うIDは登録ユーザーに自動的に割り振られるID、つまりget_userdata()で取得できるIDの値のことです。
/?author=1というクエリの値である'1'もこれですね。

このIDは/?author=1で404レスポンスが返らずに投稿者アーカイブにリダイレクトが発生した時点で「そのユーザーIDが存在する」ことが分かるので、その様な意味で「プラグインを利用してもIDは隠すことができない」と書きました。
しかし、こうして見ると「ユーザーID」という言葉は紛らわしいですね…！

[flat]

To: kei344
追記して下さりありがとうございます。
そして追記に気付く前に私もほぼ同じコードに行き着いたのですが、もしかしたら無駄な処理が多いかもしれません。

// get_author_posts_url() で取得するURLを変更
function reformat_author_posts_url( $link = '', $author_id = 0 ) {
// ユーザー情報を取得
$author = get_user_by( 'id', $author_id );
// ユーザースラッグを取得
$author_slug = $author -> user_nicename;
// URLに含まれるユーザー名をユーザーIDに置換
$link = str_replace( $author_slug, $author_id, $link );
// パーマリンクの構造に応じて末尾のスラッシュの有無を切替
$link = user_trailingslashit( $link );

// 置換したURLを返す
return $link;
}
add_filter( 'author_link', 'reformat_author_posts_url', 20, 2 );

こうして見るとkei344さんのコードの方がコストが低く済んで良さそうですね。

[manabufukai]

re: flat さん
ああ、なるほど。get_userdata()オブジェクト内のIDプロパティということですね？
（※おっしゃる通り、自分が言っていたIDというのはログインに使用するID＝user_loginプロパティの値のことです。こちらの認識がちょっとズレていましたね…申し訳ございませんでした。。）

完全に話の腰を折った感じでしたね…大変失礼いたしました。。

---ここからは参考程度に---
確かに、author=1の権限グループは後から変更ができないので、存在する＝管理者
という公式は成り立ちますが、重要なのはそこからどんなデータが返されるか？だと思います。
実際、IDプロパティの値が分かったところでその情報だけでは攻撃には結びつきません。
SQLインジェクションできてしまう箇所があるなら論外ですが、
閲覧者が自由に入力可能な箇所から「自前でデータベース接続する＋受け取った値で動的にクエリを発行（静的プレースホルダーを使っていない等）※注1」という処理を追加していない限り、WordPress側でちゃんと対応されているのでSQLインジェクションの危険性はほとんど無いと言えるかなと。
（※注1：動的に組み立てるのが絶対的に悪い、とは言えませんが）

なので、クエリの結果から返る値をしっかりと処理してさえいれば、author=1の存在有無が外部に漏れることの問題はさほど無いかな、と考えています。

思い切り横道に逸れてしまいましたね…申し訳ないです。。

[flat]

Re: manabufukai
> 申し訳ないです。
いえいえ、とても有益なお話でした。
どのようなデータかというのはしっかりと認識しなければいけませんね。
初心を忘れないことと同じように、私もその意識は常に持つように改めて心掛けていきます。

あとは余談というか雑談みたいになってしまいますが、manabufukaiさんのコメントに触発されて色々とユーザー情報の秘匿に関する課題が浮かんできました。

- comment_class()
ログインユーザーのコメントのクラスにユーザー名が表示される(フィルターフックで簡単に対処できる)
*対処済み

- ユーザーの新規登録
10文字未満のユーザー名(user_login)による登録は無効にする
新規登録時の項目にニックネームも追加して、新規登録時から表示名をニックネームにする処理を追加(これは「SX User Name Security」というプラグインでおそらく可能)
「Gianism」などのプラグインでソーシャルアカウントによる登録ができるようにする

- 著者への連絡先情報としてメールアドレスを表示させたい場合は、登録時のメールアドレスとは別のメールアドレスを表示させるように諸々の処理を追加(それほど難しくない)

- ログインIDをログインユーザー名かメールアドレスのどちらかひとつにする
メールアカウントが乗っ取られた場合やリスト型アカウントハッキングを考慮すると、ログイン情報をユーザー名のみにした上で2段階認証などを導入するのが無難？

このあたりでしょうか。
プラグインに頼らずに全部に対応しようとすると物凄く大変そうなので、プラグインで対応できるところはプラグインを利用した方が良いですね。
対応済みのcomment_class()以外は、私の場合にはすぐに対応しなければいけないようなものは無いのであくまでも思い浮かんだだけなのですが、もしかしたらこれらの対応が必要になるときが来るかもしれません。

何だか話を広げすぎた気がしますが、またこのような機会がありましたら、その時にはぜひ回答を頂けると嬉しく思います。

[flat]

To: kei344
すみません、解決したと思っていたというか解決自体はしているのですが、ちょっと疑問に思った事があったので質問に追記します。

追記
ごめんなさい、変数名を間違えていたというケアレスミスによる私の勘違いでした…。
回答を編集する前に気付いて良かった…。