プロジェクト

全般

プロフィール

Backport（バックポート） #2109

部分一致検索を行う箇所でワイルドカード検索ができてしまう

Minoru Takai がほぼ13年前に追加. 12年以上前に更新.

ステータス:
Fixed（完了）
優先度:
Normal（通常）
担当者:
Yuya Watanabe
対象バージョン:
OpenPNE 3.4.16
開始日:
2011-05-17
期日:
2011-10-06
進捗率:

100%

説明

Overview (現象)

メンバー画面の「メンバー検索」や「コミュニティ検索」、あるいは管理画面の「メンバー管理」などでは、ニックネームやキーワード等で部分一致検索が行える。ここで、アンダースコア("_")やパーセント("%")を含めて検索すると、文字としてではなくメタ文字（ワイルドカード）として検索が行なわれてしまう。

これは仕様と考えれば問題ではないと言えるが、この動作は意図した仕様ではなく、不具合として扱うべきであると考えられる。

Causes (原因)

LIKE検索を行っている箇所では

$query->addWhere('name LIKE ?', '%'.$value.'%');

のように（部分一致）検索文字列として入力された値を直接渡しているためメタ文字がそのままメタ文字として扱われてしまっている。

Way to fix (修正内容)

LIKE検索は関数化されていない（LIKEメソッドがあるわけではない）ため、LIKE文を用いている箇所全てで入力文字列中のメタ文字をエスケープするか、最終的にSQLが生成される時点でエスケープを施すという対応が考えられる。

opDoctrineQuery クラスに LIKE 検索用のメソッドを作成し、それを各所で使用するように書き換える。このチケットではコアのみを扱う。

なお、このチケットで「意図しないワイルドカード検索ができてしまう問題」を解消するのは MySQL を使っている場合とする（仮に他のDBで問題が解消されていなくても MySQL でさえ解消されていれば良いものとする）。

Note (補足)

バックスラッシュを含む文字列での検索についての挙動も気になる。例えば "foo\bar" というニックネームのメンバーがいる場合、メンバー検索で "foo" と検索すればヒットするが、 "foo\" と検索してもヒットせず、 "foo\\" と検索するとヒットするような動作を確認している。

関連するチケット

関連している OpenPNE 3 - Bug（バグ） #2106: 部分一致検索を行う箇所でワイルドカード検索ができてしまう Fixed（完了） 2011-05-17
関連している OpenPNE 3 - Backport（バックポート） #2108: 部分一致検索を行う箇所でワイルドカード検索ができてしまう Fixed（完了） 2011-05-17

関係しているリビジョン

リビジョン 876c2ac3 (差分)
Yuya Watanabe が12年以上前に追加

