Google Crisis Response(Google)
災害に関する情報源や、行方不明者情報の収集と検索を行う『パーソンファインダー』を初めとするツールの提供が行われています。

2011年5月21日 土曜日

MODXを使ってみました

Filed under: インターネット,ソフトウェア
タグ:, , ,
時間:18時54分
投稿者:よしとも
AddClips 経由でソーシャルブックマークに登録

WordPressで構築したサイトを、CMSのMODXを使って再構築をしてみました。WordPress使用者の視点から導入の解説を簡単にしてみたいと思います。

WordPressとCMS

もともとブログを目的として作られたWordPressですが、最近はCMS的な使い方をされることも多くなりました。導入事例として紹介されている中には、かなり知名度の高い大手企業も複数含まれます。いくつか例を挙げてみます。

私も、MMORPGで参加しているギルドサイトの構築で試しにWordPressを使用してみたことがあります。ページ数が少なくてコンテンツが増える予定もなかったので、固定ページだけで構成してしまう方法を採用しました。テーマのどのファイルを使用するか指定できますし、アドレスも意味のある単語が使用できます。

サイトは完成し、これといって問題もないまましばらく運用していました。問題はなかったのですが、なんとなくCMSを使ってみたくなり、思い切って再構築を行うことにしました。

CMSの絞込み

私も改めて調べてから気がついたのですが、世の中には非常にたくさんのCMSが存在します。一般的に公開されている中ではWikiとXOOPSしか知りませんでしたが、ウィキペディアのコンテンツマネージメントシステムの項で汎用CMSとして掲載されているだけでも100近く。すべて見るのは不可能なので、ウィキペディアに項目があるものは取りあえず見るところから始めました。その中でPHPで構築されていて、尚且つ日本語で情報が得られるものを絞り込み。

この段階で数個まで絞り込むことが出来たので、それぞれ詳しい情報を収集。最終的にはDOMXを選びました。管理画面でサイトの構成が見やすいことと、バージョンが古いながらも書籍が1冊出ており日本語の公式サイトがある点が決め手になりました。

MODXによるサイト構築

まず、MODXで再構築したサイトはこちら。デザインは公式配布されている素材を使って知人にお願いしたものです。再構築前と変更はほとんどありません。

インストール

WordPressで構築したものを再現するため、ローカルサーバーに場所を確保してMODXをインストールしました。MODXには一般向けのEvolutionと大規模向けのRevolutionの2つがあり、今回使用したのはEvolutionです。

インストールは簡単です。WordPressに比べるとステップは多いですが、出来るだけ自動化しようとしたためでしょう。パーミッションの設定などはやや煩雑に感じました。詳しくは、公式サイトにあるインストールの説明をご覧ください。

コンテンツの入力

管理画面上でコンテンツを増やしていけます。コンテンツには、存在しないページにアクセスがあったときに表示するもの(「Page Not Found」です)も含めます。

階層構造にすることも出来ますが、今回はすべてフラットです。トップページは別の場所で指定するだけなので、特別扱いせずに同じ階層に作ります。

WordPressのページスラッグのようなフレンドリーURLを使用することを前提にしているので、トップページの名前はindexとして index.html でアクセスできるようにしました。

中身が出来たら、取りあえずサイトを見て確認です。デザインは後から設定するので、この時点ではデフォルトのままです。

テンプレートの作成

WordPressではサイトデザインがテーマとしてまとまっていますが、MODXの場合はテンプレートファイルに相当するものはデータベース上に登録されるだけでファイルではありません。MovableTypeと同じですね。

まずは、WordPressで構築したサイトのトップページではないページのソースを持ってきてテキストエディタに貼り付けます。そのままテンプレートにしてしまうことも出来ますが、それではCMSである意味がありませんのできちんと作ります。

コンテンツとなる部分をテンプレート変数 [*content*] に置き換えます。WordPressでは、the_content() を呼ぶのに相当します。同じように、コンテンツで登録したデータを利用したいところもテンプレート変数に置き換えます。

トップページは少し構成が異なるのでそのままでは問題があります。方法としては2つあって、1つは専用にテンプレートを作る方法。違いが多い場合はこの方法がわかりやすいです。

もう1つは、1つのテンプレートの中で分岐処理をする方法。違いがわずかな場合は変更作業などが楽になるのでお勧めです。今回は違いが次の2つだけなのでこの方法を採用しました。

  • HTMLページタイトルにコンテンツのタイトルを含めるかどうか。
  • コンテンツ内にコンテンツタイトルを表示するかどうか。

