Product Advertising API

amazonがAmazon アソシエイト Webサービスの名称を「Product Advertising API」と変更し、リクエストを送信する都度、認証のための電子署名を要求すると発表したのが、5月前半。期限は8月15日。

Windows Live WriterのAmazon アソシエイトプラグインを公開しているのだが、こいつも影響をうける。動かなくなる。

あ~めんどくせ~、ってんで、記憶のかなたに追いやっていたのだが、もう期限が迫っているのでちょっと調べてみた。

夏休みの宿題は最後にやる方針なので。。。

この発表があったのが、5月8日。同時に、

Dear Amazon Associates Web Service Developer,

Through our Associates Program, we pay out hundreds of millions of dollars per year to websites that advertise our products. Effective immediately, we are renaming the Amazon Associates Web Service as the “Product Advertising API.” This new name more accurately reflects the purpose of the API, which is to enable developers to advertise products offered on the Amazon sites and thereby receive advertising fees from us.

みたいなメールが届いてたんだけど、日本にいたし、遠い記憶。

先日、Amazon アソシエイト Web サービスの名称を、「Product Advertising API」へ変更しましたこと、および Product Advertising API への全てのリクエストに、認証のための電子署名を 2009年8月15日までに含めていただく必要があることにつき、ご案内させていただきました。

弊社による調査では、お客様の AWSAccessKeyID から送信されているリクエストには、未だ電子署名が含まれていないことが判明しています。

7月19日には、こんな警告まで届いてました。さて今日は、あわてて調べもの。

Amazon アソシエイトプラグインでは、Access Keyをプログラム中に埋めこんでいる。このAccess KeyをSOAPリクエストにくっつけている。さて、認証が必要になると、Secret Access Keyも埋め込まなければならない。

アマゾンアソシエイト挿入プラグイン for Windows Live Writer 作成中

に

6) 他の開発者やユーザーが利用できるようなソフトウェアを開発した場合、自分の登録IDを埋め込むべきですか、それともそれぞれのユーザーが登録IDを指定できるようにすべきですか？
必ずしも他のユーザーが登録IDを指定できるようにする必要はありません。むしろ、そのソフトウェアの利用状況を計測できるように、登録IDは固定しておいたほうがいいでしょう。

ってあったんだけど、あれは何やったんや？

Amazon.co.jp Product Advertising API ライセンス契約
https://affiliate.amazon.co.jp/gp/advertising/api/detail/agreement.html

秘密キーであるアカウント識別子またはパスワードであるデータフィードアクセスID は、お客様個人の利用のためものであり、お客様は、お客様の秘密キーの秘密性およびセキュリティの管理をしなければなりません。お客様は、お客様の秘密キーまたはパスワードを、他の個人または事業体に販売、譲渡、サブライセンスまたは公開してはいけません。

プログラム内にSecret Access Keyを埋め込むことが可能かどうか。

Amazon Web Services Developer Community : 秘密キーまたはパスワードの「公開」の範囲 …

Re: 秘密キーまたはパスワードの「公開」の範囲について
Posted: Jun 22, 2009 5:52 PM PDT in response to: Saitou Daisuke(E)
お待たせいたしました。開発チームからの見解が出ましたので、お伝えします。
今までにお問い合わせいただきました、
・コンパイル型言語で秘密キー等を実行用バイナリ内に埋め込んで、
実行用バイナリを公開する。
ユーザーは自身のPCで実行用バイナリを実行する。
・インタープリタ型言語で秘密キー等をソースコードに埋め込み、実行形式としてパッケージ化し、
パッケージの開梱禁止を利用条件として、実行プログラムとしてパッケージを公開する。
ユーザーは自身のPCで実行用プログラムを実行する。
提供者の意図しない方法でパッケージを開梱した場合、秘密キーを参照できる状態。
・ http://www5.plala.or.jp/visage/download.html および
http://nagaokastation.com/?p=330
において配布されているような形式
・コンパイル型言語で秘密キーを暗号化した上で実行用バイナリ内に埋め込んで、実行用バイナリを公開する。ユーザーは自身のPCで実行用バイナリを実行する。
実行用バイナリをバイナリエディタで覗いた位では秘密キーは解読できないが、実行用バイナリコードをリバースエンジニアリングされれば秘密キーを得ることも可能な状態。
のいずれのケースについても、理想的な方法とは言えませんが、条件付きで利用可能であるという見解となります。
上記の実装を行っていただくにあたっての条件は以下の通りです。
1) すでにご質問においても提起されていますが、ユーザが何らかの方法を利用して秘密キーを参照・悪用するような事態が発生した場合に、速やかに秘密キーを変更（AWSアカウントページで随時変更可能です）いただくこと。。
2) 秘密キー変更後、速やかに新しい秘密キーを含んだ新しいアプリを既存ユーザに配布できるようご手配いただくこと。
もし、hack行為によってお持ちのIDが不正利用されているにもかかわらず、秘密キーの変更が速やかに行われなかった場合、Product Advertising APIチームによってアカウントがロックまたは停止され、このIDを利用したアプリが一切動作しなくなる危険性がありますのでご注意ください。
以上、ご不明な点、ご懸念などありましたらおたずねください。
よろしくお願いいたします。

ということで、秘密キーが、参照悪用されるような事態が発生した場合に、すぐに変更しちゃってもかまわなければOKの模様。でも、理想的な方法とは言えませんが、条件付きで利用可能であるとあるので、びみょ~

では、埋めこまないとした場合、どんな手がとれるか。

プロキシをつくること。

ということで、調べてみる。

Amazon Web Services Developer Community : Re: OSSからの認証利用について

Re: OSSからの認証利用について

Posted: Jun 17,
2009 11:57 PM PDT in response to: tdtds

ご返信ありがとうございます。また、代替策についてご検討くださり、ありがとうございます。
ご提案いただいている
アプリ –(ASIN)→ PROXY –(ASIN+秘密キー)→ Amazon
の方法でしたら、ライセンス上問題となりませんので、対応につきご検討いただけますと幸いです。
改めまして、今回の変更では開発者の皆様、ならびにアプリユーザの皆様にはお手数をおかけいたしますが、引き続きよろしくお願いいたします。

ただのにっき様のAmazon API認証のPROXYを書いたよ(AmazonのAPI認証導入はOSSに対する挑戦だよなぁ(4))経由の情報です。

これもOK。ちうか、これはさすがにOKだよな。

で、探せば、でるわでるわ、いろんな実装がいっぱい。

Ruby : Amazon API認証のPROXYを書いたよ(2)

Python : 俺も Amazon の Proxy を Google App Engine で作ってみた

Perl : Ajax – AWS Caching Proxy w/ Authentication Support

Perl : Perl による自分用 Amazon Product Advertising API proxy「PAPAXY」

Apacheモジュール： Apache モジュール版の Amazon API 認証プロキシを作ったよ

などなど。もっといっぱいでてくる。

一番おもしろいのが、