Wordpress の API で BASIC 認証を使う

WordpressAPI を使用するにあたり、いくつかの機能では認証が必要になります。
認証の方法にはいくつかありますが、高いセキュリティが求められていない場合は簡単な方法にしたいところです。
サポートされている認証の1つに BASIC認証(Basic Authentication) がありますので、これを使用する際のポイントをまとめておきたいと思います。

プラグインの導入が必要

BASIC認証を使用するためには、プラグインの導入が必要です。といっても大仰なプラグインを導入する必要はなく、 https://github.com/WP-API/Basic-Auth から basic-auth.php をダウンロードして、wp-content/plugins ディレクトリに配置するだけです。
配置したあと、有効化するのを忘れないようにしましょう。

.htaccess の修正が必要な場合がある

ここがハマるポイントだと思います。
上記のプラグインでは、$SERVER['PHP_AUTH_USER'] と $SERVER['PHP_AUTH_PW'] を参照して、BASIC認証のユーザとパスワードを取得しています。
しかし Apache を採用しているレンタルサーバ等では、デフォルトではこれらの値を取得することができない場合があります。
その場合は .htaccess に以下のような設定を追加する必要があります。

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule ^(.*) - [E=HTTP_AUTHORIZATION:%1]

ポイントは、Wordpress が自動的に生成するリライトルールの前に書くという点です。
これを Wordpress が自動的に生成するリライトルールの後に書いた場合、正常に動作しません。


これで、BASIC認証による API の認証ができるはずです。
どうしても 403 Forbidden になってしまう場合は、以下を確認するとよいでしょう。

  • クライアント側からちゃんと BASIC 認証のヘッダが送信されているか
  • Wordpress 側で PHP_AUTH_USER / PHP_AUTH_PW が取得できているか

WAF や SSL などの目的のために設置されたリバースプロキシによって、うまく情報が渡っていないケースも考えられます。

動作検証などで「何でもいいからとにかく動かしたいんだ!」という場合には、basic-auth.php をいじってしまうという手もあります。
結局は、渡ってきたユーザ/パスワードで Wordpress の内部的な認証をかけているだけなので、basic-auth.php の以下の部分で $username と $password に任意のユーザとパスワードを与えれば、認証は通るようになります。

$user = wp_authenticate( $username, $password );



Wordpress の API を利用する

Webサイトの構築に Wordpress を利用することが多くなっています。
最近のバージョンの Wordpress では標準で REST API が使用できるため、これを自動化やシステム連携に活かさない手はありません。

API には、認証が必要なものと不要なものがあります。例えば投稿の一覧を取得する場合、/wp-json/wp/v2/posts にアクセスするだけで取得することができます。 以下は、公式のデモサイト http://demo.wp-api.org/wp-json/wp/v2/posts のレスポンスです。

f:id:venturenet:20180413182213p:plain

API のレスポンスはすべて JSON 形式です。

公開されている記事や固定ページ、カテゴリの取得など、公開されている系の情報を取得するAPIは認証なしで利用することができます。
記事を投稿するなど、通常 Wordpress にログインしていなければできない操作系のAPIでは、認証が必要になります。
認証には、こちら にあるようにいくつかの方式がありますので、いずれかを選択する必要があります。

なお、バージョンによりエンドポイントやインタフェースが異なることがあるため、公式のドキュメントをチェックするようにしたいところです。
https://ja.wp-api.org/ ← 日本語
https://developer.wordpress.org/rest-api/ ← 英語ですが、情報がフレッシュ

Salesforce データローダのメモ

このブログでは、技術的な事柄を備忘録として残していきます。
記念すべき1つ目は、Salesforce のデータローダに関するメモです。最近業務でデータインポートする機会がありましたので、そのときに発生したエラーや気付きを残します。
※データローダのバージョンは42

インポートデータが UTF-8 の場合は、BOMを外す

インポートデータが UTF-8CSV の場合、BOM が付いていると読み込めません。
なお ExcelUTF-8CSV を開くときには、逆に BOM が付いていないと読み込めません。(少なくとも Excel 2010 では)

インポートデータが CSV の場合は、ダブルクォーテーションでデータを囲む

インポートデータが UTF-8CSV の場合、内容によるのか必ずそうなのかは不明ですが、ダブルクォーテーションでデータが囲まれていないと、読み込みでエラーが発生します。 追記:やはり必ずしもエラーになるわけではありませんでした。ダブルクォーテーションで囲む、囲まないは統一した方が良さそうです。

作成日と最終更新日をセットするには特別な権限が必要

データの移行では、レコードの作成日と最終更新日を設定したいこともありますが、デフォルトではこれらの項目に値を設定することはできません。
システム権限「レコードの作成時に監査項目を設定」が必要になります。
参考:https://help.salesforce.com/articleView?id=000213290&language=ja&type=1

作成日が最終更新日より後だとエラー

当たり前といえば当たり前ですが、作成日が最終更新日より後だと、FIELD_INTEGRITY_EXCEPTION:Last Modified Date ~ というエラーが発生します。 移行元が古いシステムだったり、いいかげんなデータの持ち方をしているシステムだったりすると、必ずしも日時データの整合性の取れた状態になっていないこともありますので、注意が必要です。

DELETE なのに「値を入力してください」エラー

インポートに限った話ではありませんが、DELETE しているのにも関わらず「値を入力してください」というエラーが出ることがあります。
INSERT/UPDATE しているわけでもないのに、と 一瞬混乱してしまいますが、このようなときは、親オブジェクトの必須項目が空になっていないか確認するとよいかもしれません。

  1. 親オブジェクトINSERT ※このときは項目Aは必須でなく空を設定
  2. 子オブジェクトINSERT
  3. 親オブジェクトの項目Aが必須化
  4. 子オブジェクトDELETE → そのレコードの親の項目Aが空だとエラー


マッピングファイルは作っておいた方が便利

インポート対象が多い場合、リレーションが複雑な場合は、マッピングファイル(*sdl)を作っておいた方が便利です。

Invalid session id エラー

データローダの画面を開いたまましばらく放置して、そのあとにインポートしようとすると、Invalid session id というエラーダイアログが表示される場合があります。
タイムアウトしているだけなので、一度ログアウトしてから再度インポートすればOKです。

UNABLE_TO_LOCK_ROW エラー

インポート対象が多く、思わず複数台で並列にインポートを実施したところ、 UNABLE_TO_LOCK_ROW というエラーが頻発しました。 関連のあるオブジェクトでは並列のインポートは行なわない方が無難かもしれません。