You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
認証の方法は悩みがちなポイントだと思います。コンテナ等の実装も含めると手段は色々あるし、一言に認証といっても、色々な業務ロジックが絡んでくることも多いからでしょうか。 今回はSAStrutsで、sessionとAOPを使ったスタンダードな方法を実装しました。 仕組みはいたってシンプルで、何らかのロジックで認証した後、ID等のデータをセッションに格納して、その有無でログイン済みかを確認するというものです。ログアウトはそのセッションを廃棄することになります。Webアプリケーションでは王道の方法だと思います。 この場合、認証のチェックが必要な場面で同じ処理が必要になるので、SAStrutsではセッションのチェックはメソッドを分けて、AOPでアクションに適応します。 今回は、全体的にログインしっぱなしでいて欲しいので、LoginAction以外では全てのアクションで確認します。 これにより、どのペ
2012年07月08日19:02 by oklahomer Facebook Night vol.7 発表内容まとめ 2:認証ダイアログの構成 カテゴリTips 「Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions」ではアプリからの投稿周りで多用するパーミッション2つの違いを紹介しましたので、ここでは認証ダイアログをおさらいして、そこでの両パーミッションの違いを紹介します。 新・認証ダイアログは2画面構成3/9から強制以降が始まった新・認証ダイアログは、「User and Friends Permissions(ユーザ自身と友だちに関するパーミッション)」と「Extended Permissions(追加のパーミッション)」の2画面構成となっていて、それぞれ役割が違います。ここでは、email, publish_act
APIやWEBサービスを利用する際によく見かけるのがOAuth(オーオース)とxAuth。 しかし、OAuthは仕組みがやや複雑であるため、詳しく解説されると逆に混乱し簡易すぎるとよくわからない仕組みと理解されがちです。 そこで、自分なりにイイ感じにスッキリまとめたので紹介します。 前書き 近年Webサービスが爆発的に普及してきました。 代表的なサービスではGoogle Yahoo mixi Twitter Facebookなどでしょうか。 これらのWEBサービスを利用又は開発する際に問題になるのがユーザ管理です。 IDやパスワードを預かるWEBサービスではユーザ登録の手間やセキュリティの強化など、利用する側も開発する側にも少なからず煩わしい手続きと思われてきました。 そこで登場したのがOpenIDです。 OpenIDとは OpenIDはWebサービスごとにIDを作成しなくても予め所有して
これは2012年1月の記事です。Facebookアプリを制作のみなさまならわかるかもしれませんが、Facebook apiの仕様は日々変わっていきます。今日の情報は明日には役に立たなくなっているかもしれません。それをご承知の上御覧ください。 javascriptを使うには読み込まなければならない。 当たり前だけれど、facebookのjavascriptSDKはその読み込みにも癖がある。 シンプルにどのようにして読み込むかというところから、ログインまでを示す。 ※注意 FB.loginについて開発者用ページでは以下のようにアナウンスされている。 As of December 13th, 2011, the JavaScript SDK now only supports OAuth 2.0 for authentication. The ability to enable OAuth
EclipseからSubversionを使うのに使えるプラグインはいくつかありますが、今回は、「subclipse」の設定方法を解説します。 ダウンロードとインストール このサイトに行って、「Downloa・・・ 「Eclipseのプラグイン「subclipse」のインストールと使い方」の続きを読む
2011年04月12日17:57 by oklahomer Permissions カテゴリドキュメント http://developers.facebook.com/docs/authentication/permissions/ ユーザがアプリを許可するとき、デフォルトでアプリに与えられる権限はユーザ基本情報の読み込みのみです。それ以上のデータを読み込みたかったり、Facebookに対して書き込みを行いたい場合は、必要に応じてパーミッションを得る必要があります。 パーミッションは以下の5つに分けられます。 Basic Information (パーミッション不要)User and Friend PermissionsExtended PermissionsOpen Graph PermissionsPage Permissions ユーザから追加のパーミッションを取得する方法は認証ドキ
タグやブランチを作成するにはsvn copyでtrunkをコピーする。 例えば、現在のtrunkの状態にtags/release-1.0という名前を付けるには次のようにする。
デジタル・アイデンティティの世界へようこそ はじめまして、OpenID Foundation JapanでエバンジェリストをしているNovです。 この連載では、僕を含めOpenID Foundation Japanにかかわるメンバーで、OpenID ConnectやOAuthなどの「デジタル・アイデンティティ(Digital Identity)」にかかわる技術について紹介していきます。 APIエコノミー時代のデジタル・アイデンティティ 世界中で9億人のユーザーを抱える「Facebook」や5億人のユーザーを持つ「Twitter」など、巨大なソーシャルグラフを持つサービスが、日々その存在感を増しています。日本でも、グリーやモバゲーなどがそれぞれソーシャルゲームプラットフォームを公開し、国内に一気に巨大なソーシャルゲーム市場を作り上げました。最近では、ユーザー数が5000万人を突破し、プラット
2012年07月08日12:25 by oklahomer Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions カテゴリTips 6/26のFacebook Night Vol.7で登壇しましたので、発表内容をまとめておきます。 話した内容はざっくり以下の3点です。 混同してしまうpublish_streamとpublish_actionsパーミッションの違いを、最近の仕様変更をふまえて紹介する認証ダイアログの1ページ目と2ページ目の違いと、先述したパーミッションの扱いの違い実装に落とし込む 30分の発表時間に対して若干詰め込みすぎな感じがありましたので、スライドや発表内容から削った部分も補足しつつ3エントリーに分けて紹介します。 パーミッション取得の現状と問題点実装の最初の段階でしか考えないまず現状として、ユーザから
はじめに 前回まででHerokuとFacebookアプリの概要を学んでいただけたかと思います。今回からは本格的に実装に入っていきたいと思います。まずは、アプリケーションの基本となる認証部分を実装します。Facebookアプリの登録方法からRailsのプラグインを用いて簡単に認証連携を行う方法、Heroku上でのデプロイまで紹介します。 Facebookアプリの認証 Facebookアプリの作成にあたり、必要な部分は認証部分になります。以下のHerokuのドキュメントにそのあたりの解説記事があります。英語で、サンプルがSinatraで記載されているドキュメントになっています。 http://devcenter.heroku.com/articles/facebook このHerokuのドキュメントを参考に、SinatraでなくRails3を利用したサンプルを作成します。 今回紹介するFace
2012年07月09日01:27 by oklahomer Facebook Night vol.7 発表内容まとめ 3:Batch RequestとReal-time Update API カテゴリTips 「Facebook Night vol.7 発表内容まとめ 1:publish_streamとpublish_actions」で主要な2パーミッションの違いを、「Facebook Night vol.7 発表内容まとめ 2:認証ダイアログの構成」では、それら2つの認証ダイアログ上での扱いの違いを紹介しました。その過程で、ユーザがアプリをインストールしたからと言って、全部のパーミッションを許可しているとは限らないことや、あとからFacebook上の設定ページでパーミッションが消されうることを話しました。ここでは、それに対応する実装方法を紹介します。 与えられたパーミッションを確認する例
リニューアルと同時に、Facebook ページを作ってみたんですが、タブ追加機能を使って、Facebook ページにアクセスした際に最初に表示されるページをカスタマイズしてみましたので、その作り方や設定方法などを簡単にご紹介。恒例(謎)の 5分でわかるシリーズ。 Facebook ページは iframe を使用して、外部のサーバにあるコンテンツを比較的簡単に読み込める仕様になっていますが、これを利用することでオリジナルのページを自分の Facebook ページにタブとして表示することができます。 Facebook ページにオリジナルのページを読み込むには、最低限下記の準備が必要です。 Facebook ページの開設 (当たり前ですが) Facebook への開発者登録 外部に公開された PHP が動作する Web サーバ (共有で構わないので SSL が利用できる必要あり ※後述) コンテ
アマゾンAPIを使うのに2009年8月15日から認証が必要になるらしい 2009-05-09-1 [Programming][Affiliate][WebTool] 「Amazon アソシエイト Web サービスの名称変更および署名認証についてのお知らせ」というメールが来ました。 (追記: ほぼ同内容のものが Forum とアソシ公式ブログにもありました。ただし Forum では15日ではなく16日となっています。) さて、このたび、Amazon アソシエイト Web サービスの名称を、「Product Advertising API」と変更しましたことをお知らせいたします。この新名称は、開発者の皆様が Amazon サイトで販売されている商品の広告作成を行い、これによって Amazon より広告費を受け取るという、API の目的をより正しく表しています。 はいはい、了解しました。 「Pr
公開中の認証プロキシエンドポイントAPI RESTを使用しているクライアントアプリケーションの場合、従来のAmazonアソシエイトWebサービスAPI(REST)で使用していた、 http://webservices.amazon.co.jp/onca/xml http://ecs.amazonaws.jp/onca/xml http://xml-jp.amznxslt.com/onca/xml といったエンドポイントを、 http://honnomemo.appspot.com/paproxy http://honnomemo.appspot.com/rpaproxy/jp/ に置き換えることで(クエリはそのまま)Product Advertising APIの認証処理を意識せずとも従来と同等に動作する……はず。 ご自分のGoogle App Engine上で動作させたい場合、以下のソー
「作ろうと思う」って書いちゃったしね 複数のAmazon API認証プロキシを順に使いまわすリバース・プロキシ(reverse proxy)です。 ↓のページから、プロキシ登録が出来ます。 Product Advertising API用リバースプロキシ あ、登録する際にはOpenIDでログインする必要があります。現状、自分のやつをひとつだけしか登録していないのでちょっと寂しい。だれか登録してください(笑)。 リバース・プロキシの負荷の関係から、2009/07/22現在、 認証signature付きのURLを302でリダイレクト Amazon API認証のPROXYを書いたよ(2) - ただのにっき(2009-07-06) で返すようになっていないと、登録出来なくなっています。申し訳ありませんが、ご了承願います。 amazon-auth-proxyの方は、現在対応いただいているところです。
PHPをやっているとPEARというのがよく出てきますが、知らない方もおられると思うので説明します。 PEAR とは、PHP ユーザのためのオープンソースコードの構造化されたライブラリです。 要は、世界中のphpエキスパートの方々が、よく使われる再利用できそうなクラスをパッケージ化して配布しておられる感じです。 ライブラリは分野ごとに分けてそれぞれ公開されています。 →パッケージ一覧 ベンチマークやページのキャッシング、認証など様々なものがあります。 PEAR::DBはデータベースを扱う上で定番となっているのでDBを扱う際は使うことになると思います。 PEARドキュメントを公開していますので、より詳しく知りたい方はこちらをご覧ください。 スポンサードリンク もどる
今回から始まった「ゼロから学ぶ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(後述)を兼ねるサービスとなっています。こういった背景
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く