「fiddle」 には、「いじくる, もて遊ぶ」 とか 「暇・時間をつぶす」 などの意味があるようです。「jsFiddle」 はご存知の通り、HTML + CSS + Mootools、jQuery、Prototype、Dojo などの各種 JavaScript フレームワークで、遊んでみようというサイトです。日本には、「jsdo.it」 という、楽しいサイトもあるのですが、jsFiddle はまだαバージョン。次のβバージョンでは機能追加が数多く予定されており、個人的には期待大なのです。また jsdo.it にはない機能もありますので、必要に応じて使い分けるのが吉だと思います。 今回はそんな魅力が伝えられるよう、まとめてみたいと思います。 1.Firebug Liteの組み込み クロス・ブラウザのチェックも含めて、console 系のデバッグ出力 を使いたい場合、Firebug Lite
JavaScriptの動作をオンラインで確認できるエディタです。 軽く使ってみて使い勝手もよく、サンプルも見れたりして気になっていたので試してみたいと思います。 Create a new fiddle - JSFiddle すぐにスクリプトを書いて、左上の"Run"ボタンを押せば、実行できます。バージョン細かく設定できるので、かなり便利です。 各ウィンドウの右上にHTMLやCSSと記述してあるので、記述する場所を間違えることもないです。 これだけなら、アカウントを作成しなくても使用できます。 ファイルの保存や共有するなどのダッシュボード機能を利用したい場合は、アカウントが必要です。 Create an account - JSFiddle - Code Playground 上記から登録できます。下記が登録ページです。 ユーザ名(30文字以内。半角英数字とアンダーバー) パスワード パスワ
Updated functionality to the original XHR specification including things like file uploads, transfer progress information and the ability to send FormData. Previously known as XMLHttpRequest Level 2, these features now appear simply in the XMLHttpRequest spec. ﹖ 4 - 6: Support unknown◐ 7 - 28: Partial support◐ 29 - 30: Partial support◐ 31 - 49: Partial support✅ 50 - 137: Supported✅ 138: Supported✅
Internet Explorer 系列 で クロスドメイン通信 を行う場合、 IE8, IE9 だと XDomainRequest 、IE10 では XMLHttpRequest を利用します。 ここでは、似て非なる両者を比べてその違いをまとめます。 (IE7 以前は調べていません。。) ちなみに、Chrome や Firefox はかなり以前から XmlHttpRequest level 2 (クロスドメイン通信) 対応しているようです(詳細はこちら)。 XDomainRequest の 機能制約 XDomainRequest は XMLHttpRequest level 2 に比べて、以下の制約があるようです。 スキーマ は http か https のみ 利用可能 メソッド は GET か POST のみ 利用可能 カスタムヘッダー は 利用不可能 Content-Type は t
前回「秋はまだですか」と書きましたが、その日のうちに気温下がったw これでちょっと過ごしやすくなったかも。…薄着で寝ててちょっと風邪引きそうになったのは内緒(・ω・) 本題。 クロスドメインでの非同期通信(XMLHttpRequest Level2)をGoogle App Engineで実装したのでメモ。はまったポイントもいくつか書いておきます。 特にハマったのは出力ヘッダ周り。 Access-Control-Allow-Origin これはあちこちのサイトに書かれてますね。このヘッダを「*」で出力してあげると他ドメインからの通信を受け付けるようになります。・・・が、これだけじゃダメなんです。 Access-Control-Allow-Methods こいつを指定してあげないとサーバーが受け付けてくれません。GETならGET、POSTならPOST・・・と指定してあげないといけません。これは
今回は久しぶりにWebネタです。 HTTPのページからHTTPSを使ってJavaScriptでサーバと通信するのは特に問題無さそうにも思えますが、普通にAjaxを使おうとしても拒否されてしまいます。 クライアント側(http://〜/test.htmlの一部) <a href="#" id="test">test</a> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script> <script> $(function() { $("#test").click(function() { $.ajax({ type: "POST", url: "https://〜/hello.php", data: "name=taro", success: function(msg) { alert(
CORS設定は1つしか書けない CORSを使ったWebアプリケーションを作る際、API等のサービスを提供するサーバに対して複数のドメインからクロスドメイン通信させたい場合があります。しかし、HTTPレスポンスヘッダに書く事ができるCORSは1つだけです。そこで、クラウドデザインパターンです。Multi-CORSパターンと勝手に名付けました。ちなみに、この仕組みはAmazon S3のCORS設定で使われているものです。CORSRuleをXML形式でCORSルールを複数設定できるようになっています。以下はS3のCORS設定サンプルです。今回は、S3と同じようなことをWebAPIを提供するサーバ側で行ってみたいと思います。 <CORSConfiguration> <CORSRule> <AllowedOrigin>http://www.example.com</AllowedOrigin> <A
合わせて読んでください:Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
ごぶさたしております。 S3がCORS対応になったので、少し触れてみたいと思います。 CORSはCrossDomainResourceSharingの略です。 JSONPなどの特殊なケースを除いて通常ajaxなどではクロスドメイン通信は認められていません。 CORSは、通信先のサーバーで条件付きで許可をすることでクロスドメインアクセスを可能にするための仕組みで、W3Cで策定されいてる仕様です。モダンブラウザであればほぼサポートされているかと思います。 CORSではブラウザがクロスドメインのサーバーにリクエストする際に、事前にそのサーバーがこれから行おうとしているリクエストを許可しているかどうかをHTTPメソッドのひとつであるOPTIONSメソッドといくつかのHTTPリクエストヘッダを用いて問い合わせます。これをPreflightリクエストと言います。 そしてそのレスポンスをもってブラウザは
脱毛を考えるとき、病院でおこなうかエステでおこなうかで悩むと思います、どちらで施術したらよいのでしょう。 エステで脱毛をする場合と病院に行くのとは、違う特徴があります。 お互いのメリットとデメリットを良く調査して賢く選びたいですよね、ご紹介します。 続きを読む 女性で肌を見せるような服を着たいと思っていても、毛深いと勇気がいりますよね、そこで考えられるのが脱毛や除毛といった作業なのではないでしょうか。 しかし、こういった作業をしても「また生えてくるのでいちいち作業をするのが面倒」であったり「毛深くなるのではないか」といった心配が付きまといます。 除毛の場合、肌が荒れるといった心配もあるでしょう。 本当に毛深くなるのかという真偽のほどは今は置いておくとして、そんな時に考えられるのがエステでの脱毛や、医療機関での脱毛です。 広告による影響かもしれませんが、意外と皮膚科での脱毛を知らない方もいら
2010/12/10 コース:元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 IE8+jQueryによるクロスドメイン通信とXDomainRequestラッパーの作成 こんにちは、ネットエージェント株式会社、研究開発部の長谷川です。 さっそくですが、みなさんは「Advent Calendar」をご存じでしょうか? Advent Calendar と言えば、一般的には、クリスマス(12月25日)までの残り日数をカウントダウンするカレンダーを思い浮かべるかもしれませんが、ここで紹介する Advent Calendar とは、様々な業界、技術方面で活躍されているプログラマ有志が、毎日交代で1つずつ技術的なトピックスを紹介する技術系Webイベントのことです
クロスドメイン制限の回避について 今まではXHR(XmlHttpRequest)の仕様によりJSを読み込んでいるHTMLファイルがあるサーバから異なるドメインサーバへのAjaxリクエストが制限されていました。Same Origin Policyと呼ばれているものです。Same Origin Policyの役割としては悪意のあるscriptが個人情報等を他のサイトに転送する事を防ぐためです。このセキリティ制限を回避するために多くの人が代表的なJSONP(JSON with Padding)を利用してサーバサイドでクライアントのコールバック関数をechoしてクライアント側で実行されることにより、クロスドメイン間のAjax通信をそれっぽく動くように対応していたと思います。 JSONPについては以前記事を書いたので宜しければ参照してください。20秒で理解するJSONP - Yuta.Kikuchi
Ajaxでクロスドメイン通信について調べたのでまとめ。 シンプルな例 client var xhr = new XMLHttpRequest(); var url = 'http://example.com/xhr-response.php'; xhr.open('GET', url, true); xhr.send(); server <?php header('Access-Control-Allow-Origin: *'); echo "ok"; Access-Control-Allow-Origin: *を付けてレスポンスすると、エラーにならず結果を受け取れる。 クッキー付きの送信 client var xhr = new XMLHttpRequest(); var url = 'http://example.com/xhr-response.php'; xhr.withCrede
前回めでたくクロスドメインからレスポンスもらえるようになったけど、Cookieが送れなかった件。 参考をよーく見直してみたら、なんかCookieセットできそうな文章を発見。で、再度お試し。 RPC側を次のように修正。Access-Control-Allow-Credentialsヘッダーを追加する。 <?php header('Access-Control-Allow-Origin:http://localhost'); header('Access-Control-Allow-Credentials:true'); header('Content-Type:text/plain;charset=UTF-8'); $msg = ' World'; if(isset($_COOKIE['_test_'])) { $msg = ' Again'; } else { setcookie('_te
#基本的には、面倒な話なのであるが・・・この種のプログラムを作る上では避けられない・・・ Webブラウザーの基本的なセキュリティー実装方針として、"Same Domain Policy"というのがあり、Cookieではそれが適応されているが、XMLHttpRequest(XHR)を通じた接続はどのような状況であろうか? ユーザーが、example.com にアクセスした場合、cookieはexample.comにしかcookieを送信しないようにしているのは、ブラウザーの実装による。cookieの生成元にしかcookieを送信しない。これで、example.comとユーザーとの間のみで、プライバシーに関連するような情報を保護しようと言うのである。わかりました。同意です。 ただし、formタグからサブミットする先、scriptタグから読み込まれたスクリプトの実行は、このポリシーが適応されてい
なぜ通常のXMLHttpRequestにはクロスドメイン制約があるのに、JSONPではクロスドメインでリクエストを送信できるのか?不思議に感じたので、ちょっと調べてみた。 クロスドメイン制約は「ブラウザ上で実行されるJavaScriptは同じドメインにしかリクエストの送信やクッキーの編集を行えない」という制限である。 なぜこのような制限が必要になるのか。クロスドメイン制約がなかったらどうなるかを思考実験してみよう。ブラウザ上では、いくつものサイトからダウンロードしてきたJavaScriptが同時に実行されることは珍しくない。また、悪意のあるページにアクセスしてしまい、悪意あるJavaScriptを実行してしまうことも、十分に起こり得る話である。間違えて変なページにアクセスしたら致命的な問題が起きました、ではまずいので、ブラウザではJavaScriptができる事にかなりの制限を与えている。X
JavaScriptに限らず浮動小数点の演算では以下のような誤差が発生します。 > 0.1 + 0.2 0.30000000000000004 > 1.13 * 100 112.99999999999999 お金の計算で四捨五入や切り上げ、切り捨てなどが絡む場合はこういった誤差が致命的だったりします。このような場合、JavaではBigDecimalを使ったりしますが、JavaScriptには同様のライブラリとしてbignumber.jsというものがあるようです。 https://github.com/MikeMcl/bignumber.js/ 使い方は簡単でこんな感じ。 > new BigNumber(0.1).plus(0.2).toPrecision() "0.3" > new BigNumber(1.13).times(100).toPrecision() "113" 四捨五入や切り
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く