Ruby 天気予報編 (9) Twitter Gem と developer 登録 【計算数学 I】

更新日時:

Twitter Gem の利用方法

どのように利用するかを知るためには、私が説明するより、サンプルドキュメントを見るのが早いでしょう。この教材では必要な部分を引用します。

まず、 Twitter REST API を利用するクライアントを用意する必要があります。

client = Twitter::REST::Client.new do |config|
  config.consumer_key        = "YOUR_CONSUMER_KEY"
  config.consumer_secret     = "YOUR_CONSUMER_SECRET"
  config.access_token        = "YOUR_ACCESS_TOKEN"
  config.access_token_secret = "YOUR_ACCESS_SECRET"
end

key, token, secret という文字が並んでいますが、これらは developer 登録された時に発行されるので、そいつを入力することになります。

ここで定義した client を使って client.update(str) を実行すると、 str の内容が Tiwitter に投稿されます。

今回やりたいことを実行するために必要なコードは、なんとこれだけです。ライブラリを利用すると、ここまで簡単に Twitter に投稿できます。ありがたいことです。

Twitter developer 登録

先ほど書いたコードで言う所の str の内容を、すでに私たちは準備しています。 残りは key, token, secret を発行するだけです。 まず先に、具体的な手順を述べます。次に、それがどういう意味を持つのか説明します。

developer 登録の手順

まず、天気予報を投稿したいアカウントを作成し、ログインする。

  • この手順はさすがに自分でやる

次に Twitter Developers にアクセスし、下の方にある Manage my apps にアクセスする。

  • 見つからないなら、ページ内検索。
  • 2017/06 現在ではそういう名称だから、以降突然変わるかも知れない。その場合もそれらしい名前のページにアクセスする。

Create new apps で、アプリケーションを登録する。

  • この時、携帯電話認証が求められるかもしれない。 developer 機能は不正な利用が相次いでいるので、厳しい本人確認が求められるようだ。
  • Name はツイートごとにソース欄に表示される。 他と同じ名前では通らない 。Website はそのリンク先。 Description もアプリケーションの概要として公開される。あまり適当では困るが、今回はプログラミング演習であるので、そこまで気にする必要はない。
  • Callback URL は今回は空欄で構わない。各ユーザーの OAuth 認証をクリックひとつで行う時に必要。
  • 画像で入力されているテキストは全て例なので、自分で入力する。

Create new apps

Key and Access Tokens で、 key, token, secret を確認する。

  • 詳しくは画像を参照。

Key and Access Tokens 1

Key and Access Tokens 2

テキストファイルを読み込む方法は次の記事で書きます。以下では、上記の key らが意味するところを書きます。

前提:アプリケーション・クライアント・アカウントの関係

私たちは Create new Apps でアプリケーションを作りました。アプリケーションにはもっと広い意味があるので、ここで作ったものはより正確にはクライアントと呼ぶべきものです。これは、 Twitter を操作するアプリケーションの素朴な中身だと思って良いです。つまり… Twitter を題材としたアプリには様々なものがありますが「投稿する」「検索する」「閲覧する」といった基本機能は Twitter API が提供しています。その Twitter API を利用するための末端がクライアントです。

このクライアントは、アプリケーション 1 つに対し、基本的には 1 つです。ところが、アプリケーションは、たいていの場合、複数のアカウントを扱う必要があります。

「自分は Twitter 廃人ではない、複数アカウントなんて持っていない」と思うかもしれません。しかしそういう問題ではありません。例えば Twitter の投稿をする iOS アプリケーションを開発して AppStore で売るとすると、そのアプリを買った各々の人が、それぞれ別のアカウントで使用します。でも、クライアントは 1 つのアプリケーションには 1 つです。

故に、 1 つのクライアントに、アカウントは複数登録される ことになります。まずこのことを押さえてください。今回は、自分の作ったクライアントを利用する人が自分 1 人であるからたまたまそうではありません。

  • アプリケーションのうち、Twitter API を利用する部分がクライアント
  • クライアント 1 つに対し、通常は複数のアカウントが登録される

ここまでで、 Consumer Key と Consumer Secret の意味が述べられます。これらは、クライアントの ID とパスワードのようなものです。

OAuth 認証の必要性

さて、クライアントがアカウントを使用する際には、どのような関係で結ばれるべきでしょうか? もっとも素朴な方法は、クライアントに自分の ID とパスワードを入力することです。しかし、これは以下の理由から、 現在の Twitter では使用されていない 認証方法です。

  • 生の ID とパスワードをアプリケーションに入力するのは、セキュリティ上好ましくないです。これが知られると、パスワード変更も含め、危険なことまでできます。アプリケーションにそこまで権限を与えるのはやりすぎです。
  • パスワードを変更した後、あらゆるアプリケーションのパスワードの変更をする手間があります。これは誠にめんどくさいです。

現在は OAuth 認証 が採用されています。これは、 アカウントがクライアントに権限を許可する という考え方に基づいています。

  • 権限を与えるかどうかをアカウントに確認する。OK なら、 Access Token と Access Token Secret を発行する。これらは発行されるたびに新しくなる。
  • 与えられた権限の中で、アカウントの操作ができる。例えば、どんなに頑張っても、パスワードの変更はできない。
  • 必要な権限をクライアント側が指定し、必要な権限をアカウントにリクエストする。

ここまでで、残りの答えがわかります。

  • Access Token と Access Token Secret は、アカウントがクライアントに与えた ID とパスワードである。
  • Access Level が Read and write であるということは、クライアントに読み書きはできるように許可したということ。例えば DM の送受信はできないし、パスワードの変更もできない。
  • 登録時に書いた Description は、「権限を与えるかどうかをアカウントに確認する画面」に出る。

演習

OAuth 認証の場合、権限を取り消す場合は、アカウント保持者がクライアントの同意を得ることなく 一方的に 取り消すことができます。これはなぜ可能でしょうか。また、なぜ望ましいことでしょうか。

ナビゲーション

この教材は、東京大学理学部数学科専門科目「計算数学 I」のために執筆されたものです。 このサイトに掲載する際に、記事を分けてあります。 他の回はRuby 天気予報編 一覧 #ks1-ruby-forecastから御覧ください。

Ruby 入門 (計算数学実習資料集)には他の TA が書いた教材があります。

コメントする