タグ

oauthに関するsnsn9panのブックマーク (8)

  • iPhoneとTwitter OAuth認証の流れについて - いとーけーのページ

    twitterヘの認証方式は2つありまして、1つはお馴染みBasic認証。もう1つがOAuthです。で、なにやら、今後はOAuthしか受け付けなくなるとかいう話があって、ちょっと盛り上がっているtwitterクライアント界隈。 OAuthの細かい話はさておき、twitterのOAuth認証(access_token取得)の手順には2通りがあります。(太字はiPhone上での主な挙動) サーバ型 アプリごとの key から request_token 取得 request_token を用いて twitter のサイトを表示 → MobileSafari起動 ユーザにログインしてもらう 設定していた callback URL が呼び出される → サーバ側で元アプリの URL scheme にリダイレクトし、元アプリを起動 callback に渡された oauth_token から acces

    iPhoneとTwitter OAuth認証の流れについて - いとーけーのページ
  • リバースProxy環境でのmixiアプリのOAuth

    CakePHPでmixiアプリのOAuthを処理させる方法は以下のサイト参照。ホントにシンプルでわかりやすい解説。 [cakephp] mixiアプリのOAuthのリクエストを受け取る – 「のーぶるじゃすぱー」略して「のぶじゃす」のBLOG 通常の環境ではこのまま実装すればOK。 で、このあとロードバランサーの入ったサーバに持ってきたらOAuthが正しく認証されない。 OAuthRequestのhttp_urlを見てみると、 http://192.168.0.2:8001:80//api/hoge/hoge/… という悲しいことになっていて、これがどうも問題のようだと。というか、ホスト:ポート:ポートってどういうことだ… 来ならもちろん、 http://mixiapp.sample.com:80/api/hoge/hoge/… みたいなアドレスになっていないといけない。 ちなみに送信側

  • mixiアプリからの署名付きリクエストの受け側を作る - ppworks.jp

    前回、署名付きリクエストで外部サーバへデータを保存する方法を見てきましたが、そんでは受け側はどうやって作ろうかというお話です。 外部サーバのAPIPHPMySQLを用いて作成することを前提とします。 ** 署名の確認 OAuthの署名を用いて、リクエストがコンテナから発行されたものであることを確認します。 このときリクエストに含まれる -oauth* -opensocial -xoauth_ といったパラメーターは、コンテナがリクエストの際に付与するパラメーターです。 これらはOAuthの認証や、アプリケーションの情報を確認するために使用します。よって同名のパラメーターは指定出来ない事に注意します。 たとえば、パラメータとして以下のようなパラメータを渡すと || opensocial_owner_id=123456789 ||< とか || opensocial_hogehoge_id

    mixiアプリからの署名付きリクエストの受け側を作る - ppworks.jp
  • 署名付きリクエストで外部サーバへデータを保存する - ppworks.jp

    今までアプリケーションのデータ保存は永続化データに任せていました。この度、mixiアプリを作成しましたで作成したアプリを機能拡張するにあたり、データを外部サーバに保存してみようと思います。あるユーザの投稿内容を外部サーバへ送る際に気をつけなければ行けないことを調査してみました。 結論からいうと、署名付きの |javascript| gadgets.io.makeRequest ||< を使うようにする、ということになります。 今回はその具体的な使い方を見ていきます。 その前に、OpenSocialアプリケーションとOpenSocialコンテナ、外部サーバの関係について整理しておきます。 ** 署名なしのgadgets.io.makeRequestからのリクエストを確認する まずは署名なしのgadgets.io.makeRequestを使ったリクエストはサーバ側へ、どのようなパラメータを渡す

    署名付きリクエストで外部サーバへデータを保存する - ppworks.jp
  • 第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をお使い

    第2回 OAuth Consumerの実装(入門 : OAuth Access Tokenの取得と利用) | gihyo.jp
  • 第1回 OAuthとは?―OAuthの概念とOAuthでできること | gihyo.jp

    今回から始まった「ゼロから学ぶOAuth⁠」⁠。全4回の特集にて、これからのWebサービスを開発する上で不可欠な技術「OAuth」について取り上げます。初回は、OAuthの概念について取り上げます。 はじめに はじめまして、iKnow!改めsmart.fmの真武です。現在smart.fmでは、OAuthやOpenID、OpenSocial、Semantic WebやActivity Streamなどといった新しい技術の導入を積極的に行いサイトを活性化させるとともに、smart.fm APIを通じて我々の技術を外部のデベロッパの方々にも提供しています。 smart.fmは日最大のOpenID Relying Partyであるだけでなく、国内では数少ないOAuth Consumer(後述)およびOAuth Service Provider(後述)を兼ねるサービスとなっています。こういった背景

    第1回 OAuthとは?―OAuthの概念とOAuthでできること | gihyo.jp
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 2-legged OAuth on OpenSocial - Codin’ In The Free World

    OAuth Consumer Request 前回も簡単に触れましたが、OAuth Consumer Requestという拡張仕様があり、 これは二者間でのやり取りを行うためのものでした。OAuthのプロトコル中で 重要なパラメータは、トークンとシグネチャ(署名)です。トークンは、ある エンドユーザーがサービスプロバイダ上に持っているリソースに対して、 特定のコンシューマがアクセスしてもよいという認可を与えたという証明となります。 また、コンシューマはリクエスト毎に共有鍵、もしくは秘密鍵で署名をつけることにより、 不正なコンシューマの偽装を防ぐことが出来ます。 二者間でやりとりを行う場合、エンドユーザは登場しません。なので、トークンを 扱う必要がなく、署名の検証のみで認証を行うことになります。 事前にリクエストトークンの発行、エンドユーザをリダイレクトさせて承認をもらう、 承認済のリクエス

  • 1