最近質問サイト等でCORS(Cross-Origin Resource Sharing)に関する質問が急増していますが、その多くがCORSの原理をまったく理解せずに、とにかくCORSの制限を回避して動かす方法を求めるように見受けます。しかし、CORSはブラウザのセキュリティ機能なので、原理を知らないまま「動けばよい」ことを求めると重大な脆弱性の原因になりかねません。この動画では、CORSの原理、特に「なぜCORSはこうなっているのか」にフォーカスして説明します。
r7kamura さんや kzys さん に倣って、このウェブサイトの実装を紹介してみる。 ホスティング Google Firebase Hosting を使って静的ファイルを配信してる。一部動的な実装に関しては、Cloud Functions for Firebase を使っている。静的ファイル配信は今は Netlify や Surge など、基本無料で超簡単に配信ができて高速なものが多々出てるのだけど、Hosting に限らず Firebase の他のサービスとの連携が楽、という理由で Firebase Hosting を使っている。 また最近の仕事でのサーバサイドはほぼ Firebase 製品ですませていることもあって、Firebase でなんかやる、というのが技術的にもやりやすいから、というのもある。 なお画像はストレージをだいぶ食うため、はてなフォトライフにアップロードして使って
はてなブログでSREをやっているid:cohalzです。 2019年12月頃からid:utgwkkやid:onkとともに、はてなブログにおけるキャッシュ周りの改善を行いました。その結果、次のような成果が得られました。 ブログ記事のキャッシュヒット率が、1日平均で8％から58％に向上 アプリケーションサーバの台数を、以前の半数以下に削減 DBに届くリクエスト数が、以前の3分の2まで減少 レスポンスタイムの平均が、以前の8割まで減少 この記事では、実際にどういった改善を行ったのか、その際に気をつけたことや大変だったことを紹介します。 はてなブログがVarnishを導入した経緯と課題 開発合宿をきっかけに問題が明らかになる 進め方をまず考える ホストのメモリをできるだけたくさん利用する メモリを積んだホストでなぜかレイテンシが悪化 キャッシュが分散しないようVaryヘッダを使う デバイス情報を適
ただのページ遷移をしたいだけなのに、（主に手抜きという）実装の都合で JS の location.href になってることはありませんか？ 実はそれ、体験を損ねているかもしれませんよ。 起こる出来事 マウスのホイールクリック（ミドルクリック）で別のタブで開けません。 Mac にはマウスホイールなんてついてないだろ？ 実は Cmd+クリックも同様に別のタブで開けないんですよ。 スマホだったら長押しに相当すると思います。 したがって、意図して別タブで開かせたくない場合を除いて、location.href での遷移は避けるべきです。 厳密には JS の処理内での遷移させるのを避けよう、というべきですね。 なので Router の API を直接コールしての遷移も同様です。 できるだけ <a href="url"> になるようなコードが望ましいです。 SPA（React, Vue, Angular
こんにちは、フロントエンドエキスパートチームの小林（@koba04）です。 フロントエンドエキスパートチームでは、日々の業務としてブラウザやライブラリの更新情報をキャッチアップして社内で共有しています。 例えば先日、CSSのプロパティである image-orientation のデフォルト値が none から from-image に変わったため、画像の Exif 情報の扱いが変更されました。 https://www.fxsitecompat.dev/ja/docs/2020/jpeg-images-are-now-rotated-by-default-according-to-exif-data/ 注： Firefox では COVID-19 の影響により、この変更は延期されました。（Chrome は予定通り 81 で リリースしています） https://blog.chromium.o
こちらは翻訳記事となります。原著者の許諾を得て翻訳・公開しております。 英語記事: The History of the URL原文公開日: 2020/03/05著者: Zack BloomURL: https://blog.cloudflare.com/the-history-of-the-url/ 1982年1月11日、22 人のコンピュータ科学者が「コンピュータメール」(今日の電子メール）の問題を議論するために集まりました。議論の参加者にはサン・マイクロシステムズを作った人、Zork の開発者に NTP の開発者、そして政府に Unix の支払いをするように説得した人も含まれていました。 問題は単純で、 ARPANET にある455台のホストが制御不能に陥っていたのです。 この問題は、ARPANET がもともとの NCP プロトコルから、今日の”インターネット”と呼ばれる TCP/I
Web ブラウザーは通常 HTTP 要求の Referer: ヘッダーに参照元ページの URL を入れますが (あるいは document.referrer で参照元ページの URL を取得できますが)、 Web サイト側でこれを制御したいことがあります。 例えば、次のような場面が想定されます。 URL にユーザー名や秘密の ID などを含めざるを得ない時は、プライバシーやセキュリティーの観点から、この URL を外部に漏らしたくありません。 社内システムに URL を貼りたいことがありますが、社内システムの URL を外部に漏らしたくありません。 Web アプリケーションの開発用サーバーは、その所在を外部に漏らしたくありません。 投稿者と友達のみに公開される SNS の投稿にリンクが含まれる時、その個別 URL を漏らしたくありません。 (SNS 全体の URL が漏れることは問題ありま
今年もChrome開発者の集まりChrome Dev Summit 2019 (CDS) がサンフランシスコで開催されました。 今回、私が Chrome Customer Advisory Board (CAB) に選出していただいたこともあり、CDSに初めて参加しました。 これは、CDS終了後のCAB meetingで頂いたChrome Dinosaurフィギュアです。ちなみにゲームはできません。 タイトルの「なぜChromeはURLを殺そうとするのか？」は、2日目Chrome Leadsのパネルセッションで司会のGooglerが、Chrome UX担当のProduct Managerに対して一番最初に投げかけた問いです。 PMは直ちに「そんなことはしない」と即答しました。しかしChromeは、URLの表示領域からHTTPSの緑色表示の廃止・EV表示場所の移動・wwwサブドメイン表示の削
2Captchaとは 2Captcha公式ページ ロシアの会社が開発したreCAPTCHAを突破するためのプラットフォームです。 通常であれば、プログラムからreCAPTCHAにチェックをいれることは、ほぼ不可能レベルだと言われています。 では、なぜ2Captchaを使うだけで、可能なのでしょうか。 2Captchaの仕組み 2Captchaの仕組みを簡単に説明すると、reCAPTCHAのチェックボタンをネット上の『Worker』と呼ばれている人達に代わりに押してもらっているイメージです。 PythonのSeleniumで説明すると、プログラムの実行中にWorkerの誰かがリアルタイムで解錠した結果を2Captcha経由で受け取ると言ったところでしょう。 なので、2Captchaはプログラムで解錠しているように見えるけど、実際は人力…みたいなオチです。 使用方法 2Captchaを使うため
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ある日の我が家 娘**（４歳）「パパ、セッションとかCookie**ってなあに？」 娘「サーバサイドの勉強してると出てくるやつ」 ワイ「おお、今日はその質問か」 ワイ「ええでええで〜、パパが教えたるで〜」 娘「わ〜い！」 ワイ「ワ〜イ！」 例えば月曜日 ワイ「例えば、月曜日の朝は仕事する気にならへんからTwitterを見るやろ？」 娘「うん！」 ワイ「せやからTwitterのホーム画面を見るために」 ワイ「ブラウザのアドレスバーにhttps://twitter.com/homeって打ち込むんや」 ワイ「まぁ実際にはブックマークから行くん
- はじめに - 最近はWebスクレイピングにお熱である。 趣味の機械学習のデータセット集めに利用したり、自身のカードの情報や各アカウントの支払い状況をスクレイピングしてスプレッドシートで管理したりしている。 最近この手の記事は多くあるものの「～してみた」から抜けた記事が見当たらないので、大規模に処理する場合も含めた大きめの記事として知見をまとめておく。 追記 2018/03/05： 大きな内容なのでここに追記します。 github.com phantomJSについての記載が記事内でありますが、phantomJSのメンテナが止めたニュースが記憶に新しいですが、上記issueにて正式にこれ以上バージョンアップされないとの通達。 記事内でも推奨していますがheadless Chrome等を使う方が良さそうです。 - アジェンダ - 主に以下のような話をします。 - はじめに - - アジェンダ
- はじめに - この記事は Webスクレイピング Advent Calendar 2017 - Adventar の1日目の記事です。 近年では、Pythonが様々な場面で使われるようになりました。 Webからデータを取ってくる際のスクリプトとして利用し、そのままデータを機械学習における学習データとするといった案件も多く見るようになっています。 ありがたい事に本年度書きました以下の記事は、はてなブログに投稿されたPython関連の記事の中で歴代はてブ数1位だそうです。 Webスクレイピングも日に日に情報が増え、様々なパッケージやフレームワークによって手軽になっています。 本記事は、スクレイピングやクローラを記述する際に抜けがちな、「規約」について記載するものです。 スクレイピングの間隔はどうすればいい？規約は？違法でないの？という人のために法律等もまとめています。 追記2019/01/0
AMP（Accelerated Mobile Pages）がオープンソースとして立ち上げられてから数年が経ちました。食べログなどの大手Webサービスが対応し、また簡単にAMP対応できるWordPressプラグインが出たことで、今では一般に浸透してきた感じを持っています。 ただ「表示高速化技術」「一瞬で表示する技術」というのは正しくないのでやめませんか？ AMPはWeb Componentsフレームワークまず誤解されがちなのですが、AMPは新たな技術ではなく、Web標準の「Web Components」というAPIを用いて実装されています。AMPのGitHubページにもしっかりと「The AMP web component framework.」（AMPというWeb Componentsを用いたフレームワーク」と掲載されています。 Web Componentsは、再利用可能でカプセル化された
CSS読み込みの<link rel="stylesheet">は同期なので、レンダリングブロックします。 どういうことかというと、CSSファイルの読み込み・パースが終わるまで画面描写が止まってしまいます。 これに対策する方法としてpreloadというものが策定されましたが、対応状況が微妙です。 2019年7月時点でもブラウザシェアが8割しかなく、Firefoxは当面対応するつもりがないようです。 とはいえ残り2割のためにloadCSSを突っ込んだりとか始めると本末転倒感に溢れます。 全ブラウザ対応のためには、なんにしろ結局JavaScriptをこりこり書くしかない状況でした。 が、なんかすっごい簡単な対処法があったので紹介してみます。 以下はScott Jehlによる記事、The Simplest Way to Load CSS Asynchronouslyの日本語訳です。 ちなみにSco
The latest news from Google on open source releases, major projects, events, and student outreach programs. Originally posted on the Google Webmaster Central Blog For 25 years, the Robots Exclusion Protocol (REP) was only a de-facto standard. This had frustrating implications sometimes. On one hand, for webmasters, it meant uncertainty in corner cases, like when their text editor included BOM char
ウェブページの寿命: 2001 年に存在した 1000 万ページを対象にした調査 宮田洋輔（常葉大学短期大学部） m@miyay.org 安形輝（亜細亜大学），池内淳（筑波大学） 石田栄美（九州大学），上田修一（前慶應義塾大学） 抄録 ウェブページの寿命を明らかにするため，2001 年に収集された 1,000 万件のウェブページを対象に， 長期的な生存調査を実施するとともに，Internet Archive を利用して，ウェブページがいつ誕生し，いつ消 失したのかに関する調査を行った。生存調査の結果，9 割以上のページが収集から 12 年を経た現在，消 失していることが明らかになった。寿命調査の結果，2001 年に収集され現在消失しているウェブページの 平均寿命は，1,108.2 日であることが明らかになった。 1. はじめに ウェブは，公開後も容易に更新でき，削除できる など，従来のメデ
Googleのエンジニアらは、Portalsという新たなテクノロジーがウェブの世界で普及し、リンクをまたがるウェブサイト間の遷移のための標準的な方法になってほしいと考えている。 例えばエンジニアらは、ユーザーがニュースサイトを閲覧しており、記事の末尾に達した際に、<portal>タグを用いて埋め込まれた関連記事へのリンクをクリックすれば、シームレスに該当ページに遷移できるという目的で使われるようになってほしいと考えている。 従来のリンクに比べた利点は、Portalsがユーザーによるページのスクロール中に<portal>タグ内のコンテンツを先にロードし、新規ページへの展開準備をしておくことで、ロード時の待ち時間をなくせるというものだ。 この機能が最初に発表されたのは2018年11月に開催された「Chrome Dev Summit」だったが、Portalsは7日から「Android」と「mac
関連記事 WebTransport over QUICのサンプルサーバを試してみる - ASnoKaze blog WebTransport over HTTP/2 の仕様について - ASnoKaze blog WebTransport over QUIC について - ASnoKaze blog WebTransportという新しい双方向通信フレームワークの議論が始まっている。 GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。 discourse.wicg.io WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。（実際に使用する"トランスポート"はプラガブルな設計にな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く