TwitPic API v2で画像のアップロード: ふと思う--ちょっと考える （いたずら編）
Twitterの写真投稿先として一番使われているサイトは、TwitPicです。ここはTwitterのユーザであれば、TwitPicにユーザ登録すること無く写真を投稿できます。これは、Twitterのユーザ名とパスワードを本人確認をしているためです。 しかしどんなに魅力的なサービスであったとしても、ユーザにとってパスワードを登録することに躊躇します。そこで、Twitterを中心にパスワードがなくても本人確認できるOAuthという認証方式が策定されました。 外部サービスで本人確認をする方法 ユーザ確認で一番単純な方法は、パスワードです。パスワードが正しいければ、サービスを使おうとしている人が本人である認めます。OAuthは、パスワードの代わりにTwitterとサービスを提供するアプリだけが知っている秘密の鍵を使って確認します。では、外部サービスであるTwitPicは、どのようにユーザ確認をする
2-legged OAuthによるAPIアクセス - mixiアプリ
OAuth Signatureの生成方法 RESTful APIの利用に必要なOAuth Signatureの生成方法を以下に説明します。 Signature Methodは、現在、HMAC-SHA1のみ対応しています。 まず、署名生成に必要なベース文字列を生成するために次の値を用意します。 HTTPリクエストメソッド（GETやPOSTなど） 実際にリクエストが送信されるAPI URL。クエリーパラメータは含めないようにします。 OAuthの処理に必要な各種パラメータを設定します。クエリーパラメータはこちらに含めます。パラメータの順序は、予めパラメータ名のアルファベット順にソートしておく必要があります。 例えば、下記のような値を用意します。 GET http://api-example.mixi.jp/people/@me/@self oauth_consumer_key=bc906fac
PHPで2-legged OAuthによるAPIアクセス - 不思議なサービスをつくる新人プログラマーの日記
OAuthの実装の仕組みを理解するためにPHPでMyOAuthクラスなるものを自分で作った。 mixiの「2-legged OAuthによるAPIアクセス」を参考にしてるよ。 http://developer.mixi.co.jp/appli/spec/mob/2-legged-oauth ※「こうして生成されたパラメータをAuthorizationヘッダに追加して、APIリクエストを送信します。」ってどうやるねん！と思った。 ※2-legged OAuthはTwitterで採用してるOAuthなんかと違って「ユーザが認証する」プロセスがないようです。 ※追記 : クエリパラメータに ?fields=birthday,gender みたいに , 区切りがあると失敗する。なぜだ。 ⇒ どうやらパラメータの , はエンコードしてはいけないらしい。というか最初にエンコードしとらしい。なので ,
gitのリポジトリをSubversionに変換する - ぱせらんメモ
gitで始めたプロジェクトをSubversionのリポジトリにしたかったのだが、どうやったらいいのか調べてもよくわからない。 Subversionからgitはよくあるのにねー。 試行錯誤の結果とりあえずうまくいったっぽいので記録を残しておく。 これで大丈夫なのかどうかはよくわからない。 きっとid:bleis-tift先生がなんとかしてくれるハズ！ gitからSubversionへ 移行先となる新しいSubversionリポジトリを用意する。 svnadmin create foo んで、コミットがないとうまくいかない感じだったのでtrunk,branches,tagsを作っておく。 svn checkout http://localhost/svn/foo foo cd foo mkdir {trunk,branches,tags} svn commit -m "init" なんかfil
The OAuth 1.0 Protocol
The OAuth 1.0 Protocol draft-hammer-oauth-10 Abstract OAuth は、リソースオーナー (別のクライアントやエンドユーザー) に代わって、サーバーリソースにアクセスするための方法を、クライアントに提供するものである。また、リダイレクトを利用することで、エンドユーザーはクライアントにユーザ名やパスワードを共有することなく、サーバーリソースへの第三者アクセスを認可することができる。 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering T
APIアクセス権を委譲するプロトコル、OAuthを知る ― ＠IT
クロスドメインでのデジタルアイデンティティを守る APIアクセス権を委譲するプロトコル、 OAuthを知る 作島 立樹 NRIパシフィック 2008/1/21 マッシュアップと呼ばれる仕組みで、既存のWebサービスが次々とつながり、新たなサービスが登場している。しかし、メールアドレスなど重要な個人情報が意図せずに「つながれてしまう」可能性もある。そこで登場したのがアクセス権の「委譲」を目的としたプロトコル、OAuthである。本記事ではOAuthの仕組みとともに、なぜそれが登場したのかという背景にも触れる（編集部） マッシュアップの犠牲になるユーザーのアイデンティティ GETなどのHTTPメソッドをもちいてURLへリクエストする、いわゆる「RESTful」【注1】なWeb APIを使ったアプリケーション同士の交流は、いままさに隆盛を極めている。「マッシュアップ」と呼ばれているこのサービス形態
PHP: 定義済み定数 - Manual
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
Tender Surrender » OpenSocialのOAuthまとめ
OpenSocialでは、コンテナが外部サーバーとの通信を行う際、または外部サーバーがコンテナと通信を行う際、OAuthを使用して認可を行います。今回はOpenSocialにおけるOAuthについて、現段階でのまとめを書いてみます。 ※追記(2008/10/20)：2008/10/4に書いたコチラの記事も必読です。 OAuthって何だったっけ？ OAuthはユーザー、コンシューマ、サービスプロバイダの3者間でデータのやり取りを行うとした場合、ユーザーがコンシューマにクレデンシャル(IDやパスワード)を渡すことなく、ユーザーが所有するサービスプロバイダ上のリソースにコンシューマをアクセスさせるためのものです。 例えばユーザーがGoogle(サービスプロバイダ)のアドレス帳(リソース)をMySpace(コンシューマ)上で利用するシーンを思い浮かべてください。OAuthがなければ、MySpace
第2回 OAuth Consumerの実装（入門 : OAuth Access Tokenの取得と利用） | gihyo.jp
OAuth Consumerサンプルを動かす 第1回では実際にOAuthを利用したサービスを触り、ユーザから見たOAuthを理解しました。またOAuthの大まかな処理フローについても触れました。 第2回と第3回では、OAuth Consumerの実装を通じてより深くOAuthを理解します。とは言っても、ゼロからアプリケーションを実装していくのには限界があるので、ここではあらかじめ（Ruby on Railsで）実装したサンプルアプリケーションを使います。なお、ConsumerとService Providerの実装は、すべてrailsを用いて行います。 Ruby on Railsの構築に関しては、技術評論社『WEB+DB PRESS』やRubyist Magazineの記事などをご覧ください。 まずはgithubに公開されているoauth_sampleを動かしてみてください。gitをお使い
『GREE × CyberAgent 合同勉強会レポート』
みなさまはじめまして！ アメーバ事業本部スマートフォンDivエンジニアで１０年入社の紫竹佑騎(twitter: @79yuuki)と申します！！ 今回は７月２７日に開催したGREE x CA 合同勉強会での内容についてレポートさせていただきます。 尚、本エントリはサイバーエージェント公式エンジニアブログ初？のGREEエンジニアブログとの相互リンクになっております。 （こちら→GREE Engineers' Blog | グリーエンジニアブログ） 弊社側のプレゼン資料はこちらのブログで紹介し、GREE様(以下敬称略)のプレゼン資料はGREEエンジニアブログでの掲載していますので合わせて読んでいただければと思います。 会場はGREE株式会社本社の部屋をお借りしました。 両社から８０名前後の参加者が集まり、各社20分セッション × 2 と LT × 4 を行いました。 （その後懇親会代わりにre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GREE Engineer's Blog coming soon...