先人 > Amazon Product Advertising APIの認証の件 - zorioの日記
Ruby-1.8.7と Ruby-1.8.6では String#force_encoding("ASCII-8BIT")ができず、String#ordもない(ないのはエンコーディングの概念がないからと、String#[]で代替できるからだと思われる)。それらを使い分けるために 2種類のメソッドを用意するくらいなら、unpackで配列経由でいいです。
require 'digest/sha2'
def hmac_sha256(key, message)
hash = Digest::SHA256
hash_block_size = 64 # bytes (= hash.new.block_length)
key = hash.digest( key ) if hash_block_size < (key.bytesize rescue key.size)
ikey = Array.new( hash_block_size, 0x36 )
okey = Array.new( hash_block_size, 0x5c )
key.unpack("C*").each_with_index{|key_byte, i|
ikey[i] ^= key_byte
okey[i] ^= key_byte
}
inner_hash = hash.new.update( ikey.pack("C*") )
outer_hash = hash.new.update( okey.pack("C*") )
digest = outer_hash.update( inner_hash.update( message ).digest ).digest
return digest
end
短い秘密鍵は 0を補うって書いてあった。その処理が見あたらないのになぜうまくいくのかと考えたら、0を相手に排他的論理和をとったって何も変わらないのねん。
class Digest::Base
- update(str)
- self << str
- 文字列を追加する。self を返す。複数回updateを呼ぶことは文字列を連結してupdateを呼ぶことと等しい。すなわち m.update(a); m.update(b) は m.update(a + b) と、 m << a << b は m << a + b とそれぞれ等価である。
Ruby-1.9で文字列の連結は怖いので m.update(a + b) と m << a + b と Digest::SHA256.digest(ipad + message) は避けたい。
302 Foundはわかる。リバースプロキシは何するもの？
require 'uri'
require 'base64'
def amazon_authenticated_query_string( host, params )
re_rfc3986_unreserved = /[^A-Za-z0-9\-_.~]/
query_string = params.to_a.sort_by{|x| x.first }.map{|key, value|
URI.encode(key, re_rfc3986_unreserved) +'='+ URI.encode(value, re_rfc3986_unreserved)
}.join("&")
string_to_sign = <<-"STRING_TO_SIGN".gsub(/^\t\t/, '').chomp
GET
#{host.downcase}
/onca/xml
#{query_string}
STRING_TO_SIGN
amazon_secret_access_key = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
signature = Base64.encode64( hmac_sha256( amazon_secret_access_key, string_to_sign ) ).chomp
return "#{query_string}&Signature=#{URI.encode(signature, re_rfc3986_unreserved)}"
end
事実と一致するかはおいておいて、Amazonが「デジモノに埋もれる日々」の記事レベルの見解を示していてくれれば抵抗もすくなかったのに。すごく納得できる内容。
既に書かれているけど OpenProxyの注意点は利用規約にも書かれている 1 call per secondの制限を守れるかどうかと、アカウントの停止の危険性だね。Proxy利用者で秘密キーを持ってる人がキーを持ち寄って上限を N call per secondに引き上 げたら……とか考えたけど、それじゃ全然「秘密」キーじゃないわな。
<追記@2009-07-08> DNSラウンドロビンってなんだ、って調べたんじゃなかったか。個人個人がサーバーを立てる、それらを同じ名前で利用する。これで秘密キーとサーバーリソースの両方を持ち寄れる。 </追記>
バイナリファイルでの扱いに関する Amazonの見解。
- コンパイル型言語で秘密キーを暗号化した上で実行用バイナリ内に埋め込んで、実行用バイナリを公開する。ユーザーは自身のPCで実行用バイナリを実行する。
- 実行用バイナリをバイナリエディタで覗いた位では秘密キーは解読できないが、実行用バイナリコードをリバースエンジニアリングされれば秘密キーを得ることも可能な状態。
のいずれのケースについても、理想的な方法とは言えませんが、条件付きで利用可能であるという見解となります。
単純な埋め込みは NG。リバースエンジニアリングにより秘密キーが知られうる場合は、理想的ではないが可。
Amazonは PAAPIのどういう利用を想定しているんだろ。サーバー型のサービスとして？ 個人が個人の責任で呼び出すものとして？ 俺はもう APIを利用してくれるなという Amazonからのメッセージだと受け取っている。(情報が少ないから曲解するんだよ)
ウィッシュリストの作成者はアカウントの名前がデフォルトで使用されるみたいだけど、基本的に名前は漏れようがなかった、と。
ウィッシュリストは、アカウントが管理するアドレス帳とは別に、届け先情報を保持してるみたいだけど、届け先のデフォルトは「お届け先を指定しない」になってたと思う。(検索結果には、登録情報がありません、としか表示されない。最初期はアカウントの住所がデフォルトだったらしい。リンク先を参照)
ウィッシュリストがデフォルトで公開なのはウィッシュリスト画面の冒頭に赤字で長々と「このリストの初期設定は公開になっています。云々」と表示されるようになったとき(最近ではないけど数年前でもないと思う)に気がついて非表示にした。
問題だったのは次の二点だろか。
ウィッシュリストの中の「購入済み」の商品、ってこと？
あぁ・・・
これ「非公開」に設定してもリストに入れた商品が非表示になるだけで本名は表示されるんだなw
アホや・・・・Amazon
http://guideline.livedoor.biz/archives/51048706.html
非公開にするだけではダメみたいやね。
似たような話で、メールマガジンの冒頭で、登録した本名を使って呼びかけてくるものが嫌い。近すぎて気持ち悪いし、特定の相手だけに教えたつもりの情報なのに往来で無造作に喋られてるようで不愉快。> CodeZine_News
* ちなみに、自分の PCを使ってるときはもう何年間も明示的にログインした記憶がない。
Amazon.co.jpの検索画面で [N][N]と二回押すと次のページへ、[P][P]で前のページへ移動する。
Firefoxの Find As You Typeが有効だと効きません。残念。accesskey属性も一緒に設定しておいてくれたら (Firefox+Windowsな環境では) Alt+Shift+N(P)で代替できたのに。おすすめページに付けないのも片手落ちじゃないかなあ。
Amazon一つのために Find As You Typeを無効にするのは不便だし、リンク文字列が「次へ」「戻る」の代わりに「Next」「Prev」に変わることは日本語のサイトとして考えられないので、XUL/Migemoをインストールして「tsugihe」「modoru」と入力したら「次へ」「戻る」にフォーカスがあたるようにしてやろうと考えたが tsugiで「次」、modoで「戻」がヒットするのに heや ruまで入力するとヒットしなくなる。候補を絞る目的で長く入力すると返ってヒットしなくなるのは悩ましい。
あ、XUL/Migemoのクイック検索(XUL/Migemoによる Find As You Type)だと [N][N]や [P][P]が効いてる。honnをページ内で検索したら次のページへ移動した。これを狙って XUL/Migemoをインストールしたのだったのか (日本語あってる？)。
7月23日に書いたことが修正されている。関係のあるところだけ摘む。
The ItemPage limit is now correctly set to 400.
The ItemPage limit is now correctly set to 400 for all search Indices in all locales. Previously, this limit was incorrectly set in some locales and search indices.
The ReleaseDate parameter in ItemSearch requests was not working in the JP locale.
The ReleaseDate parameter enables you to specify a range of dates as search criteria. This parameter is now working correctly.
ちょ、正しくうごくようになったって、ReleaseDateなんてパラメータそもそもどこにドキュメントされてるの。
最新の 2007-07-16版の HTMLヘルプで「ReleaseDate」を検索しても見つからないし、「SearchIndex-ItemSearch Parameter Combinations for JP」(This Search Index Matrix shows you which ItemSearch parameters may be used with each of the available SearchIndex values for the JP locale.)(翻訳ではなく解説：この表は JP localeでの ItemSearchリクエストにおいて SearchIndexに指定した値に応じてどのパラメータが使用可能かをしめしたものです)というページにも載ってない。
日付をもろに指定して取得できるなら、Sort=pubdateで日付順に並べて、欲しい日付を探すなんて回りくどいことをする必要なんてない。
The parameter, pubdate, which is used in ItemSearch Power searches is not working correctly.
This parameter sometimes does not return results for the specified pubdate value when it should.
Do not use ItemSearch power searches that use pubdate.
ItemSearch Power requests do not return accurate results for specific dates.
ItemSearch responses may be incorrect when the request specifies a specific day. Using date ranges returns expected results.
Do not look for specific dates in ItemSearch Power requests.
どゆこと？ それに、日付の範囲の指定の仕方がわかりませんが。
Known Issuesの二点は 2007-07-23より前の 2007-06-14には既に明らかになってた。よく読め>自分といいたいけど APIドキュメント読んでも載ってないんだもの。ReleaseNotesを読まないといけない。
40 ：クリックで救われる名無しさんがいる：2006/12/15(金) 18:23:25 ID:BA+uJkll0
>>38
一回で呼べるのは10個までいける気がする
それ以上なら1秒以上間隔をあける
>>39
BrowseNodeLookupでNewReleases
ttp://developer.amazonwebservices.com/connect/servlet/KbServlet/download/480-102-865/ecs-rl-jp-20061106.htm
ちっとは調べろ・・・
リンク先では
TopSellers および NewReleases の response group が、全てのストアにおいて利用可能になりました。
注： ただし、CartTopSellers および CartNewReleases については、引き続き US のみにおいて使用可能です。
だって。JPでも NewReleases使えるじゃないか。APIドキュメント(ecs-dg-20070827.chm)には未だに「This response group is available in the US locale only.」と書いてあるのに。
543 ：クリックで救われる名無しさんがいる：2007/08/24(金) 16:25:34 ID:6c3thW/60
>>538
Version指定しないとダメ
指定しないと2005-10-05が指定されたことになる
Reviews以下が追加されたのはAPI Ver.2006-10-25以降だから
当然戻ってこない
ちなみに最新は2007-07-16
指定しないと最新だと思ってた。どちらにしろ指定しておくのが無難か。
633 ：クリックで救われる名無しさんがいる：2007/09/02(日) 19:59:38 ID:3hhoE9Y80
>>632
機能追加時にリリースノートで読んだはずなんだけどと思ったが
予想以上に古くて手間取った。
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=161&categoryID=17
の ecs-rl-20060308.pdf
どうもAPI Refにはなさそうだね。
PDFの中身(該当部分)はこう
Now Itemsearch can filter results by release date for the following search indices: Music, DVD, VideoGames. Valid values for the new parameter, ReleaseDate, are of the form: yyyymmdd or yyyymmdd-yyyymmdd, where the second option is a range of release dates.
ReleaseDateパラメータとその書式。これが知りたかった。Music, DVD, VideoGamesでしか使えないというのは知りたくなかった。これ以降のリリースで Booksにも拡張されてないかな。
14日に「新刊のリストが手に入れば自分でフィルタリングするが」と書いたのを受けて、Amazon E-Commerce Serviceの 2007-06-13版のドキュメントを眺めてみた。
特定の BrowseNodeに属するニューリリースを取得することが可能。Booksという BrowseNodeも存在するので、本のニューリリースを取得できる。但し US locale限定。JP localeで使用できるようになれば本命。
検索条件を一つ以上与えないといけないので、BrowseNode=465610 という条件を加える。465610は JP localeで Booksを表す BrowseNodeId。(但し BrowseNodeInfoで得られる、この BrowseNodeIdの Nameは「ジャンル別」となっている。HTML表示のためだろう)
これはまあまあ、Amazonがどれくらいの数のクエリを許してくれるかを度外視した上で、成功した。ドキュメントには ItemPageパラメータは 1-400だと書かれていて、1ページ目の 2009-01発売の本から始まって、400ページ目までいってもまだ 2007-07発売の本が続いてるから、直近の新刊は取得できないかと思ったが、実際には ItemPageパラメータに上限は設けられていないようで、400ページ目以降も問題なく取得できた。
追記 エラーメッセージによると有効な値は 1から3200までだって。実際に 3300ページ目は取得できなかった。
追記:2007-09-10 9月からエラーメッセージでも 1から400までが有効だと言われた。実際に 3200ページ目は取得できなくなっている。ドキュメント通りになってしまった。
但し、この方法で取得できない本があった。BrowseNodeが全ての本に設定されてるわけじゃないものね。この本は「ジャンル別」(BrowseNodeId=465610)ではなく「出版社別」の BrowseNodeにしか属していない。どの BrowseNodeにも属していない本だってあるだろう。
BrowseNodeに依存する案1と案2では漏れがでることがわかった。
これは「author」「ISBN」「keyword」「language」「pubdate」「publisher」「subject」「title」というキーワードと「not」「and」「or」「：」「()」「""」「*」という構文要素からなる複雑な検索が行える。例えば、Power=author:"米澤 穂信" なら著者(Authorや Creator要素。Roleは関係なさそう)に「米澤 穂信」を含む本が取得できる。これで Power=pubdate:2007-07*を検索してやろうというわけだ。
結果は、先のリンクをクリックすればわかるけど「リクエストに該当する結果がありません。」とのつれないお答え。Power=pubdate:2007-07や Power=pubdate:2007-07-23でもダメなところを見ると、ドキュメントでは気付かなかったけど、pubdateキーワードがサポートされてないんじゃなかろうか。(US localeではもちろんサポートされてるだろう)。ガックリ。
コミックは比較的早め(それでも 1〜2週間前)に登録されるが、文庫は前日から数日前が多い。単行本は知らない。 速報性は求められないので、毎日、当日発売の本をチェックするのが妥当。
【続きを読む前に予備知識】 発売日 2007-06-31〜2007-06-01〜2007-06の本が含まれるのは現時点で 5?0から 15?0ページ目までの約1000ページ。
ひと月約1000ページとして 2000ページ目までには今月の刊行物が全て収まってるとする。 特定の日付の始まりか終わりの含まれるページを見つけるのに約11回(log2(2000)≒10.9)のクエリ。 そこから一つずつインクリメント(デクリメント)すること 30回(1000÷31)もあれば次の日付が現れるだろう。
平均して一日あたり 40回程度のクエリで当日発売の本が取得できる。(前述の通り「ジャンル別」の BrowseNodeに属していない本は漏れるが)
発売年月の情報しか持たない本については、どのタイミングで追加されるかわからないので、漏れとクエリを最小にするには、月が変わってから取得する必要がある。月が変わってから……。
Amazonを 25回呼び出して得られたのが以下の23日発売の本たち(といっても半分以上が雑誌だが)。25回の内訳は 2007-07-23が現れる最初のページを見つけるまでに 11回。データ取得に 14回。同じページを重複して取得するのを避けたら 1〜数回は呼び出しを減らせる。ラブやんがきちんと引っ掛かってるので自分的には成功。
これ、毎日起動してもいいのかな……かな？
毎日 01:00前に自動更新。リストは Amazon.co.jp NewReleasesにアップ。
様々な値が入力されている。
自分用のデータをここに入力するときに採用しているルールは、表紙と表紙の内側に貼られた紙を除いた全てのページ(広告なども含む)、というもの。但し、デフォルト値は Amazonから引っ張ってきたデータなのでページ数として表示される全ての数字がこのルールに則ってカウントされたものというわけではない。
Amazonで ISBNと ASINが一致しなくなるのが一番痛い。ASINの桁数を増やしてくれるのが楽なんだけど、Amazonにとっては楽じゃないんだろうなあ。
気になる AWSでの ItemLookup。 従来は [An ASIN]の部分に単に ISBNを入力するだけで本の情報を得ることができた。
http://webservices.amazon.com/onca/xml?Service=AWSECommerceService &AWSAccessKeyId=[Your Access Key ID Here] &Operation=ItemLookup &ItemId=[An ASIN]
これに
&IdType=EAN
というパラメーターを付ければ ItemIdとして ASINの代わりに JANを指定できる。新しい 13桁の ISBNは JANと一致しております。やったね。ただし、
If you select SKU, UPC, or EAN as the IdType for your request, you also need to include the SearchIndex parameter.
(IdTypeに SKU, UPC, EANを選んだら SearchIndexも指定する必要があるよ。)
SearchIndex is required any time you select SKU, UPC, or EAN as the IdType for your request.
(上と同じ内容だけど any time you select EANと書いてあって、よりハッキリ。)
と書かれているので、同時に SearchIndexも指定しなければならない。
Amazon.co.jpで許されてる SearchIndexの値は以下の通り
以上。本がありませんね。
2006-11-14版の ドキュメントによれば JANを使って ItemLookupすることはできないみたい。
https://affiliate.amazon.co.jp/gp/associates/network/help/t4/a7/
転載しちゃって良いかな？
自動化された方法、またはプログラムを組むことによって、13桁のISBNからアソシエイト・リンクを作成することはできますか？
はい、13桁のISBN（以下、新ISBN）への移行後は、Amazon Webサービスの一部である、Amazon E-Commerce Service (ECS) のシステムを利用して、新ISBNをもとにアソシエイト・リンクを生成することが可能になる予定です。Amazon Webサービスでは、現在、ItemLookupの機能を利用して、流通コードであるEANやJANをキーにしたデータ参照が可能であり、この機能に新 ISBNを使用したマッチングを追加する予定です。こちらのサポート開始時期につきましては、E-Commerce Serviceの開発者フォーラム（英語版または日本語版）や、ニュースレターによりご案内しますので、定期的にチェックされることをお勧めします。なお、Amazon Webサービスのご利用には登録が必要です。登録がお済みでない方は、こちらより登録IDを取得してください。
見覚えがあるから一度は読んだはずなのに。
* 2007年からです。知らなかったわけではありませんが、忘れていました。
裏面に注意を要する文言。
本カードは、Amazon.co.jpのアカウントへチャージされない場合、ご購入から6ヶ月後に無効となります。
すぐに買うものがない場合でも、アマゾンにアクセスして「アカウントサービス」->「Amazonギフト券・Amazonショッピングカードの残高を確認する・残高に追加する」と移動してコードを入力しておくのが吉。
15アイテムずつ表示するのは一緒だけど……
以前は「おすすめの理由は」っていうリンクがあるだけだったのに、「〜などを評価されたお客様におすすめします」って、最初から一冊だけだけどおすすめの理由が表示されてる。これはページの移動が減るなあ。
出版日も表示されてる。
マウスオーバーに合わせて「嫌い(☆)」「好きではない(☆☆)」「普通(☆☆☆)」「好き(☆☆☆☆)」「大好き(☆☆☆☆☆)」と表示され、クリックすると評価が送信される。ページ遷移はない。
「持っています」「興味がありません」も従来はハイパーリンクだったものが、ページ遷移無しでアマゾンに送信されるようになっている。
ソースを覗いてみると、Javascriptが使用可能なら
window.location.href="〜"
とやってる。これは普通ページを移動するときに使うけど、そうはならない。からくりは以下のレスポンス。(注: id と名の付くものをそのまま載せるのはまずいかもしれないので正規表現に置換してある)
HTTP/1.x 204 NoContent
Date: Thu, 06 Apr 2006 18:42:18 GMT
Server: Server
x-amz-id-1: [0-9A-Z]{20}
x-amz-id-2: [0-9A-Za-z/=]{44}
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Connection: close
Content-Type: text/html; charset=Shift_JIS
Firefoxは 204 NoContent を受け取ったものだから新しいページを表示できなくて古いページを表示し続けるというわけ。
Javascriptが使用不可ならフォームを使って、(確認してないけど)スクリプトと同じ内容を POSTしてる。レスポンスも同じ 204 NoContentだろう。
評価などを変更しましたか? ここをクリックするとおすすめ商品の情報が更新されます。
というのがページ下部にある。内容は単なる javascript:location.reload() だけど需要のあるリンクだと思う。表示中のページに加えた評価 を加味した最新のおすすめを表示したいと思うもの。
キーボード派は F5を押せばいいと言うでしょうがキーボード派はお呼びでない様子。
「興味がありません」を例にとるとソースはこう↓。丸々スクリプトで中身を出力してる。(スクリプトOFFなブラウザには <noscript><form>〜</form></noscript>が用意してあるので重複して表示しないように。)
<td style="white-space: nowrap;"> <script language="Javascript" type="text/javascript">amz_js_showNotInterested(asin, notInterested);</script> </td>
amz_js_showNotInterested()が何を返すかというと
function amz_js_showNotInterested(asin, notInterested){
var imageID = "notInterested." + asin;
document.write("<img src="+'"'+ + checkboxImages[notInterested] +
+'"'+"");
document.write("onclick="+'"'+"amz_js_sendNotInterested('" + asin + "', 'alt');"+'"'+" ");
document.write("onmouseover="+'"'+"amz_js_notInterestedMouseOver('" + asin + "', 'alt');"+'"'+" ");
document.write("onmouseout="+'"'+"amz_js_notInterestedMouseOut('" + asin + "', 'alt');"+'"'+" ");
document.write("id="+'"'+ + imageID +
+'"'+" ");
document.write("border="+'"'+"0"+'"'+" valign="+'"'+"bottom"+'"'+" />");
}
一つの <img>要素。リンクでないただの画像にフォーカスは移りません。
というわけで、スクリプトが OFFの場合はフォームと画像ボタンが表示されるのでキーボードで操作できるはずだが、スクリプトONの場合はマウス必須。
☆の部分のソースを見ると、☆の画像は一つで、6つの<area>を持つ<map>を適用することで個々の☆のマウスオーバー効果やクリックの処理をしている。評価送信のトリガはハイパーリンクを使ったものではなく <area onClick="〜" />。だから、☆にフォーカスは移るんだけど Enterを押しても反応しない。クリックをエミュレートするキーボードショートカットがあれば何とかなるが。
因みに ☆評価に対応した <noscript> なフォームは用意されてないのでスクリプトオフでは☆自体が表示されないはず。
改行とインデントをいじって HTML要素の内容を省略したソースが以下。
<html>
<head>
<title>Amazon.co.jp: おすすめ商品</title>
<script language="Javascript1.1" type="text/javascript"></script>
<style type="text/css"></style>
<style type="text/css"></style>
<style type="text/css"></style>
</head>
<body>
<html>
<head>
<title></title>
<style type="text/css"></style>
<script language="Javascript1.1" type="text/javascript"></script>
</head>
<body bgcolor="#FFFFFF" link="#003399" alink="#FF9933" vlink="#996633" text="#000000">
……
</body>
</html>
</body>
</html>
よくわからない HTML、ところどころ XHTML風味。何れにしろ Broken みたいなっ。
アマゾンみたいなサイトでは HTMLの理念理想よりブラウザ互換性の方が大事でしょうが、見映えと関係ない細かな部分ではソースの統一をして欲しいな。(<br />なんて <br>でいいでしょ)
これまでは 100件ちょっとで「次のページ」が無くなって打ち止めになったけど、現在 400件目を過ぎたところまで表示してる。ここまでくるとおすすめの精度が悪くて参考にならない。でも自分で止めるところを決められるのは良い。
* Ajaxを XmlHttpRequest, MSXMLオブジェクトを利用した、ページ遷移を伴わないサーバーとの通信(HTTP GET/POST)、(とそれによるページ更新)とするなら