typista

Archive for the ‘JavaScript’ Category

取り急ぎのバージョン0.3bにも残存していたXSSの脆弱性は、PHPによるコード出力を廃止することで対策しました。
度重なるYuriko様のご指摘に助けられた反面、さらに慎重を期すためWORDPRESSフォーラムへの報告は、しばらく見送ります。

修正内容は、細かな機能アップも含めて主に次の５点です。

• PHPによるコード出力を廃止
• リンク先がfeed等のXMLの場合、その内容のチェックは見送る
• チェック対象外URLに”wp-login.php”を追加(この対策によりチェック後の管理画面ログアウトを回避)
• チェック中を示す「Checking …」のロジック見直し(カウンターのインクリメント箇所が正しくなかったため、フリーズしたように見えてしまっていたことへの対策)
• チェック済み／チェック合計数、開始／終了時刻の表示

使い方

1. dead-link-checker.0.4b.zipをダウンロード
   (最新版はhttp://typista.xii.jp/wp-content/uploads/dead-link-checker.zip)
2. プラグインディレクトリに解凍
3. ダッシュボードからアクティベート
4. リンクチェックの実行は、「ダッシュボード」→「設定」→「Dead Link Checker Plugin」→「start」ボタン。

以上で、bloginfo(“url”)からリンクを辿り、リンクチェックを開始します。中断も可能です。
正常なページは、一覧から消えていき、エラーの場合は、HTTPステータスコードとそのリンクを含むURL（非同期の複数コネクション実行のため、最新１つで上書き）も表示します。

制限事項

「はてなブックマーク」への追加リンク、W3CのHTML Validatorへのリンクなどで400または404エラーとなります。原因調査中ですが、当デッドリンクチェッカーでエラー検知されたURLは、手動にて確認されるようお願いいたします。
また、現状ではハイパーリンクのみの抽出のため、JSやCSSは対象外です。

今後の対応

大きな機能追加要件として、被リンクゼロチェック機能、つまりどこからもリンクされていない画像等を抽出する機能を想定しています。が、これはかなり難航するかも知れません。
小粒要件としては、JSやCSSのデッドリンクチェックへの対応です。formへの対応は決めかねています。
その他、チェック結果表示のポップアップウィンドウ化 or iframe化や体裁、それらのオプション設定などなどです。

取り急ぎのバージョン0.2、0.3、0.3bにもXSSの脆弱性が残存していました。
Yuriko様から再びのご指摘をいただき、修正しました。

修正内容は、主に次の３点です。

• get_file_contents()はphp.iniの設定に依存するため、fsockopen()に変更
• HTTPステータスコードが301と302のときは、リダイレクト先をチェック(fsockopenの影響で必要になった処理)
• 明らかに自ドメインの場合のみ取得ソースをecho(入力パラメータ$urlが”/”を含まない場合、末尾に付加)

なお、このバージョン0.3bでは、feed等のXMLを対象としたリンクチェックが不完全な状態です。この不具合よりも、XSS対策版を優先すべきという観点で、リリースさせていただきます。

使い方

1. dead-link-checker.0.3b.zipをダウンロード
   (最新版はhttp://typista.xii.jp/wp-content/uploads/dead-link-checker.zip)
2. プラグインディレクトリに解凍
3. ダッシュボードからアクティベート
4. リンクチェックの実行は、「ダッシュボード」→「設定」→「Dead Link Checker Plugin」→「start」ボタン。

以上で、bloginfo(“url”)からリンクを辿り、リンクチェックを開始します。中断も可能です。
正常なページは、一覧から消えていき、エラーの場合は、HTTPステータスコードとそのリンクを含むURL（非同期の複数コネクション実行のため、最新１つで上書き）も表示します。

制限事項

前述のとおり、本バージョンでは、feed等のチェックが不完全です。この不完全ですが、JavaScriptエラーで処理が中断してしまいますので、同時セッション数は、３以上が良いかも知れません。(自サイトのチェックの場合、feedとatomの２つでセッション中断で以降のチェックが進みません。)前バージョンでは正しくチェックされていた(と思われます)ので、今回の処理変更との影響を調査中です。
しばらくお待ちください。
jQuery(JavaScript)を利用したチェックのため、このプラグインでのエラー検知が万全ではないようです。
これは、(予想の域を越えませんが)ｊQuery、というよりJavaScript(？)では、クロスドメインでのHTTP通信不可のため、擬似的にサーバサイドで回避(*1)しています。この対処(出力)が万全でないのかも知れません。
また、現状ではハイパーリンクのみの抽出のため、JSやCSSは対象外です。

今後の対応

大きな機能追加要件として、被リンクゼロチェック機能、つまりどこからもリンクされていない画像等を抽出する機能を想定しています。が、これはかなり難航するかも知れません。
小粒要件としては、JSやCSSのデッドリンクチェックへの対応です。formへの対応は決めかねています。
その他、チェック結果表示のポップアップウィンドウ化 or iframe化や体裁、それらのオプション設定などなどです。

ｊQueryの勉強も兼ねて、デッドリンクチェッカーを作りました。ハイパーリンクであれば、画像も対象です。非同期通信で、同時接続数はチューニング可能にしています。(デフォルト値は2)
クライアントはもちろん、サーバにも負荷がかかりますので、同時接続数は適宜、試してください。

WordPressのbloginfo(“url”)から順次HTMLソース内のハイパーリンクを辿ります。HTMLソースで相対パス表示の場合、当チェックの実行パス(＝http://example.com/wp-admin/)からの相対解釈になってしまう対処に、少し手こずりましたが、[javascript]相対URLを絶対URLにする関数に救われました。

なお、重複チェックは無限ループになるため、当然除外し、外部ドメインについては、１階層までチェックします。つまり、対象WordPressサイトのリンク品質を確保するためのツールです。

使い方

1. dead-link-checker.zipをダウンロード
   (最新版はhttp://typista.xii.jp/wp-content/uploads/dead-link-checker.zip)
2. プラグインディレクトリに解凍
3. ダッシュボードからアクティベート
4. リンクチェックの実行は、「ダッシュボード」→「設定」→「Dead Link Checker Plugin」→「start」ボタン。

以上で、bloginfo(“url”)からリンクを辿り、リンクチェックを開始します。中断も可能です。
正常なページは、一覧から消えていき、エラーの場合は、HTTPステータスコードとそのリンクを含むURL（非同期の複数コネクション実行のため、最新１つで上書き）も表示します。

制限事項

jQuery(JavaScript)を利用したチェックのため、このプラグインでのエラー検知が万全ではないようです。
これは、(予想の域を越えませんが)ｊQuery、というよりJavaScript(？)では、クロスドメインでのHTTP通信不可のため、擬似的にサーバサイドで回避(*1)しています。この対処(出力)が万全でないのかも知れません。
また、現状ではハイパーリンクのみの抽出のため、JSやCSSは対象外です。

今後の対応

大きな機能追加要件として、被リンクゼロチェック機能、つまりどこからもリンクされていない画像等を抽出する機能を想定しています。が、これはかなり難航するかも知れません。
小粒要件としては、JSやCSSのデッドリンクチェックへの対応です。formへの対応は決めかねています。
その他、チェック結果表示のポップアップウィンドウ化 or iframe化や体裁、それらのオプション設定などなどです。

追記

外部リンクのチェック用サーバサイドスクリプト(上記*1)がXSS攻撃に悪用される危険性がありました。
バージョン0.1をご利用の方は、0.2以降にアップデートしてください。

Ktai Styleの作者Yuriko様にご指摘いただき、修正しました。

追記２

Yuriko様から、さらにご指摘いただき、XSS攻撃対策が不完全でしたので、修正しました。
バージョン0.3bにアップデートをお願いします。
なお、バージョン0.3bでは、feed等のXMLを対象としたリンクチェックが不完全な状態です。この不具合よりも、XSS対策版を優先すべきという観点で、リリースさせていただきます。
このデバッグ／修正に時間がかかりそうですが、対策完了次第、リリースいたします。
もし、当プラグインをご利用いただいている方がいらしたら、大変ご迷惑をおかけしますが、今しばらくお待ちください。

前回のバグ回避策で触れましたように機種依存文字の検出ロジックを見直し、 ver.0.3bで公開します。
NGをチェックする方式 ⇒ OKをチェックする方式 に変更しました。
機種依存文字などチェックのソースをそのまま流用させていただきました。
 

使い方

1. x-charactercode-validator.0.3.zipをダウンロード
   (最新版はhttp://typista.xii.jp/wp-content/uploads/x-charactercode-validator.zipです)
2. プラグインディレクトリに解凍
3. ダッシュボードからアクティベート

今後の対応

FCKEDITORにも対応可能な方策を探します。どなたかアドバイスいただけると幸いです。
検知した場合に置換してしまうオプション設定が可能となるような機能拡張は、引き続き予定しています。

前回の課題にあげたMac版に、ほんのり対応しました。 OS XのFireFoxで試したものの、WYSIWYGモードでは入力したMac機種依存文字が文字化けしていた（ソースモードでは機種依存文字が正しく表示される）状態ながら、一応検出されていると思われるので、ver.0.2で公開します。 ＊Mac版の品質フィードバックをいただけるとうれしいです。

使い方

1. x-charactercode-validator.0.2.zipをダウンロード
   (最新版はhttp://typista.xii.jp/wp-content/uploads/x-charactercode-validator.zipです)
2. プラグインディレクトリに解凍
3. ダッシュボードからアクティベート

今後の対応

Mac版で不具合があれば、その対応。 検知した場合に置換してしまうオプション設定が可能となるような機能拡張。

補足

WYSIWYGは、FCKEDITOR2.4.1を利用しています。標準のWYSIWYGなら文字化けしないのかも試してみたいと思いますが、少し時間がかかると思いますので、どなかた試された方からの報告をいただけると幸いです。 それとMacの機種依存文字をJavaScriptで配列化するために、機種依存文字一括変換辞書にある「MAC機種依存→共通.txt」を利用しました。 このファイルはSJIS保存だったため、Mac版のチェック用JavaScriptファイルは、

charset="Shift_JIS"

でのインクルードです。

2008.06.06追記（バグ報告）

WYSIWYGにFCKEDITOR2.4.1を使っている場合に、１度検知された機種依存文字を削除しても、記事を保存することができないことがわかりました。 <textarea id="content">の値が、onLoad時に取得したままの状態で更新されないことが要因です。 「保存」「公開」ボタンを押したときの

target = document.getElementById( "content" );

を取得するように試行錯誤中です。 取り急ぎの回避策としては、WordPressデフォルトのWYSIWYGエディタに戻し、かつ記事編集後、逐一「ビジュアル」→「HTML」→「ビジュアル」の切り替えが必要です。(この結果、target.valueが更新されるため、機種依存文字チェックが正しく機能します。)

2008.06.06追記（バグ回避策）

デフォルトのWYSIWYGエディタの場合のみ、苦肉ですが以下のバグ回避策を講じました。
→ x-charactercode-validator.0.3.zip からダウンロードしてください。

FCKEDITORは、まだ回避策が見つかりません。

if ( ( ‘undefined’ == typeof wpTinyMCEConfig ) || ‘tinymce’ == wpTinyMCEConfig.defaultEditor ) { switchEditors.go(‘content’);
}

同時に、機種依存文字の検出ロジック(の流用元)を見直し、従来は機種依存文字をターゲットに検索していましたが、機種依存しない文字(共通文字)の範囲にあるかをチェックする方式に変更しています。