ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
Intel NUC で自宅 Ubuntu 開発環境構築と SSH Port Forwarding によるアクセス | blog.jxck.io
Intro 家では Mac を使っていたが、やはり Ubuntu 開発環境を作ることにした。 前々から気になっていた Intel NUC をベースに Ubuntu 環境を構築。 また、外出時もアクセスできるように SSH Port Forwarding を使って、固定 IP の無い家に外からアクセスできるようにした。 備忘録を兼ねて記す。 自宅開発環境 自宅では長らく Mac を使ってきたが、やはり Linux 環境があったほうが良いということで、数年ぶりにラップトップ以外の PC の購入を検討した。 自宅サーバとして使えれば、宅内オートメーションや、さまざまな用途にも流用できて、遊ぶ上でも良いだろう。 今は mini PC も色々出ており、選択肢も多く、比較的安価に、場所をとらないサーバが組めるようになった。 これを期に、高い Mac の買い替え更新をやめ、 Air などの持ち運び用途に
Cookie の性質を利用した攻撃と Same Site Cookie の効果 | blog.jxck.io
Intro Cookie はブラウザによって保存され、紐づいたドメインへのリクエストに自動で付与される。 この挙動によって Web におけるセッション管理が実現されている一方、これを悪用した攻撃方法として、 CSRF や Timing Attack などが数多く知られており、個別に対策がなされてきた。 現在、提案実装されている SameSite Cookie は、そもそもの Cookie の挙動を変更し、こうした問題を根本的に解決すると期待されている。 Cookie の挙動とそれを用いた攻撃、そして Same Site Cookie について解説する。 Cookie の挙動 Cookie は、 Set-Cookie によって提供したドメインと紐づけてブラウザに保存され、同じドメインへのリクエストに自動的に付与される。 最も使われる場面は、ユーザの識別子となるランダムな値を SessionI
Promise.allSettled と Promise.any | blog.jxck.io
Intro Promise.allSettled() と Promise.any() の仕様策定が進んでいる。 両者は近いレイヤの仕様では有るが、作業の進捗には差がある。 Promise.allSettled は Stage 4 であり、 Chrome や Safari TP には実装もされている Promise.any は Stage 2 であり、実装はまだない ここでは、これらがあると何が嬉しいのかを Promise.all(), Promise.race() の特徴を踏まえて解説する。 Promise.all()/race() Promise.all(), Promise.race() は、いずれも複数の Promise をまとめて処理する Utility Method のようなものである。 all は全ての Promise が Resolve したら Resolve し、 race
画像最適化戦略 Lazy Loading 編 | blog.jxck.io
Intro 長らく議論されてきた <img> や <iframe> における Lazyload について、仕様と実装が動きを見せている。 ここでは、特に画像 <img> に注目し、 Lazyloading の議論の変遷を踏まえた上で現状を解説する。 画像最適化シリーズ第 5 回目のエントリである。 画像最適化戦略 PNG/JPEG 編 画像最適化戦略 Picture 編 画像最適化戦略 WebP 編 画像最適化戦略 SVG/Font 編 > 画像最適化戦略 Lazy Loading 編 Lazyloading 画像や iframe の埋め込みは、読み込むサイズも大きく、処理が同期であるため、レンダリングのボトルネックになりやすく、それらが多いページでは初期表示の遅延の原因となることが多くあった。 特に縦に長いページでは、最初にユーザが見えている領域 (Above the Fold) では表
Referrer-Policy によるリファラ制御 | blog.jxck.io
Intro リファラはリンクなどでページを遷移する際に、遷移元の URL をリクエストの Referer ヘッダに載せる仕様である。 この付与はブラウザが自動で行うため、場合によっては非公開として扱っている URL が意図せず漏れることがある。 この挙動を制御することができる、 Referrer-Policy ヘッダについて解説する。 Referer or Referrer 本来の英語としては RefeRRer が正しいが、 HTTP Header ではスペルミスした RefeRer が互換性を保つためそのまま使われている。 しかし、新しく定義された Referre-Policy は、正しいスペルが採用されている。 Referer ヘッダ 例えば https://example.com/index.html に貼られたリンクから https://blog.jxck.io に遷移する場合を考
Linux で出力を別の shell に pts 経由で表示する | blog.jxck.io
Intro tmux, screen, terminal のタブなど、 shell を複数起動する方法はいくつかある。 Linux では、 pts を経由すれば、ある shell の出力を簡単に別の shell で表示することができる。 これを応用すると、簡易ダッシュボードを作り色々便利に使うことができる。 stdout/stderr 代表例として、 tmux で pane を分割し、コマンドの出力を stdout/stderr で分けて pane ごとに表示するケースで解説する。 まず、以下のようにランダムにエラー出力を吐くプログラムを実行する。 #!/usr/bin/env ruby while true do if rand(0..1) == 0 then STDOUT.print "hello\n" else STDERR.puts "world\n" end sleep(1) e
.mjs とは何か、またはモジュールベース JS とエコシステムの今後 | blog.jxck.io
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
Noto Sans の Web Font 対応とサブセットによる最適化 | blog.jxck.io
Intro このサイトのフォントに Web Font を適用することにした。 フォントには Google と Adobe が協同で開発した Noto Sans CJK JP を採用した。 また、このサイトでは使用しないだろう文字を削除したサブセットを作ることで、フォントサイズを最適化した。 フォントサイズの最適化 Noto font は、そもそも豆腐(フォントがなかった場合に代替表示される四角)が出ないように(No-豆腐)することをコンセプトにしているため、フォントの網羅率は非常に高い。 そのため Web Font として利用する場合は、全体だとサイズが大きすぎるため、言語毎に提供されるフォントセットの中から、必要なフォントのみを適用することになる。 本サイトでは、 ASCII 、記号、日本語のフォントを用いる。 しかし、特に網羅された漢字の中には、日常では使わない文字が多々ある。 加えて
Cache-Control の Immutable 拡張によるリロード時のキャッシュ最適化 | blog.jxck.io
Intro ブラウザはリロード時に、 max-age に満たないキャッシュを持っていても Conditional GET によってキャッシュの Validate (有効性の問い合わせ)を行う。 Cache-Control Extension として提案されている Immutable 拡張は、キャッシュが max-age 内であればリロード時もキャッシュヒットさせる拡張である。 このヘッダの効果と、本サイトへの適用について記す。 Cache-Control Cache-Control に max-age を指定することで、ブラウザにリソースをキャッシュさせることができる。 このキャッシュは max-age の期間内は fresh とみなされ、 fresh であればサーバへの問い合わせなく再利用される。 サーバへの問い合わせ(RTT)が無いため、事実上最速のリソース取得となる。 Reload
リンクのへの rel=noopener 付与による Tabnabbing 対策 | blog.jxck.io
なお IE は(security zone setting をいじらない限り)この問題が発生しないようだ。 引用元: blankshield demo | Reverse tabnabber phishing tabnabbing 上記の挙動を、フィッシング詐欺に利用できることが既に指摘されている。 この手法は Tabnabbing と呼ばれている。 Tabnabbing: A New Type of Phishing Attack Aza on Design Target="_blank" - the most underestimated vulnerability ever この攻撃方法を解説する。 攻撃の概要 https://cgm.example.com (左上) というサービスがあるとし、これは SNS やチームコラボレーション系サービスを想定する。 攻撃者は、このサービスの不
Stale-While-Revalidate ヘッダによるブラウザキャッシュの非同期更新 | blog.jxck.io
Intro システムにおいてキャッシュの設計は永遠の課題であり、 Web のパフォーマンスにおいても非常に重要である。 Web では、 HTTP ヘッダを用いてブラウザやプロキシにキャッシュの制御を指定する。 Stale-While-Revalidate ヘッダは、このキャッシュ制御に選択肢を追加する新しい仕様である。 このヘッダの概要と、本サイトへの適用を解説する。 Web におけるキャッシュ キャッシュの種類 まず、ブラウザが持つ従来のキャッシュの機構について整理する。 そもそも、キャッシュを行う意義は大きく二つある。 リソースの取得を高速化する サーバへの負荷を減らす これまでは HTTP ヘッダを用いて、キャッシュを管理させる方法を用いてきた。 Web における、キャッシュの指定には大きく二つの方式がある。 ブラウザはリクエストを発行せず、保持するキャッシュを使用する(Cache-
HTTP Strict Transport Security(HSTS) 対応 | blog.jxck.io
Intro 本サイトにて HTTP Strict Transport Security (HSTS) を有効化した。 includeSubdomains を用いた *.jxck.io 全体への適用および、ブラウザへの Preload 登録も検討したが、本サイトの特性上それは見送った。 導入に必要な設定や、注意点についてまとめる。 HSTS 本サイト (blog.jxck.io) では、フル HTTPS 化が完了しており、 HTTP へのリクエストは全て HTTPS へリダイレクトしている。 特に本サイトのタイトル自体が blog.jxck.io であり、ドメイン名と同じになっているため、これが Twitter などで http://blog.jxck.io へのリンクと解釈される場合が多く、そこからの HTTP アクセスも少なくはない。 しかし、 MITM の脅威への対策が可能な HTTP
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
