- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 600円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 300円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 100円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 490円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 400円
doncha.net制作・発行:KindleやiBooks、楽天kobo、BOOK☆WALKERで読む電子書籍
OAuth で twitter にアクセス
OAuthをごそごそやってたのは twitter がそのうち Basic認証じゃなくて OAuthをAPIのクチにする、というの読んだから。
OAuthのわかりやすい解説は他の有用なサイトにまかせるとして、素人のわたしの理解をメモる。
やろうとしているコト。
現状。
1)縦書きtwitter(わたしの作ったtwitterを利用するサイト)がある。
2)縦書きtwitterは現状ではユーザーにtwitterのIDとPASSを入力してもらって、そのユーザーのタイムラインを取得、表示している。
※入力してもらった情報はユーザーのクッキーに保存。twitterに対してはBasic認証で繋いでいる。
この(2)の部分を、今後twitterが推奨するという、OAuthでの認証にしてみたい。
ざっくり大雑把な理解で流すけど。
1)縦書きtwitterにユーザーがアクセスする。
2)縦書きtwitterは、twitter本体に対して、縦書きtwitterは登録してありますよ、とお伺いをたてる。
3)twitter本体が、おう、お前久しぶりやな、ということがわかれば、ユーザーをこっちに寄こしなさい、ということで、ユーザーを twitterにリダイレクトする。
4)ユーザーは twitter に飛ばされて、そこでIDとPASSを入力して「承認」すると、ふたたび縦書きtwitterに戻される。
5)ユーザーは、twitterからもらう アクセスのためのtoken (IDみたいなもんだ)と、tokenを含めたアクセスを正しく認識するためのtoken_secret(パスワードみたいなもんだ)を持って戻ってくることになる。
6)縦書きtwitterは、ユーザーのtokenとtoken_secret=IDとパスワードをどこかに保存しておいて、ユーザーに縦書きtwitterを使ってもらう。
※保存するのはたぶんクッキー。DBに保存したら、今度はそのIDとPASSがだれのものか、というログインが必要になるしねえ。
一応、OAuthで TL を取得したり、つぶやきを投稿したりできるようにはしたけど。はたして、これ、本当に安心で便利なシロモノなのか、そこんとこがまるで理解できない。
Basic認証は、IDもパスワードも平文で流れるのでセキュリティに問題があるのはよくわかる、けど。Basic認証にしろ、OAuthにしろ、少なくともアクセスしている間は、IDとパスワードをどこかに保存しなきゃいけない。この穴はBasic認証だろうとOAuthだろうと同じじゃないのか。見えないIFrameに仕込まれる程度のチャチなクッキー引っこ抜きに引っかかって「なりすまし」被害に合うのは防げない、ような気がする。
ユーザーにしてみれば、yhooなりmixiなり、ひとつのIDとパスワードを使いまわしできるので管理がラク、ってだけだったら(セキュリティ的に画期的になにかが変わったわけでもなさそうな)OAuthなんてこんな「ややこしい」手順を踏まなきゃいけないメリットは感じないんだよなあ。
OAuthの良さを誰か教えてくだされ~。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」