続、コメントの編集機能session版
この記事は公開または最後に更新されてから3224日が経過しています。情報が古くなっている可能性があるのでご注意下さい。
コメントの編集機能の続編です。
wordpressのコメントに関する関数、編集の wp_update_comment()、削除の wp_delete_comment() についてはコメントの編集機能に記載してあります。
上記ページで作ったコメント編集、削除機能は、良く知っている方だけが見る、非公開サイト用なのでほとんどセキュリティの事など考えもしないで作ったもの。
金銭のやりとりのある商品販売のためのフォームでもないから、ユーザーに迷惑がかかることもないだろうし、何かおこるとすればメールアドレスを盗み見られるぐらいでしょうか。
少し関心があって不正アクセス対策等のセキュリティに関する本を何冊か読んでみましたが、一般に公開しているサイトにおいては何がおこるかわからないということもあります。
それにここのところ外国からの(特に中国だと思えます)スパムコメントがやたらと多くなって、ログを見ていると何やら気味の悪い事をしていそうなのです。
と、いうことで備えあれば憂いなしですし、少しでも手を打っておこうとsession機能を使って造り直してみました。
ただ、session機能はcookieを受け入れるようにしていないと使えないことになるのでその辺は不便になりますが。
urlでsessionIDをやり取りできるようにすればcookieは必要ありませんが、それだとsessionを使うメリットも無くなってしまうように思います。
2015年12月17日追記:nonce で新しく作り直しています。【コメントの編集機能、nonceで作り直してプラグイン】
前回作ったものは、ユーザーから入力された検証用のメールアドレスとコメントIDはフォームのhiddenに入れてページのリロード時にPOSTで送信してデータを持ち回りさせていました。
その辺を改良して、それらのデータをsessionで扱って、どうせsessionを使用するならフォームの偽造を防ぐワンタイムチケットの機能も付けようという目論見です。
186~210行目は編集、削除のボタンを押されてリロードされた時に表示する編集用のフォーム部分。
ヘッダー部分の158~165行目部分と末尾の236~259行目部分に関して。
検証で何らかのエラーがあって途中で処理が終了してしまった場合に236~259行目部分で失敗したことの表示とセッションデータの破棄を行っています。
セッションデータの破棄を処理しているのは249~259行目ですが、実はこれがあるとFirefoxとSafariにおいて正常に動作しなくなります。
Firefoxでいろいろ様子を見たところ、コメントを見るときに直接このページのコメント表示部分に対してのリンク(たとえば https://strix.main.jp/?page_id=26870#comments というような)で開いた時に正常に動かなくなります。
コメントを表示する<div id="comments">に対してのジャンパーというのかなんというのかurlに#commentsがついている時におかしくなります。
セッションデータやPOSTで送信されるデータを見ているとどうもPOSTのデータが無くなったりしているようなのでセッション変数にカウンターを設けてみるとやはりurlに#commentsがある時は2度リロードし異常で、ない時は1度のみで正常に作動します。
2度再読み込みするためにPOSTで送信されるデータが無くなってしまい、検証が不正になり、セッションデータも破棄されてしまうようです。
それにしても不思議ですねぇ、面白いです。これにたどり着くのに随分時間と手間を要しました。
データの処理の仕方に問題があるのか、フォームの表示の仕方に問題があるのかよくわからないところです。
Safariに関しては、詳しく検証しませんでしたが、ジャンパーの有無にかかわらずこのセッションデータ破棄の処理があると正常に動作しませんでした。
ちなみにFirefox、Safariとも、2012年11月6日現在においての最新バージョンです。
まぁこの249~259行目部分は検証でエラーがあった場合のセッションデータを破棄する処理なので、そんなに頻繁に発生することもないだろうし、特にFirefoxとSafariにおいてだけの問題のようなので、それ以外の時にだけ処理させればいいかという気もします。そんなにセッションデータのゴミもたまらないだろうしガベッジコレクタにお任せしてもいいのではと。
で、この2つのブラウザにこの処理を無視させれば期待した通りの動作をしてくれます。
とは言うもののなんだかすっきりしませんね。
特にFirefoxはメインに使用しているブラウザなのでなんとかしたくなります。
いろいろ考えあぐねたすえに、エラーがあった場合の処理を別ファイルを呼び出して処理させることにしました。
それが158~165行目部分です。
検証で得たエラーフラグと自らのurlをセッション変数に作って、目的のファイルへリダイレクトさせています。
リダイレクトされるファイルはセッションデータからどのファイルから呼び出されたかを検証し、セッションデータの破棄を行い、再び元のページへリダイレクトするだけのページです。一応、固定ページにて作成しました。
当然のことですが、このリダイレクトさせる処理をするのであれば、236~259行目は不必要です。
ここまでやる必要もなさそうですけどね。
尚、コメントの編集機能の最後にも掲載してあるcomments.phpのフォーム部分の追加はこちらでも必要です。
Post : 2012/11/07 09:29
Talking
本当に勉強になります。
応援しています!!
ドラえもんさん。
コメントありがとうございます。
いやぁ、ほんとにうれしいなぁ!
とても励みになります。
Comments feed
Trackback URL : https://strix.main.jp/wp-trackback.php?p=27500