MODXのテンプレートはPHPのコードを直接書けないどころか、Smartyのような分岐処理も出来ません。自由度は下がりますが、メンテナンス性を高めるためだそうです。どうしても必要な場合は、スニペットという拡張機能としてのPHPプログラムに記述し、その結果を使いたい場所には [[スニペット名]] と記述します。

HTMLページタイトルの場合は、次のようなスニペットを使用しました。トップページ以外ではコンテンツのタイトルも含めると言うものです。

  1. <?php
  2. if( $modx->documentIdentifier == $modx->config['site_start'] )
  3. {
  4.     return '[(site_name)]';
  5. }
  6. else
  7. {
  8.     return '[*pagetitle*]  | [(site_name)]';
  9. }
  10. ?>

また、コンテンツ内にコンテンツタイトルを含めるかどうかについては、Not Found のページでも対象にしたかったため別の方法を使用しています。表示の有無を選べるテンプレート変数を登録し、それを取得して分岐するようなスニペットを登録します。前半でテンプレート変数 DisplayH2Tag の値を取得し、後半で [*content*] を含む出力をしています。[*content*] を含むようにしたのは、単にテンプレートの見通しが悪く感じたためです。

  1. <?php
  2. $tmplvar_info = $modx->getTemplateVar('DisplayH2Tag');
  3. if ($tmplvar_info !== FALSE)
  4. {
  5.     $display_h2_tag = (bool) $tmplvar_info['value'];
  6. }
  7.  
  8. print '<div id="content">';
  9. if ( true == $display_h2_tag )
  10. {
  11.     print '<h2>[*pagetitle*]</h2>';
  12. }
  13.     print '<div class="main">
  14. [*content*]
  15. </div>
  16. </div>';
  17. ?>

スニペットの登録が終わったら、テンプレートの [*content*] をスニペット変数に置き換えます。

最後に、ナビゲーション部分を Wayfinder というスニペットを使って表示します。このスニペットは初めから使用できるようになっていてなかなか便利です。

テンプレートのメニューを表示したいところに、次のようにスニペット変数を記述します。

  1. [[Wayfinder?startId=0&config=`navigation`]]

次に、設定ファイルを作成してFTPでアップロードします。設定ファイルはパラメーターを指定する替わりになるものです。設置場所が決められないのは難点。

設置場所はドキュメントルートの assets/snippets/wayfinder/configs で、ファイル名は navigation.config.php です。ファイルの内容は下記のとおり。

  1. <?php
  2. /*
  3.  * Wayfinder設定
  4.  *
  5.  * グローバルナビゲーション
  6.  */
  7.  
  8. // ----------
  9. // テンプレート
  10. // ----------
  11.  
  12. $hereTpl = '@CODE:<li[+wf.id+][+wf.classes+]>[+wf.linktext+][+wf.wrapper+]</li>';
  13.  
  14. // ----------
  15. // パラメーター
  16. // ----------
  17.  
  18. $hideSubMenus = 'true';
  19. $level = '1';
  20. $rowIdPrefix = 'page-item-';
  21.  
  22. ?>

Wayfinderの使い方については、Let’s enjoy MODxの解説が非常に参考になりました。パラメーターの意味については、そちらをご覧ください。

まとめとお礼

以上で解説終了。MODXについては素人にも届かないので、間違っているところがあったらごめんなさい。

それから、設置作業中にツイッターでPHPのmagic_quotes_gpcがオンになっていると問題になることをつぶやいたのですが、それに対して本家コミッターyamaさんから次のバージョンで修正するとのご連絡が。その後も何度かアドバイスを頂け、非常に助かりました。ありがとうございました。

Comments (0)

2011年2月19日 土曜日

WordPress の HTTP API

Filed under: WordPress,プログラミング
タグ:, , , , ,
時間:12時49分
投稿者:よしとも
AddClips 経由でソーシャルブックマークに登録

WordPress には、Snoopy という HTTP 通信用のライブラリが以前から使われています。自前で用意するには結構大変なので、拙作の AmazonLink でも利用しています。

WordPress 2.7.0 では、これに変わるものとして HTTP API が導入されました。ライブラリの変更ではなく、WordPress の持つ機能の1つという扱いです。

