Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

Webアプリのデバッグやチューニングに役立つ、Chrome Developer Toolsの主要機能を、スクリーンキャプチャ中心で簡潔に紹介。2014年10月に最新情報に改訂。 モダンブラウザーの中でGoogle Chromeは最後発ながら、その機能の潤沢さ、便利さ、高速さからシェアを大きく伸ばしている。そして、今やほとんどのブラウザーではWindowsの場合F12キーを押すことで(Macの場合はCommand+Option+Iキーで)手軽に各ブラウザー搭載のデベロッパーツールを利用できるが、特にChromeのデベロッパーツールは、非常に機能が豊富なため、利用している人もかなり多い。 本稿では筆者がよく使う機能や、使うと便利な機能を中心に、Chromeのデベロッパーツールについて紹介していく。なお、本書は執筆時点で、最新のChrome 38を使用している。 機能ふかん 残念ながら、Chro
canonical属性とは/link rel="canonical"によるURL正規化タグ——SEOにとって非常に重要な進歩(前編) | Moz - SEOとインバウンドマーケティングの実践情報 | Web担当者Forum http://web-tan.forum.impressrd.jp/e/2009/03/05/5112 そのため、その正規化されたURLは、その Web ページの作成者が、その Web ページをどんな URL として扱って欲しいのかを明示的に示したものです。 従って、Webページの URL をブラウザ側で動的に取得しようとした場合、location オブジェクトから取得する場合には、URL の表記に様々なバリエーションが生まれてしまいますが、正規化された URL を用いれば、そのコンテンツに対する URL を一つに限定できます。 正規化された URL は、次のように H
javascript:WebページのURLをlocationからではなく、HTML文書中のcanonicalから取得する理由 イントロダクション javascriptにて、ブラウザ側で動的にURLを取得する場合には、locationオブジェクトからではなく、ref 属性に "canonical" が指定された link タグの href からURLを取得する理由を記載します。 ただし、ref 属性に "canonical" が指定された link タグは、webページのHTML内に必ずあるものではないため、無い場合には代替手段として locationオブジェクトから取得するなどの方法を行う必要があります。 Webページの URL をブラウザ側で動的に取得しようとした場合に考慮すべきこと Webページの URL をブラウザ側で動的に取得しようとした場合、考慮すべきことがあります。 それは、W
実験用コード: <form onsubmit="return false;"> <b>input_text:</b><br /> <textarea id="input-text" rows="4" cols="80"> ">Hello!</textarea><br /> 例)">Hello!<br /> <input type="button" value="実行" onclick="runTest_setAttribute_outerHTML();" /><br /> </form> <br /> <b>element.setAttribute("title", input_text)のouterHTML:</b><br /> <textarea id="output-html" rows="4" cols="80"> ここにデータ出力 </textarea><br
JavaScript:document.createTextNodeをappendChildしたときの、HTMLはどうなっているか? イントロダクション JavaScript にて、「DOM Based XSS」の脆弱性を埋め込むのを防ぐためには、document.write や element.innerHTML などを使うのではなく、以下のように DOM 操作用メソッドを使用すると良いとされています。 入力されたテキストをブラウザのドキュメントに表示: element.appendChild(document.createTextNode(input_text)); input_text : 入力されたテキスト element : テキストを追加する親要素(element オブジェクト) このとき、テキストを追加した親要素の HTML が、入力されたテキストによってどうなるのか気になり
セキュリティ対策:JavaScriptでHTML操作をする人は必読!IPAテクニカルウォッチ 『DOM Based XSS』に関するレポート イントロダクション 誰でも手軽に使えて便利な JavaScript ですが、書き方を間違えると重大なセキュリティ上の問題(脆弱性)を引き起こしてしまいます。 そんな JavaScript を使ったプログラムの脆弱性の中でも、うっかり作りこんでしまいがちなのが、「DOM Based XSS」ではないでしょうか? DOM Based XSS は、JavaScript を使用して、ブラウザで表示している HTML 構造に手を加えるときに埋め込んでしまいがちな脆弱性です。 例えば、ブラウザで表示している画面を、document.write や element.innerHTML などで書き換えていませんか? (それら以外にも、危険なメソッド・プロパティはあり
ここ数年、XSS業界の最先端で盛り上がっている話題として mXSS というものがあります。mXSS - Mutation-based XSS とは、例えば innerHTML などを経由してすでに構築されているDOMツリーを参照したときに、本来のDOM構造とは異なる結果を得てしまい、そのためにHTML構造の破壊を引き起こすという類のDOM based XSSの亜種とも言えます。 mXSSに関しては以下の資料などが参考になります。 The innerHTML Apocalypse mXSS Attacks: Attacking well-secured Web-Applications by using innerHTML Mutations どちらの資料にも掲載されていますが、mXSSのきっかけとなったのは 「教科書に載らないWebアプリケーションセキュリティ(1):[これはひどい]IEの
最近、なんというか、フロントエンド勉強会に出席する度に、「フレームワークじゃねぇんだ! MVC設計がな! 」とか言い続けている気がする。たくさんフレームワークが出てきて、○○フレームワークの問題とか、開発の困難の話を聞く度に、自分の設計を棚に挙げて、「これは、フレームワークがスケールできないせいだ!」「jQueryが糞」とか言ってて、「何言ってんの?コイツ?」みたいな気分になる。 最近になって、なんでこの状況がいつまでたっても変わらないんだろう? って理由が分かってきた。フロントエンドできない人が、フロントエンドやりすぎなのだ。 なんでフレームワーク使うの? そもそも、なんでフレームワークを使うか?ってことに答えられない人が多い気がする。というか、大抵「上司が決めたから」とか「チームで決まっているから」という答えが返ってくる。そもそも、フレームワークを強制して学習させる環境になっている現場
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く