令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio
XMLHttpRequest とはなんだったのか | blog.jxck.io
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
Puppeteer で静的サイトの Font Subsetting | blog.jxck.io
Intro Web Font のサブセット化を Font Weight に応じて作り分けるとともに、それを Puppeteer を用いて生成するように変更した。 Web Font の静的サブセット 本サイトで提供している Web Font は当初、文字を事前に選定して生成したものを使っていた。 Noto Sans の Web Font 対応とサブセットによる最適化 当時はコンテンツがなかったが、コンテンツも増えた後は、コンテンツの原稿である markdown ファイルから使用している文字を抽出して生成するように変更していた。 これでおおよそ必要最小限のサイズにすることができていた。 Regular と Bold の最適化 本サイトでは Font Weight として Regular(400) と Bold(700) を提供しているが、これまでは抽出した文字種を Bold/Regular 両
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
Private Class Field の導入に伴う JS の構文拡張 | blog.jxck.io
Intro ECMAScript の Private Class Field の仕様策定と各ブラウザの実装が進んでいる。 これにより、従来の JS にはなかった Class の Private フィールドが使えるようになる。 提案されている構文や、挙動について解説する。 Class Field Declaration まず前提として、現状の Class の フィールドはコンストラクタで定義する必要がある。 例えば count フィールドを持つ Counter クラスを定義した場合、以下のようになる。 class Counter { constructor() { this.count = 0 } increment() { this.count ++ } display() { console.log(this.count) } } const c = new Counter() c.in
JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
Intro textarea などに入力された文字数を、 JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、 BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID
Noto Sans の Web Font 対応とサブセットによる最適化 | blog.jxck.io
Intro このサイトのフォントに Web Font を適用することにした。 フォントには Google と Adobe が協同で開発した Noto Sans CJK JP を採用した。 また、このサイトでは使用しないだろう文字を削除したサブセットを作ることで、フォントサイズを最適化した。 フォントサイズの最適化 Noto font は、そもそも豆腐(フォントがなかった場合に代替表示される四角)が出ないように(No-豆腐)することをコンセプトにしているため、フォントの網羅率は非常に高い。 そのため Web Font として利用する場合は、全体だとサイズが大きすぎるため、言語毎に提供されるフォントセットの中から、必要なフォントのみを適用することになる。 本サイトでは、 ASCII 、記号、日本語のフォントを用いる。 しかし、特に網羅された漢字の中には、日常では使わない文字が多々ある。 加えて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
