Google Friend Connect API に gadgets.io.makeRequest 相当を自前で実装する - snippets from shinichitomita’s journal
Google Friend Connect のOpenSocial APIには gadgets.io.makeRequest が含まれていない（今のところ）。もしあると個人的にちょっとだけ嬉しかったりするので、作った。これでHTML側ではGFCのスクリプトをロードするだけで、任意のサーバに対してHTTPリクエストを送ることができる。リソース側にJSONPインターフェースとかcrossdomain.xmlは必要ない、いわばGFCをオープンなクロスドメインプロキシとして使っている。 e.g. http://gfcxd.googlecode.com/svn/trunk/xd-test.html opensocial-jquery版。ちゃんと動く。 http://gfcxd.googlecode.com/svn/trunk/opensocial-jquery-test.html ContentTy
OAuth CrossDomain JavaScript Proxy を作った - snippets from shinichitomita’s journal
サービス： http://xdoauthproxy.appspot.com/ ソースコード： http://xdoauthproxy.googlecode.com/ 何ができるか OAuth(3-legged)のAPIがJavaScriptクライアントから簡単に呼べるようになります。 プログラム的には非同期の呼び出しのみで記述でき、面倒な手続き（トークンのやり取り、同意画面の表示など）はプロキシ側で完了します。 プロキシサービスはGoogle App Engine上で動いてます。 コード例 http://xdoauthproxy.googlecode.com/svn/trunk/assets/example.html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/ht
Google FriendConnect APIとFacebook Connectという変態たち - snippets from shinichitomita’s journal
遅ればせながら、Google FriendConnect がAPI出しましたね。Google FriendConnect本体がブログパーツ的にウェブに貼付けるものだったので、それ用のガジェット開発キットかなと思ってあつかうと、間違えますね。これ、ぜんぜんガジェット開発者だけの話ではないですよね。 早速えーじさんが記事を書いてます。 サービス提供者にとって，今回公開されたGFCの認証機構は魅力です。OpenIDを使ってすら複雑なサーバー実装を必要とした認証が，HTMLファイルとJavaScriptの設置だけで実現できるのです。認証機能を完全に外部にたよることで，Cookieのパラメータでログイン状態を判断し，さらにそれを認可にも用いることで，サービス提供者は開発の手間を劇的に減らすことができます。 http://gihyo.jp/dev/column/01/social/2009/03180
window.nameによるクロスドメインXMLHttpRequestを実装してみる - snippets from shinichitomita’s journal
前回のつづき。 さて、大体 window.name によるクロスドメイン通信がどんなものかで、dojo のwindowNameモジュールがどんなことやってるかはわかった。個人的にdojoはすばらしいことをやっていると思うが、これだけのために常にdojoを使う気にはならない。ので、可能な限りポータブルなライブラリを実際に自分で実装してみることにする。 実装前におさえておきたい前提 クロスドメインでリクエストを送るためには、ターゲットとなるリソースが配置されているサーバの同一ドメイン上に、プロキシの役割を担うHTMLファイルがあらかじめ配置可能である必要がある。これはFlashで例えればcrossdomain.xmlのようなもので、リソース側がクロスドメインのリクエストをオプトインしている、と考えればよい。さらにポリシーを記述することができるという点でもよく似ている（これは後述）。 何らかの静
window.nameによるクロスドメイン通信 - snippets from shinichitomita’s journal
随分前になるが、SitePenの人 (dojo) が書いたブログに window.nameを使ったクロスドメイン通信についてまとめられていた。 window.name Transport - Blog | SitePen 気になっていたがちゃんと読む時間がなかったので、今ごろ見てみる。抜粋して訳。 window.name による通信 The window.name transport is a new technique for secure cross-domain browser based data transfer, and can be utilized for creating secure mashups with untrusted sources. window.name is implemented in Dojo in the new dojox.io.windowN
OpenIDとプライバシー - snippets from shinichitomita’s journal
最近ずいぶんフィード消化してませんでした。で、久しぶりに見てみたら、こんな話がZIGOROuさんとこに。 Web+DBのOrenID特集を読みました。、教えて欲しい疑問点があります。素人なので初歩的な疑問点で申し訳ありませんが、よろしくお願い致します。 今、携帯電話の契約者固有ＩＤのプライバシーの懸念が問題になっています。http://takagi-hiromitsu.jp/diary/20080710.html 問題点を以下に要約しますと、 ａ サイトで住所氏名Ｅメールアドレス等の個人特定情報を入力することによって、その個人特定情報と契約者固有ＩＤ（ｉモードＩＤ等）とが紐付けられ、ネット上での行動履歴情報が契約者固有ＩＤを手掛かりに収集され（名寄せされ）、その収集情報と個人とが結び付けられる。 ｂ 収集情報と個人とを結び付けた情報（以下「個人特定型ライフログ」という）が、悪徳業者の手に渡
SAMLについて自由勝手に紹介 - snippets from shinichitomita’s journal
宿題をid:ZIGOROuさんから課せられたので、早めにやっつけで片付けます。でも入門、というのとはちょっとちがうだろうな。今回は、SAMLを知っている人には当たり前の話でも、知らない人はきっとわからないだろうことを補足するだけです。しかもとみたの主観的におもしろいと思ってるところだけ。 そもそも僕自身の能力的な話で、Libertyの時代も仕様は気になったところしか読んでないので、網羅的に書くのは正直つらいし、割に合わないと感じてます。ただ、今回はきっとtkudoさんが添削してくれるはずなので、かなりのびのびと書いちゃいます。 歴史のおさらい まず間違え易い点として、SAML1.0とか1.1ってのは、SAMLが出たてのときの仕様なので、いまの話(v2.0)と結構違う。結構SAMLで検索するとこのころの話が引っかかったりする。むしろ今のSAML 2.0を調べようとしたらLiberty ID-
snippets from shinichitomita’s journal - AOL WebAIM APIを注目すべき５つの理由
AOL OpenAuthがすごいとか、JSONPによる認証だとか騒いでたけど、もう去年の１１月にAOL Web AIM APIが公開されていたということについて、なんで気づいてなかったのか。一年近くもこれを正当に評価してこなかったことは、恥ずべきことだ。 Web AIM APIは、以下の理由で画期的、あるいはちょっとネガティブな側から見れば問題児なAPIである。そして、これからWebサービスAPIを設計／開発する人、およびWebのセキュリティを考える人にとっては、少なくとも現在こういったWebサービスの実装が存在していることについては、ちゃんと注視しておかなければならない。 1. サーバレスでメッセンジャーアプリを構築できる これがとりあず一番目に重要なポイント。これはAPIリクエストとしてJSONP形式のバインディング(運搬方法)を採用していることによる。サーバレスでアプリが作れることの
重み付きシャッフルの回答案 - snippets from shinichitomita’s journal
前回の続き。 問題：配列の中のある要素aに対してWaの重みが付いている。このとき、要素aが要素bより先に来る確率がWa/(Wa+Wb)となるようにシャッフルするにはどうすればよいか？ # 2007年08月28日 brazil brazil 1, TEMP, JAVASCRIPT, PROGRAMMING 最後の方法じゃだめなんだ...、ランダム はてなブックマーク - 重み付けシャッフル、再び - snippets from shinichitomita’s journal ランダムにそのまま重みを掛けた値でのソートだとだめなのは、絵を描いてみるとわかりそう。 PaとPbがそれぞれaおよびbの方が大きくなるエリアだけど、面積比はあきらかにWa:Wbじゃない。 まあその後色々考えて、多分これならそれっぽくシャッフルされるかな、というのを思いついたのだけど、どんなもんか。 var arr =
Subspace: Secure Cross-Domain Communication for Web Mashups: - snippets from shinichitomita’s journal
http://ajaxian.com/archives/subspace-enabling-trusted-cross-domain-ajax http://www2007.org/papers/paper801.pdf これ読んだときは単純に「へー、これでJSONPみたいなのを気軽にできるんだったらまあいい話なのかなあ」とか思ったんだけど、あくまでJavaScript読み込み元のページへの無制限リソースアクセスができちゃうのをSandboxにとどめるための手法ってだけなんで、たとえばブラクラみたいなコードをダウンロードしちゃったときはブラウザ全体でアウトになるから、やっぱそのレベルまで考えるんであれば使えないよなあ。 まあ言ってることの有用度はともかく、さまざまなクロスドメインコミュニケーションの手法とかが整理されていて、そういう意味でいい資料だとおもう。 とりあえずCross Doma
クロスドメインでのデータ読み込みを防止するJavaScript ? - snippets from shinichitomita’s journal
GMailのコンタクトリスト漏洩のエントリのついでに。 JSONデータをscriptタグにのせて配信するサービス（JSONPなど）で、限られたサイトのみにしかそのデータを配信しないようにするためには、クライアントが送出してくるリファラ情報を使ってサービスコンシューマとなっているサイトを特定してアクセス制御する方法がある。 この方法はおそらく大部分のクライアント（ブラウザ）に対しては有効で、例えば実際にGoogle MapsなどもそれとAppKeyを組み合わせてサイトを判別しているっぽいのだけど、意図的にリファラ送出を切っているブラウザであったり、あるいはプロキシプログラムなどが自動的にリファラヘッダを除去してしまうようなクライアント環境に対しては無効になってしまう。 ということで、そんなクライアントでもなんとかならないだろうかと考えていたときにちょっと思いついた、もしかしたらこの方法なら許
WebDAVサービス上で動く、HTML+JavaScriptだけで作られたブログエンジン - snippets from shinichitomita’s journal
WebDAV on XMLHttpRequest で、試しに作ってみようと思ってたのだけど、やっと動くものができた。 http://webdablog.freedav.com/app/admin.html ユーザ名：webdablog パスワード：（ユーザ名と同じ） 無料のWebDAVサービス FreeDAV を利用してます。こちらでは今のところログインしたユーザでしかファイルを参照できないので、やむなく管理者ユーザ名／パスワードを公開。フォルダをパブリックに公開できたり、複数人でフォルダをシェアできればいいのだけどな。 コメント記入不可。トラックバック不可。ブログエンジンとしては弱すぎ。でも、WebDAVファイル共有サービスさえあればブラウザ上でHTMLコンテンツが手軽に作れちゃうので、イントラネットなどで利用できるかも。とはいえIISで動くかどうかは試していないのですが。 ちなみにブロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
