blog.longkey1.net

wordpressの投稿者毎ページ(author.php)で投稿者別にデザインとかメッセージとかいろいろ変更したい場合、如何に投稿者IDを取得するかということのメモ。

hogehoge.com/blog/?author=2

とアクセスした場合、"author+author_ID"ってクラス名をセットしたい

class="author2"

みたいな感じで。

wp-content/themes/テーマ名/sidebar.phpとかheader.php等のインクルードされる側のテンプレートの場合

class="author<?php echo get_the_author_ID(); ?>"

wp-content/themes/テーマ名/author.phpやindex.php等のインクルードする側のテンプレートの場合

class="author<?php echo $wp_query->query_vars['author']; ?>"

queryっていうとデータベースってイメージだけど、GET値も含まれるんだなあ。

らしいです。

これからのプログラムの作り方 - 文字エンコーディング検証は必須

mb_check_encoding関数が使えるのはPHP 4.4.3以降らしいので、それ以前の場合はmb_convert_encoding関数を使用すれば良い模様。

mb_convert_encoding関数を使用し、変換前と変換後の文字エンコーディングに同じ文字エンコーディングを指定し、変換前と変換後の文字列に変化があるかを確かめる事により不正な文字エンコーディングを検出できます。

けど、UTF8だと同じUTF8でも違う結果を出力する場合も有るんだよなあ。
ハイフンとかその辺りだった気がするが・・・。

まあ、その辺はセキュリティとのトレードオフってことになるんだろうね。

※2008/09/02追記
Ethna 2.5.x用のプラグインを作ってみた。
エラーメッセージの英語に自信ないけど、その辺はご愛嬌で。

app/plugin/Validator/Hoge_Plugin_Validator_Charenc.php

class Hoge_Plugin_Validator_Charenc extends Ethna_Plugin_Validator
{
    /** @var    bool    配列を受け取るかフラグ */
    var $accept_array = false;

    /**
     *   文字エンコーディングのチェックを行う
     *
     *  @access public
     *  @param  string  $name       フォームの名前
     *  @param  mixed   $var        フォームの値
     *  @param  array   $params     プラグインのパラメータ
     */
    function &validate($name, $var, $params)
    {
        $true = true;
        $type = $this->getFormType($name);
        if (isset($params['charenc']) == false || $this->isEmpty($var, $type)) {
            return $true;
        }

        // define call back function for array_walk()
        if (function_exists('mb_check_encoding')) {
            // mb_check_encoding exists. just use it
            if (!mb_check_encoding($var, mb_internal_encoding()) {
                if (isset($params['error'])) {
                    $msg = $params['error'];
                } else {
                    $msg = _et('Please input character string
                                of correct character encoding to {form}.');
                }
                return Ethna::raiseNotice($msg, E_FORM_ENCORDING_STRING));
            }
        } else {
            // mb_check_encoding does not exist. use mb_convert_encoding()
            $val = mb_convert_encoding($var, $encoding, $encoding);
            if (!($val === $this->form_vars[$name])) {
                if (isset($params['error'])) {
                    $msg = $params['error'];
                } else {
                    $msg = _et('Please input character string
                                of correct character encoding to {form}.');
                }
                return Ethna::raiseNotice($msg, E_FORM_ENCORDING_STRING));
            }
        }

        return $true;
    }
}

あと、エラーコードも追加。

Hoge_Error.php

define('E_FORM_ENCORDING_INVALID', 301);

一回も動かしてないけど、こんな感じでいけるかな？
なるべく上の方に持っていけば、そのタイミングでチェックしてくれると思うけど、typeが一番最初に来てしまうことも注意。
きになるなら、そこまで手を加える必要がある。

いろんなサイトみたんだけど説明わかんなくてここをみたら、わかった。
WebAppSec - WebAppSec Wiki - 脆弱性の解説/Session Fixation

これは対策してたな、この脆弱性しらなかったけど、なんとなくやばいっしょってことで。
でらこえー。
俺のシステム開発綱渡りだなー。
セキュアなシステム作るのは非常にお金が掛かるね。
見積りの出し方考えないとなー。

＋＋で足すと同時に代入した時の値が、僕の予想と違ったのでメモ。

$num = 1;
$num_new = $num++;

echo $num;     // 2が表示される
echo $num_new; // 1が表示される

javascriptで見つけてPHPでも検証したら同じだった。

ちなみに

$num = 1;
$num_new = $num + 1;

echo $num;     // 1が表示される
echo $num_new; // 2が表示される

とこちらは予想通り。

今日始めて知ったけど、ちょっと間違えちゃいそうで怖いので使わないな。
これだから我流は怖い。

Ethnaのログで一杯出てた。
一杯出てたんだけど、まいっかと思って放置してた。
けど、たまにログを見ると、こやつがむやみにログを汚しているので、本腰入れて直した。

ログを出しているところは、
Ethna_Plugin_Validator_Customの45行目。

$ret =& $this->af->$method($name);

ずっとEthna本体が悪いのかなーと思ってんたんだけど、カスタムなので自分の作った関数がいかんのじゃないかと思ったらビンゴ。
情けない・・・。

参考にしたサイトがこちら。
はっぴぃ・りなっくす - Notice [PHP]: Only variables should be assigned by reference - Tools > PHP - SmartSection

参照って分かっているようなわかっていないような。
けど、この説明は判りやすい気がした。

参照とは、値そのものではなく、値の格納されているメモリ位置の情報です。

ポインタとかってCOBOLの奴と一緒の概念かな。
Cとかと一緒らしいけど、まったくわかんないし。
COBOLも忘れてまったけど・・・ひたすら数えていた気がする。

この警告PHP4.4.xから出るんだな。
なるほど、無頓着なはずだ。