Facebook、TwitterのOAuthを実装しよう第三弾

前回の続きです。
TwitterのOAuthはシグネチャを生成して通信するってのがポイントらしく、実に日本語でおk。
「Twitter OAuth 投稿」とかでググっても、
Twitter BOTを作ろうって記事が多すぎて、やりたいのはそれじゃない、ってなります。
あと、ライブラリをComposerインストールして云々、とかいうのもおおいです。
FTPアカウントしかないサーバが相手だったり、PHPのバージョン違ったりしたらもう破綻するのに、
ライブラリに頼りっきりになるわけにはいかないですよね。
ということで、一旦理解するフェーズです。

目標

ライブラリを使用せず、TwitterでOAuth認証を通してツイートを投稿する仕組みについて理解する

OAuth苦手ニキにも分かるTwitterのOAuth

OAuthよくわからないニキに贈る

そもそもOAuthの基本形は、

  1. リクエストトークンを発行
  2. リクエストトークンを使ってアプリ認証画面に飛ばす
  3. コールバックURLでアクセストークンを取得
  4. アクセストークンを使ってAPIを呼ぶ

ってなっている模様。
種々違いはあれど、WebアプリケーションにおけるOAuthの基本形はこんな感じ。

何すればいいの

TwitterのOAuthはシグネチャというものを生成して、
リクエストにくっつける必要があります。
ある時はGETパラメータに、ある時はリクエストヘッダに。

シグネチャを使ってリクエストトークンを発行、
シグネチャを使ってアクセストークンを発行、
シグネチャを使って各種APIを実行、
という流れなんですが…
_人人人人人人人人人人人人人_
> シグネチャってなんだよ <
 ̄Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y^Y ̄

シグネチャ とは

日本語でおk。
署名っていえば分かるとでも思ってんのかと。

つまりは何かというと、
リクエストパラメータとかトークンをひとまとめにしたデータを作っておいて、
それと一緒にパラメータ送信するから整合性チェックよろしく。
っていうためのデータがシグネチャのようです。
これのおかげでTwitterのOAuthは非常に気持ち悪い設計。

トークンを含めたパラメータ作ってシグネチャ生成してパラメータにシグネチャ追加して
全パラメータをリクエストヘッダに乗せてAPIをコール。
を毎回する必要があるわけで、こんなんpuke不可避やろ。

まとめ

pukeラッシュを乗り越えて、なんとかTwitter OAuthの片鱗を理解できた気がするぜ…
次回はいよいよ実装編。シグネチャ生成さえまとめれば意外とライブラリを使わなくても実装は簡単なもんです。

今回はここまで

参考

https://syncer.jp/twitter-api-matome
実装含め最高に分かりやすいTwitter OAuthの全て。これさえ読めば完璧です。
実装する時に、「これSyncerゼミでやった問題だ!」って叫びたくなるはず。
感謝の意。

元記事はこちら

TwitterのOAuth認証その2:理解編