タグ

ブックマーク / blog.jxck.io (9)

  • 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

    Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、当にプラットフォームに足りていなかったものと、それを補っていった経緯、当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

    令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
  • なぜ 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

    なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
  • Public Suffix List の用途と今起こっている問題について | blog.jxck.io

    Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ

    Public Suffix List の用途と今起こっている問題について | blog.jxck.io
  • ローカル開発環境の https 化 | blog.jxck.io

    Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う

    ローカル開発環境の https 化 | blog.jxck.io
    sugumura
    sugumura 2020/06/29
    わかりみ。
  • 牧歌的 Cookie の終焉 | blog.jxck.io

    Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る

    牧歌的 Cookie の終焉 | blog.jxck.io
  • Web における技術の解釈とエコシステムによる合意形成プロセスについて | blog.jxck.io

    Intro 「ユーザが意図する挙動」とは何か。技術的に可能であるが「やらない方が良いこと」は、誰がどう決めるのか。 Web には仕様、実装、デプロイ、そしてユーザの利用とフィードバックによって、そうした合意がゆるやかに形成されていく仕組みがあると筆者は考えている。 しかし、これは明文化されているわけでもなく、その全体像を把握するのは一般には難しいだろう。 今回は、ちょうど何度目かの議論が再発している ping 属性を例に、この合意形成の概観について解説を試みる。 リンクの ping 属性 <a> には ping という属性があり、以下のように URL を指定する。 <a href=https:example.com ping=/path/to/report>example.com</a> HTML Standard - ping Attribute このリンクは、クリックすると https

    Web における技術の解釈とエコシステムによる合意形成プロセスについて | blog.jxck.io
  • 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

    Private Class Field の導入に伴う JS の構文拡張 | blog.jxck.io
  • Fetch の中断と Promise のキャンセル方法の標準化 | blog.jxck.io

    Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを

    Fetch の中断と Promise のキャンセル方法の標準化 | blog.jxck.io
  • 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

    JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
  • 1