XMLHttpRequest Level 2 と wedata バックアップ - os0x.blog
http://ss-o.net/json/ 以下に対して、.htaccessで Header append Access-Control-Allow-Origin: *という指定をして、ヘッダーにAccess-Control-Allow-Originをつけているので、(*はすべてのドメインからのリクエストを許可) http://ss-o.net/json/wedataAutoPagerize.json http://ss-o.net/json/wedataLDRize.json などのファイルについてはFirefox3.5、Safari4、Google Chrome 2、IE8*1などのブラウザではクロスドメインでXMLHttpRequestを投げることができます。 サンプルコード javascript:(function(){ var xhr=window.XDomainRequest?
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
Firefox3のクロスサイトXMLHttpRequestの仕様 - bits and bytes
補足 2008.3.28 Cross Site XMLHttpRequest (XHR) Removed From Firefox 3 | Robert Accettura’s Fun With Wordageによると、最近XMLHttpRequestの仕様ドラフトに変更があり、Firefox3のリリース(今のところ6月の予定だとどこかで読みました)には実装が間に合わなそうなので、Firefox3の初期バージョンにはCross Site XMLHttpRequestは載らないことになったそうです。 Firefox3ではドメインが異なっていてもXMLHttpRequestでリクエストが出せるのをmal_blue@tumblrで知りました。 すごいじゃーんというわけでJohn Resig - Cross-Site XMLHttpRequestに書かれている使いかたを参考にちょっといじってみま
OpenAuth, Google GData API JavaScript とプライベートデータのクライアントサイドマッシュアップについて - snippets from shinichitomita’s journal
なんかいろいろと書きたくなってきたので書きます。長文失礼。 AOL OpenAuth のように、iframe でメールアドレスを選択させて、その結果を親フレームに返すようにすべきだと思いました 上の続き - kazuhoのメモ置き場 なるほど。クライアント側でのマッシュアップで Service Provider → Consumer の流れなら IFRAME + HTTP Referfer を使った方が軽いということですね。 OpenAuth の仕組みは全然追っていなかったので、 id:shinichitomita さんのエントリをもう一度読んで勉強します。まず、そこから把握しないと議論にもならなそうですね。 クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダ
クロスドメイン通信とアクセスコントロール - snippets from shinichitomita’s journal
とりあえず好きな分野なので、こういう話には飛びつくようにできている クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダイアリー(2007-12-07) これがおそらく可能な実例としてはすでにあり（OAuthじゃないけども）、AOL WebAIM APIはJSONPにOpenAuthのセキュリティトークンを乗っけてクロスドメインで機密情報の通信してるし、Google GDataのJavaScript APIはGoogle Authのトークンを含めた形でカレンダーにRead/Writeなリクエストをクロスドメインで投げている（iframe越しのトリッキー通信）。いずれもトークンの受け渡しは各サービスとブラウザとの間でダイレクトに行い、サーバ要らずになっているところ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