導入された段階では実験的な扱いでしたが、次第に多くの部分で使われるようになり、WordPress 3.0 でついに Snoopy が非推奨扱いとなっています。HTTP API が十分熟したと判断したのでしょう。

これを機会に、AmazonLink でも導入してみることにしました。現時点では Snoopy と併用するか完全に切り替えてしまうかは検討中ですが、最終的には完全な切り替えを行うことになると思います。

Snoopy の場合は別のライブラリということで、ファイルのインクルードを行い、Class のオブジェクトを取得し、実際に使用するという3段階の作業が必要です。

  1. include_once(ABSPATH.'wp-includes/class-snoopy.php');
  2. $Snoopy = new Snoopy();
  3.  
  4. $url = 'http://www.example.com';
  5. $Snoopy->fetch($url);
  6. $content = $Snoopy->results;

これに対して、HTTP API の場合は自動的にオブジェクトを取得してくれるので、いきなり実行することができます。WordPress に組み込まれているおかげです。

  1. $url = 'http://www.example.com';
  2. $result = wp_remote_get($url);
  3. $content = $result['body'];

ほかにもいろいろな機能が含まれています。残念ながら本家 Codex でもドキュメントが充実しているとは言えない状況ですので、興味のある方は実際のコードを参照してみてください。ファイルは wp-includes/http.php です。Codex 以上の説明があり、かなり参考になると思います。

ちなみに、自動的にオブジェクトを取得してくれる仕組みですが、内部でそのための関数を呼び出しています。

  1. /**
  2.  * Retrieve the raw response from the HTTP request using the GET method.
  3.  *
  4.  * @see wp_remote_request() For more information on the response array format.
  5.  *
  6.  * @since 2.7.0
  7.  *
  8.  * @param string $url Site URL to retrieve.
  9.  * @param array $args Optional. Override the defaults.
  10.  * @return WP_Error|array The response or WP_Error on failure.
  11.  */
  12. function wp_remote_get($url, $args = array()) {
  13.     $objFetchSite = _wp_http_get_object();
  14.     return $objFetchSite->get($url, $args);
  15. }

その関数の定義はこちら。プライベート関数なので直接利用するのは厳禁です。

  1. /**
  2.  * Returns the initialized WP_Http Object
  3.  *
  4.  * @since 2.7.0
  5.  * @access private
  6.  *
  7.  * @return WP_Http HTTP Transport object.
  8.  */
  9. function &_wp_http_get_object() {
  10.     static $http;
  11.  
  12.     if ( is_null($http) )
  13.         $http = new WP_Http();
  14.  
  15.     return $http;
  16. }

注目するべきは、10行目の static $http; という部分。関数から出てもこの変数は維持され、再利用が可能になります。このような手法をメモ化と言うようです。10年以上プログラムを扱ってきましたが、単語自体知りませんでした。まだまだです。

PHP のメモ化については、次のサイトを参考にしました。

ベンチマーク結果を見るとかなりの高速化が期待できそうです。HTTP 通信を行うプラグインが複数動く場合には効果的かもしれません。最近はコアでも通信を行っているようですし。

Comments (0)

2009年12月13日 日曜日

WordPressのアップグレードとユーザー権限

Filed under: WordPress,ハック
タグ:, , ,
時間:17時43分
投稿者:よしとも
AddClips 経由でソーシャルブックマークに登録

WordPress の自動アップグレードをしようとすると「このブログのプラグインを更新するための十分な権限がありません。」となってしまうので調査をしていたのですが、原因が判明しましたので記事にします。

まず、調査対象のバージョンは2.8.4です。2.6系から直接アップグレードしたもので、一番初めは2.0ME系でした。接頭辞は wp です。

権限がないといわれてしまう原因ですが、そのまま権限が与えられていないためです。管理者で作業しているので普通はそんなことはありえないのですが、どうやらアップグレード時に行われるデータベースの更新に問題があったようです。

権限情報の記録場所

権限の情報はオプションとしてデータベース上に記録されていて、次のSQLで見つけることができます。

  1. SELECT `option_name`,`option_value` FROM `wp_options` WHERE `option_name` = 'wp_user_roles';

このオプションの値はPHPでシリアライズしたもので、管理者や編集者といったロール(役割)ごとに権限を配列の形で格納しています。wp-includes/capabilities.php の冒頭には、次のように書かれています。

  1. * The role option is simple, the structure is organized by role name that store
  2.  * the name in value of the 'name' key. The capabilities are stored as an array
  3.  * in the value of the 'capability' key.
  4.  *
  5.  * <code>
  6.  * array (
  7.  *      'rolename' => array (
  8.  *          'name' => 'rolename',
  9.  *          'capabilities' => array()
  10.  *      )
  11.  * )
  12.  * </code>

