0

みんな！当然、私はまだ HTML Purifier と戦っています…</p>

したがって、私の /config/purifier.php は次のようになります。

<?php defined('SYSPATH') or die('No direct access allowed.');
return array(
    'settings' => array(
        'HTML.Allowed' =>'a,b,strong,p,ul,ol,li,img[src],i,u,span,',
  'HTML.MaxImgLength' => 250,
  'CSS.MaxImgLength' => '250px'
            ),
);
?>

また、HTML Purifier は Security::clean_xss() メソッドをオーバーロードして独自のフィルターを使用します。

データ サニテーション用に 2 つのヘルパー関数を作成しました: clean_whitelist() は、構成ファイルの HTML.Allowed 設定で許可されていないものを取り除きます。すべてのタグを削除し、ignore として渡されたフィールドを無視する clean_all()

 public static function clean_all(array $dirty_data, array $ignore) {
  $config = Kohana::config('purifier');
  $settings =  $config['settings'];
  $config->set('settings', array ('HTML.Allowed'=>''));
  foreach($dirty_data as $key => $value) {
   if( ! in_array($key, $ignore)) {
    $dirty_data[$key] = Security::xss_clean($dirty_data[$key]);
   }
  } 
  return $dirty_data;
 }

 public static function clean_whitelist($dirty_data) {
  return Security::xss_clean($dirty_data);
 }

clean_whitelist() は意図したとおりに機能しますが、clean_all は引き続きタグを許可します。Kohana::config('purifier')を呼び出した後にの新しいロードを var_dump$config->setすると、HTML.Allowed => ''…</p> を表示するファイルが表示さ れるため、完全にはわかりません

実行時に作成した構成ファイルを使用するのではなく、ホワイトリストを使用し続ける理由についてのアイデアはありますか?

いつものように、貢献してくれた人に感謝します!

4

1 に答える 1

0

使用している Kohana HTMLPurifier モジュールは、おそらく元の構成オプションでインスタンスをキャッシュしています。

このモジュールを使用している場合は、ソース コードからこのメソッドを確認してください。

于 2011-03-22T11:34:27.340 に答える