(fixes #2109, BP from #2106) added function for 'where like' query in
opDoctrineQuery class.

BP from #2106
commit 95d9ef3386809ab4aeefa446a516b1da2bcb82df
commit 7598001aa03369606ec2c9ba26a78930fdede272
commit bf00466d085647955e6f5b27371343ee03838b74

リビジョン 7a842e82 (差分)
Yuya Watanabe が12年以上前に追加

(refs #2109, BP from #2106) added function whereLike() to like query.

BP from #2106
commit 7598001aa03369606ec2c9ba26a78930fdede272

履歴

#1 Kiwa Sakai がほぼ13年前に更新

  • 対象バージョン を OpenPNE 3.4.14 にセット

対応をお願いしたいです。

#2 Shinichi Urabe がほぼ13年前に更新

  • 対象バージョン を OpenPNE 3.4.14 から OpenPNE 3.4.15 に変更

親チケットの修正がないため次期バージョンでの取り込みとします

#3 Mutsumi Imamura が12年以上前に更新

  • 対象バージョン を OpenPNE 3.4.15 から OpenPNE 3.4.16 に変更

親チケットの対応が完了していませんので対応を見送ります

#4 Hiroshi Kato が12年以上前に更新

親チケットに伴う対応で、OpenPNE-3.6beta13向けのプラグインの修正は行っていますが、OpenPNE-3.4系向けのプラグイン側の修正は行っていません。
3.4系対応時に各プラグインへの対応も検討してください。

■対象プラグイン
opAlbumPlugin
opCommunityTopicPlugin
opDiaryPlugin
opOpenSocialPlugin
opWebAPIPlugin

#5 Minoru Takai が12年以上前に更新

  • 説明 を更新 (diff)

#6 Shinichi Urabe が12年以上前に更新

  • 期日 を 2011-10-06 にセット
  • 担当者 を Yuya Watanabe にセット

#7 Yuya Watanabe が12年以上前に更新

  • ステータス を New（新規） から Accepted（着手） に変更

バックポート元である #2106 と同様の修正を施します．

具体的には op/util/opDoctrineQuery.class.php にLIKE検索用のメソッドを追加し，LIKE検索を用いているコード部分でそのメソッドを用いるように修正します．

また， http://redmine.openpne.jp/issues/2106#note-20 で記述されているように lib/util/opFormItemGenerator.class.php の一部と lib/model/doctrine/FileTable.class.php については修正を行いません．

#8 wa ta が12年以上前に更新

  • ステータス を Accepted（着手） から Pending Review（レビュー待ち） に変更
  • 進捗率 を 0 から 50 に変更

更新履歴 876c2ac3d17a44ff902b1cd3adab61ca9e2a7c5e で適用されました。

#9 Minoru Takai が12年以上前に更新

3.4.x のコア側への修正内容としては note-8 での修正はレビューOKです。

本チケットにおける次の内容について 3.4 系のリリースマネージャーに確認を行います。

note-4 や親チケットで示されていますが、この問題（仕様変更）はコアおよびバンドルプラグインに共通するものです。コア側の修正は本チケットで 3.4.16 に取り込まれるようですが、 3.4.16 にバンドルされるプラグインについては修正を取り込まないでよいでしょうか。

■対象プラグイン
opAlbumPlugin
opCommunityTopicPlugin
opDiaryPlugin
opOpenSocialPlugin
opWebAPIPlugin

プラグイン側の修正は別チケットで扱うべきだとは思いますが、このチケットの内容を考えるとコア側とバンドルプラグイン側で同時に修正されている方が自然なようには思います。

3.4.16 でコア側のみ対応して、バンドルプラグイン側は 3.4.17 で、あるいは将来的に対応するというのも悪くはないと思いますが、現時点でプラグイン側についての予定が全く言及されていないのは不適切だと思います。

  • (1) 3.4.16 でコア側とバンドルプラグイン側を両方対応し、 3.4.16 でバンドルするプラグインのバージョンを本件対応版にする
  • (2) 3.4.16 ではコア側のみで修正し、 3.4 系向けバンドルプラグインは 3.4.17 リリースまでに対応し、バンドルプラグインの本件対応版は 3.4.17 でバンドルする
  • (3) コアとプラグインを同時に修正するため、本チケットでの修正を取り消し、 3.4.17 でコアとバンドルプラグインを両方対応する
  • (4) 3.4 系ではバンドルプラグイン側の対応を行わずに、コアのみ 3.4.16 で対応する
対応表 3.4.16 コア 3.4.16 バンドル 3.4.17 コア 3.4.17 バンドル
(1) ◯ ◯ ◯ ◯
(2) ◯ × ◯ ◯
(3) × × ◯ ◯
(4) ◯ × ◯ ×（今後も対応せず）

OpenPNE-3.4.16 のリリースに際してどのように対応することが望ましいか検討してください。レビュー待ちのままにしておきます。

#10 Shinichi Urabe が12年以上前に更新

Minoru Takai は書きました:

3.4.x へのコア側への修正内容としては note-8 での修正はレビューOKです。

本チケットにおける次の内容について 3.4 系のリリースマネージャーに確認を行います。

note-4 や親チケットで示されていますが、この問題（仕様変更）はコアおよびバンドルプラグインに共通するものです。コア側の修正は本チケットで 3.4.16 に取り込まれるようですが、 3.4.16 にバンドルされるプラグインについては修正を取り込まないでよいでしょうか。

■対象プラグイン
opAlbumPlugin
opCommunityTopicPlugin
opDiaryPlugin
opOpenSocialPlugin
opWebAPIPlugin

プラグイン側の修正は別チケットで扱うべきだとは思いますが、このチケットの内容を考えるとコア側とバンドルプラグイン側で同時に修正されている方が自然なようには思います。

3.4.16 でコア側のみ対応して、バンドルプラグイン側は 3.4.17 で、あるいは将来的に対応するというのも悪くはないと思いますが、現時点でプラグイン側についての予定が全く言及されていないのは不適切だと思います。

  • (1) 3.4.16 でコア側とバンドルプラグイン側を両方対応し、 3.4.16 でバンドルするプラグインのバージョンを本件対応版にする
  • (2) 3.4.16 ではコア側のみで修正し、 3.4 系向けバンドルプラグインは 3.4.17 リリースまでに対応し、バンドルプラグインの本件対応版は 3.4.17 でバンドルする
  • (3) コアとプラグインを同時に修正するため、本チケットでの修正を取り消し、 3.4.17 でコアとバンドルプラグインを両方対応する
  • (4) 3.4 系ではバンドルプラグイン側の対応を行わずに、コアのみ 3.4.16 で対応する
対応表 3.4.16 コア 3.4.16 バンドル 3.4.17 コア 3.4.17 バンドル
(1) ◯ ◯ ◯ ◯
(2) ◯ × ◯ ◯
(3) × × ◯ ◯
(4) ◯ × ◯ ×（今後も対応せず）

OpenPNE-3.4.16 のリリースに際してどのように対応することが望ましいか検討してください。レビュー待ちのままにしておきます。

同時のタイミングでリリースできるのが理想ですが、コア側の修正を先にいれ
別途アナウンスを行い、3.4向けバンドルプラグインにも #2109 の修正を取り込んだプラグインをリリースをお願いする旨を告知しようと考えています。(2) の方針

対象プラグイン

  • opAlbumPlugin (1.0.0 で対応[リリース済み] 現在 0.9.4.1 : OpenPNE3.6.0 も 0.9.4.1 のため 3.6に追従する)
  • opCommunityTopicPlugin (0.9.9 で対応[未リリース] 現在 0.9.8.1 : 0.9.9 のリリース次第で取り込み)
  • opDiaryPlugin (1.2.1で対応？[未リリース] 1.4.0(3.6向け)はリリース済み 現在1.2.0 : 1.2.1で取り込み想定？)
  • opOpenSocialPlugin (0.9.13で対応[リリース済み] 現在 0.9.12 :バージョンアップ予定)
  • opWebAPIPlugin (0.5.1 で対応[リリース済み] 現在 0.5.0 :バージョンアップ予定)

#11 Shinichi Urabe が12年以上前に更新

  • ステータス を Pending Review（レビュー待ち） から Fixed（完了） に変更
  • 進捗率 を 50 から 100 に変更

修正内容は問題ないと思いますので、チケットは完了にします

他の形式にエクスポート: Atom PDF