権限の記録は20行目の配列で、権限名がキーでその権限があるかどうかを示す真偽値が値となります。

現状の確認

さて、ここまでを踏まえて実際にどのように権限情報が記録されているかを確認します。PHPで表示させるプログラムを書いてみてもいいのですが、面倒なのでもっと手っ取り早い方法を使いました。

前述したSQLでオプション値を取得し、それをテキストエディタ(私は秀丸エディタを使いました)に貼り付けます。このままではすべてが1行に繋がってわかりにくいので、{ と } と ; の後ろにテキスト置換で改行を入れました。
こうすると、権限名と真偽値が交互になってわかりやすくなります。

準備ができたら権限名を探します。自動アップグレードのアドレスから、きっかけとなるコードは wp-admin/update-core.php であることがわかりますので確認します。

冒頭の12行目に次のようにあります。

  1. if ( ! current_user_can('update_plugins') )
  2.     wp_die(__('You do not have sufficient permissions to update plugins for this blog.'));

update_plugins という名前の権限を確認して、権限がなければメッセージを表示して終了するという処理ですね。早速この権限名を先ほど準備したテキストデータで探しますと、見当たりません。この名前をキーとする配列要素がないということになりますので、PHPでは真偽値は false となります。

念のため新規に同じバージョンのインストールをしてみた場合で確認したところ、しっかりとこの権限については true となっていました。

なぜこうなったのか

こうなると原因が気になります。アップグレードスクリプトの権限処理をするところを探してみました。アップグレードインストールをするときのファイル名を基点にしてたどってみたところ、wp-admin/includes/upgrade.php に定義されている upgrade_all() という関数の中で、WordPressデータベースのバージョンによってアップグレード用の関数を呼び出していることがわかりました。

  1. /**
  2.  * Functions to be called in install and upgrade scripts.
  3.  *
  4.  * {@internal Missing Long Description}}
  5.  *
  6.  * @since unknown
  7.  */
  8. function upgrade_all() {
  9.     global $wp_current_db_version, $wp_db_version, $wp_rewrite;
  10.     $wp_current_db_version = __get_option('db_version');
  11.  
  12.     // We are up-to-date.  Nothing to do.
  13.     if ( $wp_db_version == $wp_current_db_version )
  14.         return;
  15.  
  16.     // If the version is not set in the DB, try to guess the version.
  17.     if ( empty($wp_current_db_version) ) {
  18.         $wp_current_db_version = 0;
  19.  
  20.         // If the template option exists, we have 1.5.
  21.         $template = __get_option('template');
  22.         if ( !empty($template) )
  23.             $wp_current_db_version = 2541;
  24.     }
  25.  
  26.     if ( $wp_current_db_version < 6039 )
  27.         upgrade_230_options_table();
  28.  
  29.     populate_options();
  30.  
  31.     if ( $wp_current_db_version < 2541 ) {
  32.         upgrade_100();
  33.         upgrade_101();
  34.         upgrade_110();
  35.         upgrade_130();
  36.     }
  37.  
  38.     if ( $wp_current_db_version < 3308 )
  39.         upgrade_160();
  40.  
  41.     if ( $wp_current_db_version < 4772 )
  42.         upgrade_210();
  43.  
  44.     if ( $wp_current_db_version < 4351 )
  45.         upgrade_old_slugs();
  46.  
  47.     if ( $wp_current_db_version < 5539 )
  48.         upgrade_230();
  49.  
  50.     if ( $wp_current_db_version < 6124 )
  51.         upgrade_230_old_tables();
  52.  
  53.     if ( $wp_current_db_version < 7499 )
  54.         upgrade_250();
  55.  
  56.     if ( $wp_current_db_version < 7796 )
  57.         upgrade_251();
  58.  
  59.     if ( $wp_current_db_version < 7935 )
  60.         upgrade_252();
  61.  
  62.     if ( $wp_current_db_version < 8201 )
  63.         upgrade_260();
  64.  
  65.     if ( $wp_current_db_version < 8989 )
  66.         upgrade_270();
  67.  
  68.     if ( $wp_current_db_version < 10360 )
  69.         upgrade_280();
  70.  
  71.     maybe_disable_automattic_widgets();
  72.  
  73.     update_option( 'db_version', $wp_db_version );
  74.     update_option( 'db_upgraded', true );
  75. }

