さて、最終的に、OAuth 認証ヘッダを作成して、Bot として動作できそうなところに来ました。
実は、私が管理しているのは、「節気さんシリーズ」といいまして、単純に生成したメッセージを（とりあえず、メッセージを生成するまでの過程はそれなりに複雑）単純にポストするだけのものです。
ですから、Twitter へのリクエストは、POST http://api.twitter.com/1/statuses/update.xml のみです。（一応レスポンスのコードはチェックしていますが）
まず、非常におおざっぱに言いますと、Basic 認証であろうと、OAuth 認証であろうと、送信するヘッダ、ボディはほとんど同じです。
Authorization: Basic （Basic 認証ヘッダ）が
Authorization: OAuth （OAuth 認証ヘッダ）に変わるだけです。
というわけで、OAuth 認証ヘッダを生成できれば、Botとして動作可能というわけです。
----------- OAuth 認証ヘッダ作成プログラム -----------------
こんなのを作りました。
ヘッダファイル ： create_oauth.h : http://www.axis.blue/tec/create_oauth.h
ソースファイル ： create_oauth.cpp : http://www.axis.blue/tec/create_oauth.cpp
※上記のソースの中で、
#include <system.hpp>
#include <Classes.hpp>
の２行と、
void makeNonce() にある、 AnsiString time = Now().FormatString("yyyy/mm/dd-hh:nn:ss");
int UnixTime(TDateTime aTime) や、void makeTimeStamp() にある、Now() や、TDateTime 型は、Turbo C++ の処理系に依存しています。
別の処理系では、
AnsiString time = Now().FormatString("yyyy/mm/dd-hh:nn:ss");
は、単純に、time = "aaajajajajaja"; // ランダムな文字
とかで良いはずです。
時刻系のものは、なんとか、Unix Time を算出してください。（Visua C++ なら、CTime が使える気がします。
さらに、AnsiString も、処理系依存です。
こちらは、ほぼ、std::string で書き直せると思います。
これが、OAuth 認証ヘッダの生成に使うソースになります。
------------- 具体的にポスト ----------------------------
まず、単純に、abcd という文字をポストすることにします。
ボディは、 status=abcd です。
また、基本情報として、
OAuthDataDef mine =
{
"My_API_Name", // これは実際には使いません
"my_Consumer_key", // 実際には、入手した Consumer_key 以下同じ
"my_Consumer_secret",
"my_Access_Token",
"my_Access_Token_Secret"
};
と元になるキーを定義しておきます。
また、Body は、
char *body = "status=abcd";
とでもしておきます。
さて、このあと、
makeNonce(); // Nonce の生成
makeTimeStamp(); // timestamp の生成
AnsiString key = mine.Consumer_secret;
key += "&";
key += mine.Access_Token_Secret;
// ここまで、HMAC-SHA1 の鍵生成
AnsiString baseString = makeBaseString(mine, body);
// Base string を生成して
makeSignHere(baseString, key);
// シグネチャーを作って、
AnsiString oauthHeadder = makeHeadder(mine, body);
// OAuth 認証ヘッダを生成
となります。
create_oauth の内部構造が整理できていないので、呼び出しはこの順番でなければなりません。
※例によって、AnsiString は、処理系依存です。これも、std::string で置き換えられると思います。
ここまでで、OAuth ヘッダが生成できました。あとは、これを送信するだけです。
すでに、コネクションが成立したという前提で、（さらに、server->SendTo() でテキストが送信できるという前提で）
まず、"Content-Length: を生成します。
const char * CRLF = "\x0d\x0a";
AnsiString lenHeader = "Content-Length: ";
lenHeader += std::strlen(body);
lenHeader += CRLF;
で、
server->SendText("POST http://api.twitter.com/1/statuses/update.xml HTTP/1.1" CRLF);
server->SendText("Host: api.twitter.com" CRLF);
server->SendText("Content-type: application/x-www-form-urlencoded" CRLF);
oauthHeadder += CRLF;
server->SendText(oauthHeadder);
server->SendText(lenHeader);
server->SendText(CRLF);
server->SendText(line);
server->SendText(CRLF);
となります。
あとは、レスポンスを待つことになります。
【補足】
上記の例では、単純化するため、送信テキストを、"abcd" にしました。
しかし実際には、日本語を送信することが多いでしょう。
たとえば、
status=おはよう
であれば、UTF-8 で、URLエンコードしますから、実際に送るテキストは、
status=%E3%81%8A%E3%81%AF%E3%82%88%E3%81%86
になります。
シグネチャーを作成するための Base Text では、ここからさらに ERL エンコードされるので、Base Text の中では、
status%3D%25E3%2581%258A%25E3%2581%25AF%25E3%2582%2588%25E3%2581%2586
となります。
このあたり、最初ちょっと気がつきませんでした。
2010年05月16日
OAuth への道 ―― Bot にとって、OAuth とは何だったのか？
OAuth については、種々解説もありますが、もともと、OAuth という考え方は、「いかに安全に第三者に自分のアカウントへのアクセスを許すか」という点を重視したものです。
ですから、実際のところ、「ユーザーの許可をどう得るか」という点に、多くの機能があてられています。
一方で、Twitter の Bot は、自作のものである限り、Bot の作者も、Bot のアカウントの管理者も同一だと考えて良いでしょう。つあり、はじめから、「ユーザー（この場合は、Bot のアカウント）の許可」はとれているということになります。
そのため、「Twitter で Bot として振る舞う」だけであれば、一般的な OAuth の解説のうち、かなりの部分を省略できます。
【OAuth の「一般的な」手順】
OAuth の解説の中で、一般的な手順は、たとえばこのように書かれています。
（ APIアクセス権を委譲するプロトコル、OAuthを知る http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth02.html より、記述はかなり省略してあります）
１．コンシューマ登録
（1） コンシューマは、APIを通じたユーザーリソースの利用者としてサービスプロバイダへ登録を要求する。
（2） サービスプロバイダは、「コンシューマ・シークレット」をコンシューマに発行する。
２．リクエスト・トークン要求とユーザーの同意確認
（1） ユーザーはコンシューマのサービスを利用するために、Webブラウザでコンシューマにアクセスする。
（2） コンシューマはサービスプロバイダに接続して「リクエスト・トークン」の発行を要求する。
（3） サービスプロバイダは未承認の（Unauthorized）リクエスト・トークンをコンシューマに返す。
（4） コンシューマは、リクエスト・トークンにユーザーの承認を取るために、をサービスプロバイダにリダイレクトする。
（5） サービスプロバイダはユーザーにコンシューマがアクセスするユーザーリソースの内容と条件を表示し、同意の確認を促す。
（6） ユーザーの同意が取れたら、リクエスト・トークンを「承認（Authorized）」にして、コンシューマへリダイレクトして返す。
３．アクセス・トークン要求とAPI接続
（1） コンシューマは「アクセス・トークン」の発行を要求する。
（2） サービスプロバイダはアクセス・トークンと「トークン・シークレット」をコンシューマに返す。
（3） コンシューマはAPIに接続を要求する。
（4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。
これをすべてこなすのはかなり大変です。
【Twittter の Bot として振る舞う際に、最低限必要な手順】
１．コンシューマ登録
（1） コンシューマは、APIを通じたユーザーリソースの利用者としてサービスプロバイダへ登録を要求する。
（2） サービスプロバイダは、「コンシューマ・シークレット」をコンシューマに発行する。
３．アクセス・トークン要求とAPI接続
（1） コンシューマは「アクセス・トークン」の発行を要求する。
（2） サービスプロバイダはアクセス・トークンと「トークン・シークレット」をコンシューマに返す。
（3） コンシューマはAPIに接続を要求する。
（4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。
以上です。２．項が丸ごと抜けてしまいました。
これでもちょっと大変……という気がしますが、実運用は（Bot に限定すれば）それほどでもありません。
既に書きましたが、
（Bot 用、Access Token、Access Token Secret 入手法 http://asano-nagi.sblo.jp/article/37853895.html ）
Twitter にログインした状態で、簡単に入手できるわけです。
これをふまえてさらに書き換えると
【Twitter の Bot として振る舞う際に、最低限必要な手順 ―― Twitter にログインして】
１．準備
（１）コンシューマ登録をし、Consumer key, Consumer secret を取得する （上記「入手方法」の１．〜５．）
（２）その後、My Account Toke をクリックして、Access Token と、Access Token Secret を取得する。
（上記「入手方法」の６．〜８．）
２．Bot として動作するとき
（１）OAuth 認証ヘッダを作成する。
（２）それを使って認証を行う。
以上に集約できます。
OAuth 認証ヘッダについては、次の機会に。
ですから、実際のところ、「ユーザーの許可をどう得るか」という点に、多くの機能があてられています。
一方で、Twitter の Bot は、自作のものである限り、Bot の作者も、Bot のアカウントの管理者も同一だと考えて良いでしょう。つあり、はじめから、「ユーザー（この場合は、Bot のアカウント）の許可」はとれているということになります。
そのため、「Twitter で Bot として振る舞う」だけであれば、一般的な OAuth の解説のうち、かなりの部分を省略できます。
【OAuth の「一般的な」手順】
OAuth の解説の中で、一般的な手順は、たとえばこのように書かれています。
（ APIアクセス権を委譲するプロトコル、OAuthを知る http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth02.html より、記述はかなり省略してあります）
１．コンシューマ登録
（1） コンシューマは、APIを通じたユーザーリソースの利用者としてサービスプロバイダへ登録を要求する。
（2） サービスプロバイダは、「コンシューマ・シークレット」をコンシューマに発行する。
２．リクエスト・トークン要求とユーザーの同意確認
（1） ユーザーはコンシューマのサービスを利用するために、Webブラウザでコンシューマにアクセスする。
（2） コンシューマはサービスプロバイダに接続して「リクエスト・トークン」の発行を要求する。
（3） サービスプロバイダは未承認の（Unauthorized）リクエスト・トークンをコンシューマに返す。
（4） コンシューマは、リクエスト・トークンにユーザーの承認を取るために、をサービスプロバイダにリダイレクトする。
（5） サービスプロバイダはユーザーにコンシューマがアクセスするユーザーリソースの内容と条件を表示し、同意の確認を促す。
（6） ユーザーの同意が取れたら、リクエスト・トークンを「承認（Authorized）」にして、コンシューマへリダイレクトして返す。
３．アクセス・トークン要求とAPI接続
（1） コンシューマは「アクセス・トークン」の発行を要求する。
（2） サービスプロバイダはアクセス・トークンと「トークン・シークレット」をコンシューマに返す。
（3） コンシューマはAPIに接続を要求する。
（4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。
これをすべてこなすのはかなり大変です。
【Twittter の Bot として振る舞う際に、最低限必要な手順】
１．コンシューマ登録
（1） コンシューマは、APIを通じたユーザーリソースの利用者としてサービスプロバイダへ登録を要求する。
（2） サービスプロバイダは、「コンシューマ・シークレット」をコンシューマに発行する。
３．アクセス・トークン要求とAPI接続
（1） コンシューマは「アクセス・トークン」の発行を要求する。
（2） サービスプロバイダはアクセス・トークンと「トークン・シークレット」をコンシューマに返す。
（3） コンシューマはAPIに接続を要求する。
（4） サービスプロバイダはそれぞれのパラメータの値を確認し、問題がなければ、APIの応答データをコンシューマに返す。
以上です。２．項が丸ごと抜けてしまいました。
これでもちょっと大変……という気がしますが、実運用は（Bot に限定すれば）それほどでもありません。
既に書きましたが、
（Bot 用、Access Token、Access Token Secret 入手法 http://asano-nagi.sblo.jp/article/37853895.html ）
Twitter にログインした状態で、簡単に入手できるわけです。
これをふまえてさらに書き換えると
【Twitter の Bot として振る舞う際に、最低限必要な手順 ―― Twitter にログインして】
１．準備
（１）コンシューマ登録をし、Consumer key, Consumer secret を取得する （上記「入手方法」の１．〜５．）
（２）その後、My Account Toke をクリックして、Access Token と、Access Token Secret を取得する。
（上記「入手方法」の６．〜８．）
２．Bot として動作するとき
（１）OAuth 認証ヘッダを作成する。
（２）それを使って認証を行う。
以上に集約できます。
OAuth 認証ヘッダについては、次の機会に。
2010年05月15日
OAuth への道 ―― OAuth はなぜ安全なのか
さて、OAuth の具体的な対応方法は一時お休みして、そもそも、OAuth 認証というのが、Basic 認証に比べてなぜ安全なのか、とう安全なのかを書いてみようと思います。
一般的な解説記事などによれば、OAuth が安全なのは、「ユーザーのIDとパスワードを使わないから」といわれています。
確かにこの通りではあるのですが、OAuth では、その代わりに、Consumer key, Consumer secret, Access Token, Access Token Secret という４つの鍵を使用します。
そして、確かに、（ボットがそうするように）このキーを使って、ユーザーのかわりに様々な操作をすることができます。
さて、IDとパスワードなら危険で、同じように様々な操作をすることができる、４つの鍵なら安全だというのはどういうことでしょうか？
まず、何をもって「安全」とするかを考えなければなりません。
たとえば、従来の Basic 認証ならユーザーに成り代わっていろいろなことができるけど、OAuth 認証ではできることが限られるというわけではありません（ただし、実際には、「できることを制限する」という機能はあります）
また、一時話題になった、ダイレクトメッセージの機能を使って、SPMA のような拡散をさせるというものがありましたが、これも、OAuth 認証の元で動いていました。
ですから、ユーザーが、「承認した」状態では、機能的にはどちらであっても同じことできてしまいます。
では、何が「安全」なのでしょうか？ それは
・ユーザーがいつでも（自分のパスワードを変更しなくても）承認を取り消すことができる。
・ユーザーがいつでも自分の都合でパスワードを変更できる。
・OAuth 認証では、ホストに送信される情報が盗まれても、それが流用できない（Basic 認証だとこれができてしまいます）
という点になります。
【ユーザーはいつでも承認を取り消すことができる】
従来のBasic認証では、それが、Twitter クライアントであっても、つぶやきの転送のようなものであっても、IDとパスワードを、連絡しなければなりません。（または、設定しなければなりません）
逆に言えば、何かのサービスを「もう使いたくない」として、絶対に使われないようにしようと思えば、パスワードを変更するという方法しかありませんでした。
新しいパスワードを知らない、クライアントなりサービスなりは、それ以降ユーザーのアカウントにアクセスできなくなります。
しかし、言い換えれば、そのほかの「まだ使いたい」サービスなどに対しても、パスワードを変更したと連絡する必要があるということです。
これに対して、OAuth 認証の枠組みでは、特定のサービスの「承認を取り消す」ことで、それ以降アクセスを禁止することができます。
【ユーザーはいつでも自分のパスワードを変更できる】
これは、前項とは逆の状況です。
たとえば、安全のために定期的にパスワードを変更する。または、パスワードが漏れたらしいので、変更する。
これも、従来の Basic 認証の枠組みでは、自分が使っているクライアントやサービスの事情をいちいち気にしなければなりません。
これに対して、OAuth 認証の枠組みでは、ユーザー以外のサービスはパスワードを使いませんから、いつでもパスワードを変更することができます。
【ホストに送信される情報が流用できない】
実は、「安全」という観点ではこれが一番重要なポイントです。
まず、インターネットでは、「暗号化」がなされていない限り、ホストに送信される情報は（受ける情報も）盗まれる可能性があるというのが前提となります。
ですから、Basic 認証であろうと、OAuth 認証であろうと、ホストに送信される「ユーザーのアカウントにアクセスするための情報」は、盗まれる可能性があります。
ただ、「盗まれた」情報が流用できるかどうかで、Basic 認証と、OAuth 認証の安全性に差が出ているわけです。
Basic 認証では、ホストに送信されるユーザー情報は、ユーザーのIDとパスワードから生成されるもので、いつでも同じものです。
つまり、一度盗まれてしまえば、何度でも（ユーザーが気づいてパスワードを変更するまで）利用できてしまいます。
これが、Basic 認証におけるセキュリティ上の問題点とされていたわけです。
一方で、OAuth 認証において、ホストに送信されるユーザー情報は、「アクセスの度に変化」します。
このため、ユーザー情報が盗まれたとしても、その情報は、２度と使えないという仕掛けになっています。
その仕掛けについて、少々書いてみましょう。
OAuth では、ホストに送信されるユーザー情報は、
「Consumer key」「Access Token」「付加情報」「署名」
です。
ここで注意したいのは、先に紹介した４つの鍵のうち、２つの鍵しか送信しないということです。
つまり、送信する情報が丸ごと盗まれたとしても、まだ、２つの鍵については秘密が守られるということです。
また、「付加情報」には、「Timestamp = 送信時刻」と「nonce = ランダムな文字列」が含まれます。
送信時刻が含まれるため、このTimestamp とかけ離れた（実際には、５分を超えたずれのある）時刻に受け取られたものは、ホストから拒否されます。
まず、盗んだ情報を元に、毎日アクセスするなどということはできないわけです。
さらに、「ランダムな文字列」というのは、単に、ランダムなだけではなく、「送信の度に異なる」ものでなければなりません。
送信時刻は、５分までのずれが許されました。といって、盗んだ情報をすぐに使おうとしても、今度は、「nonce = ランダムな文字列」として、「同じものが送信された」ということで、やはり、ホスト側から拒否されます。
したがって、もしも、この情報を盗んだとしても、２度とつかない情報だというわけです。
最後に、「署名」です。
この署名は、送信する、「Consumer key」「Access Token」「付加情報」の部分を、「鍵」を使って行います。
処理の内容は省略しますが、つまりは、署名に使う「鍵」を知っている人でないと署名を作成できないというものです。
さて、この、「鍵」になるのが、残った、Consumer secret, Access Token Secret の２つです。
つまり、この鍵を知らなければ、署名が作成できません。
前述の通り、「全く同じユーザー情報は２度と使えない」「異なる情報を作ろうとすれば、secret という名前のついた鍵が必要」「しかも、secret という名前のついた鍵は、ホストに送信されることがない」ということで、情報が盗まれたとしても安全だという仕掛けです。
【最後に――全部の鍵が盗まれたら】
以上のことを踏まえると、Consumer key, Consumer secret, Access Token, Access Token Secret が揃っていれば、不正アクセスでもできてしまうということになります。
一応、Consumer secret, Access Token Secret は盗まれることがない仕掛けになっているのですが、パソコンを丸ごと盗まれるとか、いろいろあるかもしれません。
実は、その場合でも、気づけば（というか、本当は、盗まれたことに気づくということが最も重要）アプリケーションの作者は、Consumer key, Consumer secret を変更できます。この時点で、盗まれた、Consumer key, Consumer secret は、無効になってしまいます。
しかも、Access Token, Access Token Secret も、「このアプリケーション専用」なので、他のアプリケーションから、盗んできた Access Token, Access Token Secret をもとに不正アクセスするということもできません。
このようなわけで、少なくとも、被害拡大は防げるようになっているわけです。
一般的な解説記事などによれば、OAuth が安全なのは、「ユーザーのIDとパスワードを使わないから」といわれています。
確かにこの通りではあるのですが、OAuth では、その代わりに、Consumer key, Consumer secret, Access Token, Access Token Secret という４つの鍵を使用します。
そして、確かに、（ボットがそうするように）このキーを使って、ユーザーのかわりに様々な操作をすることができます。
さて、IDとパスワードなら危険で、同じように様々な操作をすることができる、４つの鍵なら安全だというのはどういうことでしょうか？
まず、何をもって「安全」とするかを考えなければなりません。
たとえば、従来の Basic 認証ならユーザーに成り代わっていろいろなことができるけど、OAuth 認証ではできることが限られるというわけではありません（ただし、実際には、「できることを制限する」という機能はあります）
また、一時話題になった、ダイレクトメッセージの機能を使って、SPMA のような拡散をさせるというものがありましたが、これも、OAuth 認証の元で動いていました。
ですから、ユーザーが、「承認した」状態では、機能的にはどちらであっても同じことできてしまいます。
では、何が「安全」なのでしょうか？ それは
・ユーザーがいつでも（自分のパスワードを変更しなくても）承認を取り消すことができる。
・ユーザーがいつでも自分の都合でパスワードを変更できる。
・OAuth 認証では、ホストに送信される情報が盗まれても、それが流用できない（Basic 認証だとこれができてしまいます）
という点になります。
【ユーザーはいつでも承認を取り消すことができる】
従来のBasic認証では、それが、Twitter クライアントであっても、つぶやきの転送のようなものであっても、IDとパスワードを、連絡しなければなりません。（または、設定しなければなりません）
逆に言えば、何かのサービスを「もう使いたくない」として、絶対に使われないようにしようと思えば、パスワードを変更するという方法しかありませんでした。
新しいパスワードを知らない、クライアントなりサービスなりは、それ以降ユーザーのアカウントにアクセスできなくなります。
しかし、言い換えれば、そのほかの「まだ使いたい」サービスなどに対しても、パスワードを変更したと連絡する必要があるということです。
これに対して、OAuth 認証の枠組みでは、特定のサービスの「承認を取り消す」ことで、それ以降アクセスを禁止することができます。
【ユーザーはいつでも自分のパスワードを変更できる】
これは、前項とは逆の状況です。
たとえば、安全のために定期的にパスワードを変更する。または、パスワードが漏れたらしいので、変更する。
これも、従来の Basic 認証の枠組みでは、自分が使っているクライアントやサービスの事情をいちいち気にしなければなりません。
これに対して、OAuth 認証の枠組みでは、ユーザー以外のサービスはパスワードを使いませんから、いつでもパスワードを変更することができます。
【ホストに送信される情報が流用できない】
実は、「安全」という観点ではこれが一番重要なポイントです。
まず、インターネットでは、「暗号化」がなされていない限り、ホストに送信される情報は（受ける情報も）盗まれる可能性があるというのが前提となります。
ですから、Basic 認証であろうと、OAuth 認証であろうと、ホストに送信される「ユーザーのアカウントにアクセスするための情報」は、盗まれる可能性があります。
ただ、「盗まれた」情報が流用できるかどうかで、Basic 認証と、OAuth 認証の安全性に差が出ているわけです。
Basic 認証では、ホストに送信されるユーザー情報は、ユーザーのIDとパスワードから生成されるもので、いつでも同じものです。
つまり、一度盗まれてしまえば、何度でも（ユーザーが気づいてパスワードを変更するまで）利用できてしまいます。
これが、Basic 認証におけるセキュリティ上の問題点とされていたわけです。
一方で、OAuth 認証において、ホストに送信されるユーザー情報は、「アクセスの度に変化」します。
このため、ユーザー情報が盗まれたとしても、その情報は、２度と使えないという仕掛けになっています。
その仕掛けについて、少々書いてみましょう。
OAuth では、ホストに送信されるユーザー情報は、
「Consumer key」「Access Token」「付加情報」「署名」
です。
ここで注意したいのは、先に紹介した４つの鍵のうち、２つの鍵しか送信しないということです。
つまり、送信する情報が丸ごと盗まれたとしても、まだ、２つの鍵については秘密が守られるということです。
また、「付加情報」には、「Timestamp = 送信時刻」と「nonce = ランダムな文字列」が含まれます。
送信時刻が含まれるため、このTimestamp とかけ離れた（実際には、５分を超えたずれのある）時刻に受け取られたものは、ホストから拒否されます。
まず、盗んだ情報を元に、毎日アクセスするなどということはできないわけです。
さらに、「ランダムな文字列」というのは、単に、ランダムなだけではなく、「送信の度に異なる」ものでなければなりません。
送信時刻は、５分までのずれが許されました。といって、盗んだ情報をすぐに使おうとしても、今度は、「nonce = ランダムな文字列」として、「同じものが送信された」ということで、やはり、ホスト側から拒否されます。
したがって、もしも、この情報を盗んだとしても、２度とつかない情報だというわけです。
最後に、「署名」です。
この署名は、送信する、「Consumer key」「Access Token」「付加情報」の部分を、「鍵」を使って行います。
処理の内容は省略しますが、つまりは、署名に使う「鍵」を知っている人でないと署名を作成できないというものです。
さて、この、「鍵」になるのが、残った、Consumer secret, Access Token Secret の２つです。
つまり、この鍵を知らなければ、署名が作成できません。
前述の通り、「全く同じユーザー情報は２度と使えない」「異なる情報を作ろうとすれば、secret という名前のついた鍵が必要」「しかも、secret という名前のついた鍵は、ホストに送信されることがない」ということで、情報が盗まれたとしても安全だという仕掛けです。
【最後に――全部の鍵が盗まれたら】
以上のことを踏まえると、Consumer key, Consumer secret, Access Token, Access Token Secret が揃っていれば、不正アクセスでもできてしまうということになります。
一応、Consumer secret, Access Token Secret は盗まれることがない仕掛けになっているのですが、パソコンを丸ごと盗まれるとか、いろいろあるかもしれません。
実は、その場合でも、気づけば（というか、本当は、盗まれたことに気づくということが最も重要）アプリケーションの作者は、Consumer key, Consumer secret を変更できます。この時点で、盗まれた、Consumer key, Consumer secret は、無効になってしまいます。
しかも、Access Token, Access Token Secret も、「このアプリケーション専用」なので、他のアプリケーションから、盗んできた Access Token, Access Token Secret をもとに不正アクセスするということもできません。
このようなわけで、少なくとも、被害拡大は防げるようになっているわけです。
OAuth への道―― HMAC-SHA1, Base64, URL Encode
-------------------- HMAC-SHA1 + Base64 でシグネチャーを作る -------------------------
さて、以前にも書いたとおり、この周辺の処理は理解できませんでした……で、ソースを
入手しました。
http://www.koders.com/c/fid645718469E4742143926FA6138FC7FD33BBD3A4F.aspx から入手しました。
使用したのは、base64.h base64.c hmac.h hmac_sh1.c memxor.h memxor.c sha1.h sha1.c です。
Windows の処理系で、かつ、Ｃ＋＋で動かそうとすると、いくつかの変更が必要になります。
まず、
・各ソースに含まれている #inlcude は削除します。
これは、unix 環境でファイルの依存関係などを記述するファイルらしいです。
が、そもそも、config.h が入手できなかったのと、実際には、なくてもコンパイルできるので、これはあっさりと削除します。
・いくつかのソースにある、restrict を削除します。
これは、C99 で定義された予約語で、関数の引数として渡された領域が「重なっていない」とコンパイラに仮定させるものです。
標準の C++ では、まだ定義されてないので、これまた、あっさりと削除します。
さて、実際に、HMAC-SHA1 および、BASE64 でシグネチャーを作成します。
以上のファイルがそれぞれコンパイルできる状態で、
void makeSign(const char *inBuff, char *key, char *outBuff)
{
int inLen = std::strlen(inBuff);
int keyLen = std::strlen(key);
char resBuff[1024];
hmac_sha1 (key, keyLen, inBuff, inLen, resBuff);
base64_encode (resBuff, 20, outBuff, 64);
}
これで、inBuff から始まる文字列を、key という文字列で、ダイジェストし、Base64 で変換したものを、outBuff 以降に保持します。
ただし、実際に使用する際には、もう一段、URL Encode が必要です。
-------------------- URL Encode -----------------------------
URL Encode はそんなに難しい処理ではないので、自力で作りました。
もともと、inBuff と URL Encode して、outBuff にセットするというものです。
３番目の引数の、delChar は、別の用途に使い回したくて、つけています。
これは、URL Encode が必要な文字に対して、%xx とエンコードするのではなくて、「削除」します。
たとえば、
abc+def=ghi
を普通にエンコードすると
abc%26def%3Dghi
ですが、delChar = true; にして呼び出すと、
abcdefghi
とエンコードすべき部分を削除します。
これは、oauth_nonce に使い回すためです。
oauth_nonce は、「POSTごとにランダムな文字列」が要求されますが、ランダムな「文字列」を簡単に作るには、せっかくある、HMAC-SHA1 を使うのが早いと、そういう発想です。
実際には、
Base Strign = "2010/05/15-15:00:00" と時刻から生成し。
key = "1000000" → "1000001" → "1000002" と、POST ごとに＋１した数値（を文字列にしたもの）
を使って、oauth_nonceを生成しています。
ただ、この中に、エンコードできる文字が入ってしまうと、ちょっと面倒なので、なら、エンコードできる文字は「削除」という発想でした。
void URLEnc(const char *inBuff, char *outBuff, bool delChar)
{
char *nonEscape = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";
std::string line = "";
while(*inBuff)
{
char c;
char lBuff[16];
std::string orgLine = "";
c = *inBuff++;
if (std::strchr(nonEscape, c))
{
lBuff[0] = c;
lBuff[1] = '\0';
}
else if (! delChar)
std::sprintf(lBuff, "%%%02X", c);
else
lBuff[0] = '\0';
line += lBuff;
}
std::sprintf(outBuff, "%s", line.c_str());
}
こんな感じで、HMAC-SHA1 → BASE64 → URL エンコード と処理を進めることができました。
さて、以前にも書いたとおり、この周辺の処理は理解できませんでした……で、ソースを
入手しました。
http://www.koders.com/c/fid645718469E4742143926FA6138FC7FD33BBD3A4F.aspx から入手しました。
使用したのは、base64.h base64.c hmac.h hmac_sh1.c memxor.h memxor.c sha1.h sha1.c です。
Windows の処理系で、かつ、Ｃ＋＋で動かそうとすると、いくつかの変更が必要になります。
まず、
・各ソースに含まれている #inlcude
これは、unix 環境でファイルの依存関係などを記述するファイルらしいです。
が、そもそも、config.h が入手できなかったのと、実際には、なくてもコンパイルできるので、これはあっさりと削除します。
・いくつかのソースにある、restrict を削除します。
これは、C99 で定義された予約語で、関数の引数として渡された領域が「重なっていない」とコンパイラに仮定させるものです。
標準の C++ では、まだ定義されてないので、これまた、あっさりと削除します。
さて、実際に、HMAC-SHA1 および、BASE64 でシグネチャーを作成します。
以上のファイルがそれぞれコンパイルできる状態で、
void makeSign(const char *inBuff, char *key, char *outBuff)
{
int inLen = std::strlen(inBuff);
int keyLen = std::strlen(key);
char resBuff[1024];
hmac_sha1 (key, keyLen, inBuff, inLen, resBuff);
base64_encode (resBuff, 20, outBuff, 64);
}
これで、inBuff から始まる文字列を、key という文字列で、ダイジェストし、Base64 で変換したものを、outBuff 以降に保持します。
ただし、実際に使用する際には、もう一段、URL Encode が必要です。
-------------------- URL Encode -----------------------------
URL Encode はそんなに難しい処理ではないので、自力で作りました。
もともと、inBuff と URL Encode して、outBuff にセットするというものです。
３番目の引数の、delChar は、別の用途に使い回したくて、つけています。
これは、URL Encode が必要な文字に対して、%xx とエンコードするのではなくて、「削除」します。
たとえば、
abc+def=ghi
を普通にエンコードすると
abc%26def%3Dghi
ですが、delChar = true; にして呼び出すと、
abcdefghi
とエンコードすべき部分を削除します。
これは、oauth_nonce に使い回すためです。
oauth_nonce は、「POSTごとにランダムな文字列」が要求されますが、ランダムな「文字列」を簡単に作るには、せっかくある、HMAC-SHA1 を使うのが早いと、そういう発想です。
実際には、
Base Strign = "2010/05/15-15:00:00" と時刻から生成し。
key = "1000000" → "1000001" → "1000002" と、POST ごとに＋１した数値（を文字列にしたもの）
を使って、oauth_nonceを生成しています。
ただ、この中に、エンコードできる文字が入ってしまうと、ちょっと面倒なので、なら、エンコードできる文字は「削除」という発想でした。
void URLEnc(const char *inBuff, char *outBuff, bool delChar)
{
char *nonEscape = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";
std::string line = "";
while(*inBuff)
{
char c;
char lBuff[16];
std::string orgLine = "";
c = *inBuff++;
if (std::strchr(nonEscape, c))
{
lBuff[0] = c;
lBuff[1] = '\0';
}
else if (! delChar)
std::sprintf(lBuff, "%%%02X", c);
else
lBuff[0] = '\0';
line += lBuff;
}
std::sprintf(outBuff, "%s", line.c_str());
}
こんな感じで、HMAC-SHA1 → BASE64 → URL エンコード と処理を進めることができました。
2010年05月14日
OAuth への道――具体的な送信内容
さて、Bot 限定でなんとか、必要なキーを入手することができました。
入手できたキー情報は４個
Bot の場合、キーの入手がかなりお手軽なので本当に助かりました。
Consumer key: aaaaaaaaaaaaaaaaaaaaaa
Consumer secret: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Access Token: cccccccccccccccccccccccccccccccccccccccccccccccccc
Access Token Secret: ddddddddddddddddddddddddddddddddddddddddddd
※このキーは架空のものです。もうちょっとそれらしいものをでっち上げたかったのですが……。
これをもとに、ヘッダを作成します。
必要な処理は
・URL Encode …… とりあえず自作。
・HMAC-SHA1 および、BASE64 によるシグネチャーの作成 …… ソースを取ってきました。
・Unix Time の算出 …… とりあえず自作。Turbo C++ にある、TDateTime 型から変換。
私の場合、「節気さんシリーズ」を動かすことが目的なので、とにかく、POST ができればいいという、そういう方針でまいります。
【HTTP ヘッダ】
POST http://api.twitter.com/1/statuses/update.xml HTTP/1.1
Host: api.twitter.com
Content-type: application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce="777ccc777",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1273672200",
oauth_consumer_key="aaaaaaaaaaaaaaaaaaaaaa",
oauth_token="cccccccccccccccccccccccccccccccccccccccccccccccccc",
oauth_signature="xxxxxxxxxxxxxxxxxxxxxxxxxxx%3D",
oauth_version="1.0"
Content-Length: 135
※上記の oauth_nonce= から、 oauth_version="1.0" までは実際には一行です。（改行は入りません）
oauth_nonce="777ccc777",
―― ランダムな文字列です。このあとの、timestamp と併せて、リクエストの一意性を確保するためです。
oauth_signature_method="HMAC-SHA1",
―― シグネチャーの生成方式で、Twitter では、これに限定されます。
oauth_timestamp="1273672200",
―― リクエストを発行した時刻です。Unix Time とよばれるもので、
1970年1月1日00:00:00(UTC)からの通算秒です。
この時刻から、５分間は有効らしいです。
あとで第三者に「再利用」されないための処置です。
oauth_consumer_key="aaaaaaaaaaaaaaaaaaaaaa",
oauth_token="cccccccccccccccccccccccccccccccccccccccccccccccccc",
―― これは、既に入手しているキーになります。
oauth_signature="xxxxxxxxxxxxxxxxxxxxxxxxxxx%3D",
―― これが、シグネチャーでして、まあ、鬼門だと思います。
oauth_version="1.0"
―― これも、現時点では、1.0 に固定です。
【先に、HTTP Body の方を……】
Twitter に投稿するための、「投稿内容」です。
実は、シグネチャーの生成には、この内容も含まれます。
status=（UTF-8 で書いたものを、ERL エンコードした文字列）
です。
ここでは、簡単に
status=abcd
としておきます（これだと、実質的にエンコードの必要がない）
【シグネチャーの生成】
さて、いよいよ、シグネチャーの生成です。
シグネチャーは、「Base String」を、「key」によって、HMAC-SHA1 で変換したものを、さらに、BASE64 で変換したものです。
● Base String とは……
ここでは、POST 処理を考えていますので、
POST
&
http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fupdate.xml
&
oauth_consumer_key%3Daaaaaaaaaaaaaaaaaaaaaa
%26
oauth_nonce%3D777ccc777
%26
oauth_signature_method%3DHMAC-SHA1
%26
oauth_timestamp%3D1273672200
%26
oauth_token%3Dcccccccccccccccccccccccccccccccccccccccccccccccccc
%26
oauth_version%3D1.0
%26
status%3Dabcd
となります。
実際には、これを改行無しで１行にしたものです。
所々見えている、%3D は = を、%26 は、& をそれぞれ URL Encode したものです。
また、そのまま & になっている部分もあります（POST の直後と、http://api.twitter/1/statuses/update.xml の直後）
あと、順番にも注意が必要です。パラメータがアルファベット順に並ぶようにします。（この順番はそうなっています）
● Key とは……
ここまで使っていなかった、secret の出番です。
キーは、Consumer secret と Access Token Secret を & でつないだものです。
つまり、
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb&ddddddddddddddddddddddddddddddddddddddddd
がキーになります。
● これを、HMAC-SHA1 と BASE64 で整形する。
実際の処理は、理解できませんでした。
ソースを、 http://www.koders.com/c/fid645718469E4742143926FA6138FC7FD33BBD3A4F.aspx から入手しました。
使用したのは、base64.h base64.c hmac.h hmac_sh1.c memxor.h memxor.c sha1.h sha1.c です。
この例で計算すると、 lJdZXD19quOrpHsxMzfaM0WWkW8%3D になるようです。
急ぎ足ですが、まずは、一通りやってみたところで。
入手できたキー情報は４個
Bot の場合、キーの入手がかなりお手軽なので本当に助かりました。
Consumer key: aaaaaaaaaaaaaaaaaaaaaa
Consumer secret: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Access Token: cccccccccccccccccccccccccccccccccccccccccccccccccc
Access Token Secret: ddddddddddddddddddddddddddddddddddddddddddd
※このキーは架空のものです。もうちょっとそれらしいものをでっち上げたかったのですが……。
これをもとに、ヘッダを作成します。
必要な処理は
・URL Encode …… とりあえず自作。
・HMAC-SHA1 および、BASE64 によるシグネチャーの作成 …… ソースを取ってきました。
・Unix Time の算出 …… とりあえず自作。Turbo C++ にある、TDateTime 型から変換。
私の場合、「節気さんシリーズ」を動かすことが目的なので、とにかく、POST ができればいいという、そういう方針でまいります。
【HTTP ヘッダ】
POST http://api.twitter.com/1/statuses/update.xml HTTP/1.1
Host: api.twitter.com
Content-type: application/x-www-form-urlencoded
Authorization: OAuth oauth_nonce="777ccc777",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1273672200",
oauth_consumer_key="aaaaaaaaaaaaaaaaaaaaaa",
oauth_token="cccccccccccccccccccccccccccccccccccccccccccccccccc",
oauth_signature="xxxxxxxxxxxxxxxxxxxxxxxxxxx%3D",
oauth_version="1.0"
Content-Length: 135
※上記の oauth_nonce= から、 oauth_version="1.0" までは実際には一行です。（改行は入りません）
oauth_nonce="777ccc777",
―― ランダムな文字列です。このあとの、timestamp と併せて、リクエストの一意性を確保するためです。
oauth_signature_method="HMAC-SHA1",
―― シグネチャーの生成方式で、Twitter では、これに限定されます。
oauth_timestamp="1273672200",
―― リクエストを発行した時刻です。Unix Time とよばれるもので、
1970年1月1日00:00:00(UTC)からの通算秒です。
この時刻から、５分間は有効らしいです。
あとで第三者に「再利用」されないための処置です。
oauth_consumer_key="aaaaaaaaaaaaaaaaaaaaaa",
oauth_token="cccccccccccccccccccccccccccccccccccccccccccccccccc",
―― これは、既に入手しているキーになります。
oauth_signature="xxxxxxxxxxxxxxxxxxxxxxxxxxx%3D",
―― これが、シグネチャーでして、まあ、鬼門だと思います。
oauth_version="1.0"
―― これも、現時点では、1.0 に固定です。
【先に、HTTP Body の方を……】
Twitter に投稿するための、「投稿内容」です。
実は、シグネチャーの生成には、この内容も含まれます。
status=（UTF-8 で書いたものを、ERL エンコードした文字列）
です。
ここでは、簡単に
status=abcd
としておきます（これだと、実質的にエンコードの必要がない）
【シグネチャーの生成】
さて、いよいよ、シグネチャーの生成です。
シグネチャーは、「Base String」を、「key」によって、HMAC-SHA1 で変換したものを、さらに、BASE64 で変換したものです。
● Base String とは……
ここでは、POST 処理を考えていますので、
POST
&
http%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fupdate.xml
&
oauth_consumer_key%3Daaaaaaaaaaaaaaaaaaaaaa
%26
oauth_nonce%3D777ccc777
%26
oauth_signature_method%3DHMAC-SHA1
%26
oauth_timestamp%3D1273672200
%26
oauth_token%3Dcccccccccccccccccccccccccccccccccccccccccccccccccc
%26
oauth_version%3D1.0
%26
status%3Dabcd
となります。
実際には、これを改行無しで１行にしたものです。
所々見えている、%3D は = を、%26 は、& をそれぞれ URL Encode したものです。
また、そのまま & になっている部分もあります（POST の直後と、http://api.twitter/1/statuses/update.xml の直後）
あと、順番にも注意が必要です。パラメータがアルファベット順に並ぶようにします。（この順番はそうなっています）
● Key とは……
ここまで使っていなかった、secret の出番です。
キーは、Consumer secret と Access Token Secret を & でつないだものです。
つまり、
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb&ddddddddddddddddddddddddddddddddddddddddd
がキーになります。
● これを、HMAC-SHA1 と BASE64 で整形する。
実際の処理は、理解できませんでした。
ソースを、 http://www.koders.com/c/fid645718469E4742143926FA6138FC7FD33BBD3A4F.aspx から入手しました。
使用したのは、base64.h base64.c hmac.h hmac_sh1.c memxor.h memxor.c sha1.h sha1.c です。
この例で計算すると、 lJdZXD19quOrpHsxMzfaM0WWkW8%3D になるようです。
急ぎ足ですが、まずは、一通りやってみたところで。
深夜のメールは「マナー違反」だという説
深夜のメールは「マナー違反」といわれたが？
こんな質問が上がっているのをみて、回答してみたのだけれど……。
ほかの回答をみると、携帯電話でメールに対して着信音が鳴るのが迷惑だから……という発想らしい。
しかしながら、もともとインターネットや、かつての、パソコン通信にしても、メールというのは、いつでも好きなときに送信できて、いつでも好きなときにそれを読むことができるというメディアだったのではなかったか。
それが、携帯電話によるメールが浸透してきて、どうも、メールに即時性（というか、即応性）が求められてきている気がする。
それでも、携帯電話でメールが使えるようになったときには、既に電子メールというものは存在して、使われていた。そして、携帯電話から、インターネットへの接続性を確保したという歴史の流れを考えるなら、既に使用されていた「文化」を尊重すべきではあったかと思う。
それにしても、携帯電話から入って、自分の使い方に沿わなければ、その時点で「マナー違反」という言葉が出てくるのも、いかがなものかなと思う。「自分にとっては迷惑だから配慮を求める」というのと、「マナー違反だ」というのは、基準としてずいぶんと異なるのだし、かなり広い範囲を把握しなければ、「マナー違反」という表現は、（本来）難しい。
さて、ここまで考えて、なぜ、そもそもメール着信に、「着信音」が存在するのかと考えた。通話であれば、確かに着信音は必要で、着信音が鳴れば、すぐに出るか、少なくとも相手先を確認しなければならい。そして、だからこそ、「通話」に対しては、深夜は遠慮しろとか、受ける方も、必要に応じてマナーモードにせよとか、それこそ、「マナー」と考えられるようなことがある。
一方、メールに対して、着信音が鳴ったから、即メールを見るという行動がどの程度一般的なのだろう。「仕事の関係でメールを携帯電話に転送している」人だって、まさか、お客様と商談中に、「ちょっと失礼」という行為はしないだろう。
結局、移動中だとか、商談の間だとか、「自分で確保できた時間」のなかでメールを読むことになる。
だったら、多分、メールに対しては本来着信音は不要なのだ。
では、なぜ、「深夜のメールはマナー違反」といわれるほど、みなが、メールに対して着信音を設定しているのだろう。
かくいう私も、しばらくはメール着信音を設定していた。
それがあまりうるさいので、着信音を「無音」にして、そして、家族とアラーム的に使っているメールについては、個別設定でそれぞれ別々の着信音を設定している。
もしかしたら、携帯電話の初期状態でメール着信音が鳴るように設定されているのが大きな要因かもしれない。
さらにいえば、メール着信音の初期状態が、「通話の着信音と同じ」に設定されているケースもあった。
確かに、夜中、通話と同じ着信音で飛び起きれば、何のことはないメールだったというのは迷惑な話だろう。
でも、その、メール着信音、そもそも必要ですか？
こんな質問が上がっているのをみて、回答してみたのだけれど……。
ほかの回答をみると、携帯電話でメールに対して着信音が鳴るのが迷惑だから……という発想らしい。
しかしながら、もともとインターネットや、かつての、パソコン通信にしても、メールというのは、いつでも好きなときに送信できて、いつでも好きなときにそれを読むことができるというメディアだったのではなかったか。
それが、携帯電話によるメールが浸透してきて、どうも、メールに即時性（というか、即応性）が求められてきている気がする。
それでも、携帯電話でメールが使えるようになったときには、既に電子メールというものは存在して、使われていた。そして、携帯電話から、インターネットへの接続性を確保したという歴史の流れを考えるなら、既に使用されていた「文化」を尊重すべきではあったかと思う。
それにしても、携帯電話から入って、自分の使い方に沿わなければ、その時点で「マナー違反」という言葉が出てくるのも、いかがなものかなと思う。「自分にとっては迷惑だから配慮を求める」というのと、「マナー違反だ」というのは、基準としてずいぶんと異なるのだし、かなり広い範囲を把握しなければ、「マナー違反」という表現は、（本来）難しい。
さて、ここまで考えて、なぜ、そもそもメール着信に、「着信音」が存在するのかと考えた。通話であれば、確かに着信音は必要で、着信音が鳴れば、すぐに出るか、少なくとも相手先を確認しなければならい。そして、だからこそ、「通話」に対しては、深夜は遠慮しろとか、受ける方も、必要に応じてマナーモードにせよとか、それこそ、「マナー」と考えられるようなことがある。
一方、メールに対して、着信音が鳴ったから、即メールを見るという行動がどの程度一般的なのだろう。「仕事の関係でメールを携帯電話に転送している」人だって、まさか、お客様と商談中に、「ちょっと失礼」という行為はしないだろう。
結局、移動中だとか、商談の間だとか、「自分で確保できた時間」のなかでメールを読むことになる。
だったら、多分、メールに対しては本来着信音は不要なのだ。
では、なぜ、「深夜のメールはマナー違反」といわれるほど、みなが、メールに対して着信音を設定しているのだろう。
かくいう私も、しばらくはメール着信音を設定していた。
それがあまりうるさいので、着信音を「無音」にして、そして、家族とアラーム的に使っているメールについては、個別設定でそれぞれ別々の着信音を設定している。
もしかしたら、携帯電話の初期状態でメール着信音が鳴るように設定されているのが大きな要因かもしれない。
さらにいえば、メール着信音の初期状態が、「通話の着信音と同じ」に設定されているケースもあった。
確かに、夜中、通話と同じ着信音で飛び起きれば、何のことはないメールだったというのは迷惑な話だろう。
でも、その、メール着信音、そもそも必要ですか？
2010年05月10日
OAuth への道――Bot 用、Access Token、Access Token Secret 入手法
さて、Twitter の Basic 認証終了が迫りました。
節気さんシリーズは、現在 Basic 認証で動いているので、なんとか、６月中に OAuth に対応させなければなりません。
しかも、この Bot Ｃ＋＋で動いているので、なんか、かなり自分でコードを書かなければならない雰囲気。
（とりあえず、HMAC-SHA1 の部分は、なんとかコードを探してくることにしますが……）
そこで必要になる情報が、アプリケーション（Bot プログラム）側で２つ。Consumer key と Consumer secret。
Bot のアカウント側で２つ。Access Token (oauth_token) と、Access Token Secret (oauth_token_secret) 。
前者の２個は、アプリケーション登録時に、その情報として得られるので良いのですが、後者の２個はちょっと難しい。
もともと、OAuth 自体が、アプリケーション（クライアント）側に、自分のパスワードを知られずに、機能を委譲するというものなので、アカウント側の情報を得るのは、ある程度面倒な使用になるのは仕方ないのですが。
ところで、Bot の場合、事情はかなり特殊です。
・そのアプリケーションは、Bot としてのポスト（など）にしか使用されない。
・Bot のアカウント自体も、もともと、プログラム作成者（＝アプリケーションの登録者）が管理している。
ということで、やはり、Bot であれば、アカウント側の情報も簡単に入手する方法があったのでした。
１．http://dev.twitter.com/ を開く
２．(2)Register an app をクリックして、アプリケーションの登録（既に登録してあれば次に）
３．Bot のアカウントでsign in する
４．アプリケーションの登録作業
５．この時点で、Consumer key, Consumer secret が取得できる。
６．My Account Token をクリック
７．Access Token (oauth_token) と、Access Token Secret (oauth_token_secret) が取得できる。
（同時に、該当アカウントの、設定 → 外部アプリ に、このアプリケーションが登録されている）
８．忘れずに、sign out
こんなところで、OAuth に必要な情報はとりあえず、すべて揃います。
あとは、これを、加工して認証まで持って行くことになります。
あとはまた。
節気さんシリーズは、現在 Basic 認証で動いているので、なんとか、６月中に OAuth に対応させなければなりません。
しかも、この Bot Ｃ＋＋で動いているので、なんか、かなり自分でコードを書かなければならない雰囲気。
（とりあえず、HMAC-SHA1 の部分は、なんとかコードを探してくることにしますが……）
そこで必要になる情報が、アプリケーション（Bot プログラム）側で２つ。Consumer key と Consumer secret。
Bot のアカウント側で２つ。Access Token (oauth_token) と、Access Token Secret (oauth_token_secret) 。
前者の２個は、アプリケーション登録時に、その情報として得られるので良いのですが、後者の２個はちょっと難しい。
もともと、OAuth 自体が、アプリケーション（クライアント）側に、自分のパスワードを知られずに、機能を委譲するというものなので、アカウント側の情報を得るのは、ある程度面倒な使用になるのは仕方ないのですが。
ところで、Bot の場合、事情はかなり特殊です。
・そのアプリケーションは、Bot としてのポスト（など）にしか使用されない。
・Bot のアカウント自体も、もともと、プログラム作成者（＝アプリケーションの登録者）が管理している。
ということで、やはり、Bot であれば、アカウント側の情報も簡単に入手する方法があったのでした。
１．http://dev.twitter.com/ を開く
２．(2)Register an app をクリックして、アプリケーションの登録（既に登録してあれば次に）
３．Bot のアカウントでsign in する
４．アプリケーションの登録作業
５．この時点で、Consumer key, Consumer secret が取得できる。
６．My Account Token をクリック
７．Access Token (oauth_token) と、Access Token Secret (oauth_token_secret) が取得できる。
（同時に、該当アカウントの、設定 → 外部アプリ に、このアプリケーションが登録されている）
８．忘れずに、sign out
こんなところで、OAuth に必要な情報はとりあえず、すべて揃います。
あとは、これを、加工して認証まで持って行くことになります。
あとはまた。
2010年05月09日
「立派な犯罪です」という表現
たとえば、「万引きは立派な犯罪です」という表現がある。
この表現に対して、時として「犯罪を、立派などと表現するとはどういうことだ」というクレームがつくケースがあるらしい。
「立派な」という単語自体は、形容動詞で
・堂々としていて正しいようす。いかめしく見事なようす。また、技術・能力などがすぐれているようす。
・とやかく言う所がなく完全であるようす。
という２つの意味を持っている。（いずれも、『学研国語大辞典（第２版）』
冒頭の例は、後者の用例であり、「間違いなく、明らかに犯罪である」ということを意味している。
後者の意味に気づかなかった場合、不自然な意味だと感じられるわけである。
と、ふと考えてみた。たとえば、「万引きは立派に犯罪です」と表現したら、おそらくクレームはつかないだろう。
この違いは何によるのか？ そもそも、この表現は正しいのか？
さて、少々調べてみると、立派なという単語は形容動詞である。
そして、「立派な犯罪です」というケースでは連体形であり、「立派な」は直接名詞である「犯罪」を修飾する。
これに対して、「立派に犯罪です」のケースでは、連用形であり、助動詞の「です」にかかる。
つまり、「明らかな事実です」というニュアンスとなる。
だから、「立派に犯罪です」であれば、後者の意味が強調され、誤解の余地も少ないと、そういうことのなのだと納得した次第である。
この表現に対して、時として「犯罪を、立派などと表現するとはどういうことだ」というクレームがつくケースがあるらしい。
「立派な」という単語自体は、形容動詞で
・堂々としていて正しいようす。いかめしく見事なようす。また、技術・能力などがすぐれているようす。
・とやかく言う所がなく完全であるようす。
という２つの意味を持っている。（いずれも、『学研国語大辞典（第２版）』
冒頭の例は、後者の用例であり、「間違いなく、明らかに犯罪である」ということを意味している。
後者の意味に気づかなかった場合、不自然な意味だと感じられるわけである。
と、ふと考えてみた。たとえば、「万引きは立派に犯罪です」と表現したら、おそらくクレームはつかないだろう。
この違いは何によるのか？ そもそも、この表現は正しいのか？
さて、少々調べてみると、立派なという単語は形容動詞である。
そして、「立派な犯罪です」というケースでは連体形であり、「立派な」は直接名詞である「犯罪」を修飾する。
これに対して、「立派に犯罪です」のケースでは、連用形であり、助動詞の「です」にかかる。
つまり、「明らかな事実です」というニュアンスとなる。
だから、「立派に犯罪です」であれば、後者の意味が強調され、誤解の余地も少ないと、そういうことのなのだと納得した次第である。
2010年05月03日
お知らせ――「松江の節気」の ID を変更しました。
節気さんシリーズの Bot のうち、「松江の節気」だけが、sekki_twit_bot という、他とはかけ離れた名前になっていました。
今般他のBotと統一するため、sekki_matsue に変更しました。
既にフォローいただいている場合には、何も変更は不要です。
また、@sekki_twit_bot というページも残している（というか、実際には、ID変更後、新たに作った）ので、こちらにいってしまった場合には、sekki_matsue のほうをフォローいただければと思います。
今般他のBotと統一するため、sekki_matsue に変更しました。
既にフォローいただいている場合には、何も変更は不要です。
また、@sekki_twit_bot というページも残している（というか、実際には、ID変更後、新たに作った）ので、こちらにいってしまった場合には、sekki_matsue のほうをフォローいただければと思います。
2010年04月30日
Twitter の「嘘」
いえ、タイトルはちょっと過激につけてみましたが、それほどのものではありませんので、はい。
一般的に、Twitter を「使っている」立場のイメージは、
・気楽なつぶやきを投稿
・気に入った人があれば、フォローする。
・そうすると、フォローした人のつぶやきが「飛び込んで」くる。
・そうして、自分と、フォローした人たちのつぶやきが、「タイムライン」を流れていってしまう。。
こんなところだと思います。
さて、実は、自分の「つぶやき」が、かなり長い間保存されていて、しかも、だれにでも――Twitter のアカウントを持っていない人であっても――見られるということを、意識する機会は少ないのではないでしょうか？
実際、buzztter で検索することも可能ですし、google の検索にも引っかかります。
（自分で、検索することできます）
通常のブログであれば、ユーザーサイドでも、「書かれたものは消さない限り、保存・公開される」というのが、意識できる構造になっています。
一方で、Twitter は、「タイムライン」を見る限り、つぶやきは、どんどん流れていってしまう――と、そう感じられるのが、もしかしたら、その「つぶやき」が、永く・広く公開されてしまっているというのを、意識しにくい形になっているのではないかと、思うわけです。
※ただし、「自分のつぶやきを公開しない」設定であれば、一般的な検索には引っかかりません。
既に、「自宅を留守にします」とつぶやいたら、泥棒に入られたという事件も発生していますが、
http://www.ideaxidea.com/archives/2009/06/twitter_robery.html
もしかしたら、Twitter というのは、その、「感じ方」と「波及効果」の間に、かなりのギャップがあるのかもしれません。
【ここから、若干技術的なお話】
技術的には、「どんなデータを使うか」ということと、「そのデータをどう見せるか」というのは、個別に考えることです。
データは同じものであっても、どう見せるかで、掲示板のように見えたり、Twitter のように見えたりするわけです。
実際、技術的にいえば、Twitter に対して行われた「つぶやき」は、決して、「飛び込んで」は来ません。
自分が、フォローしている人のリストを頼りに（自動的にですが）読み込んでいるだけです。
だから、Twitter の方から見ると、ポストされるより、タイムラインを「読む」ことの方が、負荷がかかります。
ですから、多くの人にフォローされても、案外、システム的には平気なのですが、多くの人をフォローすると、システム的に結構きついことになります。（なので、フォローする数は制限がある）
このあたり、「どう見せるか」という点をよく考えられたシステムだと思います。
ただ、通常のユーザーサイドの感じ方を超えた、検索が可能なところは、若干、疑問を感じないでもありません。
一般的に、Twitter を「使っている」立場のイメージは、
・気楽なつぶやきを投稿
・気に入った人があれば、フォローする。
・そうすると、フォローした人のつぶやきが「飛び込んで」くる。
・そうして、自分と、フォローした人たちのつぶやきが、「タイムライン」を流れていってしまう。。
こんなところだと思います。
さて、実は、自分の「つぶやき」が、かなり長い間保存されていて、しかも、だれにでも――Twitter のアカウントを持っていない人であっても――見られるということを、意識する機会は少ないのではないでしょうか？
実際、buzztter で検索することも可能ですし、google の検索にも引っかかります。
（自分で、検索することできます）
通常のブログであれば、ユーザーサイドでも、「書かれたものは消さない限り、保存・公開される」というのが、意識できる構造になっています。
一方で、Twitter は、「タイムライン」を見る限り、つぶやきは、どんどん流れていってしまう――と、そう感じられるのが、もしかしたら、その「つぶやき」が、永く・広く公開されてしまっているというのを、意識しにくい形になっているのではないかと、思うわけです。
※ただし、「自分のつぶやきを公開しない」設定であれば、一般的な検索には引っかかりません。
既に、「自宅を留守にします」とつぶやいたら、泥棒に入られたという事件も発生していますが、
http://www.ideaxidea.com/archives/2009/06/twitter_robery.html
もしかしたら、Twitter というのは、その、「感じ方」と「波及効果」の間に、かなりのギャップがあるのかもしれません。
【ここから、若干技術的なお話】
技術的には、「どんなデータを使うか」ということと、「そのデータをどう見せるか」というのは、個別に考えることです。
データは同じものであっても、どう見せるかで、掲示板のように見えたり、Twitter のように見えたりするわけです。
実際、技術的にいえば、Twitter に対して行われた「つぶやき」は、決して、「飛び込んで」は来ません。
自分が、フォローしている人のリストを頼りに（自動的にですが）読み込んでいるだけです。
だから、Twitter の方から見ると、ポストされるより、タイムラインを「読む」ことの方が、負荷がかかります。
ですから、多くの人にフォローされても、案外、システム的には平気なのですが、多くの人をフォローすると、システム的に結構きついことになります。（なので、フォローする数は制限がある）
このあたり、「どう見せるか」という点をよく考えられたシステムだと思います。
ただ、通常のユーザーサイドの感じ方を超えた、検索が可能なところは、若干、疑問を感じないでもありません。