呼び出されている upgrade_***() という関数の中では、さらに必要に応じて populate_roles_***() という関数を呼び出しています。

この関数の定義は wp-admin/includes/schema.php にあり、そこではまさにロールごとに権限の追加を行っていました。

次のSQLでデータベースバージョンを確認して呼び出されるはずの関数の処理を確認してみました。

  1. SELECT `option_name`,`option_value` FROM `wp_options` WHERE `option_name` = 'db_version';

2.6の新規インストール環境では8201となっていましたので、upgrade_all() の342~346行目が該当します。呼び出される関数の定義は次のとおり。

  1. /**
  2.  * Execute changes made in WordPress 2.7.
  3.  *
  4.  * @since 2.7.0
  5.  */
  6. function upgrade_270() {
  7.     global $wpdb, $wp_current_db_version;
  8.  
  9.     if ( $wp_current_db_version < 8980 )
  10.         populate_roles_270();
  11.  
  12.     // Update post_date for unpublished posts with empty timestamp
  13.     if ( $wp_current_db_version < 8921 )
  14.         $wpdb->query( "UPDATE $wpdb->posts SET post_date = post_modified WHERE post_date = '0000-00-00 00:00:00'" );
  15. }
  16.  
  17. /**
  18.  * Execute changes made in WordPress 2.8.
  19.  *
  20.  * @since 2.8.0
  21.  */
  22. function upgrade_280() {
  23.     global $wp_current_db_version;
  24.  
  25.     if ( $wp_current_db_version < 10360 )
  26.         populate_roles_280();
  27. }
  1. /**
  2.  * Create and modify WordPress roles for WordPress 2.7.
  3.  *
  4.  * @since 2.7.0
  5.  */
  6. function populate_roles_270() {
  7.     $role =& get_role( 'administrator' );
  8.  
  9.     if ( !empty( $role ) ) {
  10.         $role->add_cap( 'install_plugins' );
  11.         $role->add_cap( 'update_themes' );
  12.     }
  13. }
  14.  
  15. /**
  16.  * Create and modify WordPress roles for WordPress 2.8.
  17.  *
  18.  * @since 2.8.0
  19.  */
  20. function populate_roles_280() {
  21.     $role =& get_role( 'administrator' );
  22.  
  23.     if ( !empty( $role ) ) {
  24.         $role->add_cap( 'install_themes' );
  25.     }
  26. }

populate_roles_***() で追加している権限を確認したところ、3つとも登録されていました。今度はさかのぼって確認してみると、populate_roles_260() で追加される2つの権限のみがありませんでした。しかもその1つは今回問題となっている update_plugins です。

どうやらここで失敗していたようです。

  1. /**
  2.  * Create and modify WordPress roles for WordPress 2.6.
  3.  *
  4.  * @since 2.6.0
  5.  */
  6. function populate_roles_260() {
  7.     $role =& get_role( 'administrator' );
  8.  
  9.     if ( !empty( $role ) ) {
  10.         $role->add_cap( 'update_plugins' );
  11.         $role->add_cap( 'delete_plugins' );
  12.     }
  13. }

修復方法

原因まで判明したので、権限情報の修復を行います。直接書き換えてもいいのですが、間違えると面倒なので簡単なプログラムを作りました。

データを抽出して権限を追加し、再度シリアライズして表示するだけ。表示されたテキストデータをデータベース用の管理画面(ここのサーバーは phpMyAdmin が使えるのでそれを使いました)から直接反映させました。

このプログラムは自由に使っていただいてかまいませんが、何かあったときの補償はできませんので自己責任でお願いします。

  1. <?php
  2. header('Content-type: text/plain;charset=UTF-8');
  3. $link = mysql_connect('データベースサーバー', 'ユーザー', 'パスワード');
  4.  
  5. if ( $link )
  6. {
  7.     mysql_set_charset('utf8');
  8.     if ( mysql_select_db('データベース') )
  9.     {
  10.         $sql = "SELECT `option_name`,`option_value` FROM `wp_options` WHERE `option_name` = 'wp_user_roles'";
  11.         if ( $res = mysql_query($sql) )
  12.         {
  13.             if ( $rows = mysql_fetch_assoc($res) )
  14.             {
  15.                 $rol_data = unserialize($rows['option_value']);
  16.                 $rol_data['administrator']['capabilities']['update_plugins'] = true;
  17.                 $rol_data['administrator']['capabilities']['delete_plugins'] = true;
  18.                 print serialize($rol_data);
  19.             }
  20.         }
  21.         else
  22.         {
  23.             print mysql_error();
  24.         }
  25.     }
  26.     else
  27.     {
  28.         print mysql_error();
  29.     }
  30. }
  31. else
  32. {
  33.     print mysql_error();
  34. }
  35. ?>

というわけで、無事自動アップグレードの画面を拝むことができました。

Comments (1)

2009年8月9日 日曜日

AmazonLink 2.0 beta もうすぐ・・・

Filed under: AmazonLink
タグ:, , , ,
時間:18時28分
投稿者:よしとも
AddClips 経由でソーシャルブックマークに登録

平日は忙しくてまったく時間はないわ、休日は平日できてないことをやってると終わってしまうわでほぼ停止状態でしたが、昨日と今日で AmazonLink を Amazon の Product Advertising API に対応させました。

ついでに WordPress 2.7 にも対応させたので、近いうちにベータ版として公開することができそうです。2.8 は未テストなので、対象外の予定です。

また、サイドバーでやってたアンケートの結果を元に、今回から動作環境条件として PHP 5.1 以上とします。これにより、Amazon とのやり取りの処理が PHP のネイティブ関数を使えるようになるので処理が早くできるはずです。PHP 4.x の環境しかない方はごめんなさい。

ベータ版として公開したあとの予定ですが、プログラムの整理と PHP 5.x らしい書き方への変更をしたいと思っています。一緒に WordPress 2.8 にも対応したいですね。

今後も使っていただけるという方は、Product Advertising API アカウントの取得をしておいてください。8月15日以降は、アカウントがないと投稿画面での検索ができなくなります。

Comments (0)

2009年5月31日 日曜日

PHPバージョンアンケート

Filed under: AmazonLink,プログラミング
タグ:,
時間:3時21分
投稿者:よしとも
AddClips 経由でソーシャルブックマークに登録

AmazonLink を Product Advertising API(旧 Amazon アソシエイト Web サービス)に対応させるに当たり、PHPのバージョンの傾向を知るためのアンケートを開始しました。アンケートはサイドバーにも掲載されます。

PHPは4.x がすでに公式に開発終了となっていますが、まだまだ生き残っています。5.x に移行するべきではありますが、サーバー側で対応していなければどうしようもありません。大手レンタルサーバーはすでにかなり対応していますが、4.x しか使えないところも残っているようです。

現時点でどれくらいのサーバーが移行できているのかを知ることが目的です。ご協力よろしくお願いします。

メインサーバーで使えるPHPのバージョンは?
View Results
Comments (0)

2009年5月10日 日曜日

”Amazon アソシエイト Web サービス”が”Product Advertising API”に

Filed under: AmazonLink,アフィリエイト,プログラミング
タグ:, , , , , , ,
時間:17時46分
投稿者:よしとも
AddClips 経由でソーシャルブックマークに登録

Amazon.co.jp からいろいろな情報を取得することができる”Amazon アソシエイト Web サービス”というサービスがありますが、”Product Advertising API”という名称に変わるとのことです。そして、情報のリクエストには署名による認証が必要になるとのこと。

拙作 WordPress プラグインの AmazonLink でもこのサービスを使用しているので他人事ではありません。

基本方式はほとんど変わらないとのことですが、認証で使用する電子署名の作成には、開発者登録をしたときに作成した Secret Access Key というものが必要になるようです。リクエスト時のデータによって変わるため、電子署名データだけをプログラムに埋め込んでおくことができません。また、Secret Access と言うくらいなのでこれを公開するのも駄目でしょう。

詳しい情報がまだ得られていないのでなんとも言えませんが、ただ使うだけの人にも開発者登録をしてもらわないと駄目になるかもしれません。

今のところは、たつをさんによる記事が一番詳しそう。

電子署名データの作成には RFC 2104-compliant HMAC with the SHA256 hash algorithm という変換処理のようなものが必要で、これを行うための関数である hash は PHP5 でないと標準では使用できません。PHP4 はすでに終了宣言が出ているのですが、まだ PHP5 が使用できないサーバーもあるので悩みどころです。

Comments (0)

HTML convert time: 0.854 sec. Powered by

Images is enhanced with WordPress Lightbox JS by Zeo