はじめに モダンブラウザで使われるファビコンの作り方を見直して、今こそアイコン生成であくせくするのを終わりにしましょう。昨今のフロントエンド開発者は、ブラウザタブやらタッチ画面やらにWebサイトの小さなロゴを表示する、ただそれだけのためだけに静的なPNGファイルを20個以上扱わなければなりません。よりスマートな方法で、現代のニーズに合う最小限のアイコンセットを使う方法を紹介します。 ファビコンは見かけよりもずっと幅広く奥深いトピックで、実は誰もがファビコンについてしっかり学びたいと思っていることもわかってきました。本記事全体の内容を実質わずか2行のスニペットに凝縮したものも紹介していますので、今ファビコンで苦しんでいる方は（正確な使い方をご存知なら）そちらをお使いいただけますが、そこをぐっとこらえて記事を最後までお読みいただくことをおすすめいたします。 🔗 忙しい人向け: ウルトラショー
最近のデバイスやブラウザに対応させる最小限のファビコンセットには、6種類のファイルで対応できます。ブラウザはもちろん、スマホやタブレットにも対応し、さらにSVGも含めて6種類だけです。 ファビコンに必要な6種類のファイル、ファビコンの設定方法、ファビコン画像を作成する方法について紹介します。 How to Favicon in 2024: Six files that fit most needs by Andrey Sitnik Sitnik氏は、PostCSS, Autoprefixer, NanoIDの制作者です。 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 2024/2/28: 元記事がアップデートされたので、当記事もアップデートしました。 はじめに ファビコンの設定方法 -ショートバージョン ファビコンの設定方法
去る2021年10月23日に開催されたKaigi on Rails 2021にて、弊社の@ohbaryeが "Safe Retry with Idempotency-Key Header" というタイトルで発表してきました。 発表スライドはSpeakerDeckにて公開済みです。 後日アーカイブ動画も公開されるとのことですのでそちらも是非ご覧頂きたいのですが、おとなしく30分の動画を視聴できるほど現代人は暇じゃないですよね。なので本記事の前半では忙しい人のために発表内容を1/10ぐらいの密度で解説してみます。 (2021-10-31追記) 動画が公開されました 🎉 www.youtube.com (2021-10-31追記おわり) ただ、それだけでは配信動画をすでに視聴いただいた方への新規情報がゼロになってしまうので、後半では発表に関していただいたtweet・質問・感想へのコメントへのリ
キャッシュを防ぐHTTPヘッダの鉄板 他人のアカウント情報がキャッシュからレスポンスされてしまう（いわゆる別人問題）といった事故を防ぐために、HTTPヘッダでキャッシュを制御する、というものがセキュリティのお話では頻出します。 そして、その場合の鉄板的なベストプラクティスが、以下のHTTPヘッダを追加することです。 Cache-Control: private, no-store, no-cache, must-revalidate Pragma: no-cache 本記事では、キャッシュを防ぐためにはなぜ上記のHTTPヘッダが必要なのかについて解説します。 各ディレクティブについて 本文に入る前に、Cache-Controlのディレクティブについて簡単な説明を載せておきます。 private ローカルへのキャッシュの格納のみを許可する。また、通常キャッシュできないパターンもキャッシュされ
この記事はシステムエンジニア Advent Calendar 2015 - Qiitaの記事です。 弊社アーキ部で@kawasimaさんに教えてもらったさいきょうの二重サブミット対策について書いていきます！ 二重サブミットが発生するケース 不正な更新リクエストが発生するケースとして、以下のものが考えられます。 サブミットボタンをダブルクリックする 戻るボタンで戻って、再度保存ボタンを押す 完了ページでブラウザリロードする CSRF攻撃による不正な更新リクエスト 1. サブミットボタンをダブルクリックする 確定ボタンをダブルクリックすることによって、ユーザが意図していないリクエストが発生してしまうケース。 2. 戻るボタンで戻って、再度保存ボタンを押す 処理完了画面から戻るボタンで前の画面に遷移し、再び確定ボタンを押すケース。 本来は入力➡︎確認➡︎完了の画面遷移が適切だが、その画面遷移にな
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
文字コードの異なるページへのPOSTって悩ましいですよね。 具体的には、こちらのサイトがUTF-8で作られていて、相手先がShift_JISだったりする場合。 そもそも相手サイトにPOSTしなきゃいけない理由とは SPAMサイトじゃあるまいし、普通は自サイト以外へのPOSTってあんまり考えられないかも知れません。 でも、実際はあるんです。例えばECサイトが良い例。 「ご購入ありがとうございました。決済手続きは次の画面でお願いします。」 みたいなの。 いまどきそんなの古いよーという方もいらっしゃるかも知れませんが、きっとそれは大手の通販サイトを使用されていることが多いからでしょう。ショッピングモールにさえ出店しない、個人商店レベルのサイトではこんなのいっぱいあります。 中の人いわく、「個人経営のショップサイトでクレジットカード番号を入力するのは怖いというお客様がいらっしゃる」とか。なるほど、
Amplify has re-imagined the way frontend developers build fullstack applications. Develop and deploy without the hassle. Fullstack TypeScriptWrite your app's data model, auth, storage, and functions in TypeScript; Amplify will do the rest.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? プログラミング言語やフレームワークに関する疑問をググるとだいたいQiitaの記事がヒットして、開くたびにアカウント登録しろしろとうるさいのでキレながらアカウント作りました。サブカルメンヘラクソ女の@hg0です。折角なのでアカウント登録のついでに書こうと思います。 大学は芸術系で、デザインやメディアアートをかじっていた程度なのですが、縁があってWebエンジニア業界に就職することが出来ました。 2年ほど、フロントエンドのお仕事・勉強をさせて頂いて思ったこと、躓いたこと、各言語やフレームワークを使って思ったことを振り返りながら書いてみようと思
2013年4月20日(土) 11時23分03秒 [Web関連] 「キャッシュのせいだから再読込して」と毎回言わなくて済むようにする記述方法 ブラウザにはキャッシュ機能がある……のだが、 たいていのブラウザには、通信量を削減して表示速度を向上させるために、一度ダウンロードしたデータはローカル（HDDなど）のキャッシュ領域に一定期間ほど保存しておく機能があります。ユーザが表示を指示したデータ（HTMLやCSSや画像など）がキャッシュ領域にあれば、サーバからはダウンロードせずにキャッシュ領域に保存してあるデータをそのまま表示する仕様です。 キャッシュ領域に保存してあるデータを読ませずに、強制的にサーバからダウンロードし直させるには、単に「再読込」をすれば良いだけです。たいていは、F5キーを押すと（構成ファイルを含めた）ページ全体の再読み込みができます。もちろん、ツールバー上の「再読込（リロード）
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
現在、弊社Webサーバの保守・点検作業にともない、一部機能を停止させて頂いております。作業の間ご迷惑をおかけします。 書籍、Ebookのご購入に関するお問い合わせはjapan@oreilly.co.jpまでご連絡ください。
はじめに サワディーカップ（こんにちは）、Python界のミステリハンターです。さて、PyCon mini JPから早くも1週間が経ちまして、僕もPythonやってかないといかんなー、と思った次第です。そこで、早速Webクローラーを書きまして、そのときにformデータをmultipartで送信する部分がありましたので、こんな感じに実装したよというのをメモしておきます。 multipart/form-data関連リンク RFC 2045 - multipart自体のRFC RFC 2388 - Returning Values from Forms: multipart/form-data (RFC2388) ISAPI Extension (5) : Multipart/form-data の処理 まあ要はurlencodeで送信してた内容を区切り線で分けてbodyに突っ込みました、ちゃん
Learn how people are using AI at work to collaborate, find focus, and get stuff done. Hear founders, researchers, and engineers talk about the problems they’re solving with the help of new and emerging AI tools, and how AI can help you spend more time on the work that matters most. Follow: Apple Podcasts | Spotify | YouTube Music | Amazon Music | RSS
旦那が何を言っているかわからない件 一話 二話 三話 四話 五話 六話 七話 八話 九話 十話 十一話 十二話 十三話 十四話 十五話 十六話 十七話 十八話 十九話 二十話 二十一話 二十二話 二十三話 二十四話 二十五話 二十六話 二十七話 二十八話 二十九話 三十話 三十一話 三十二話 三十三話 三十四話 三十五話 三十六話 三十七話 三十八話 三十九話 四十話 四十一話 四十二話 四十三話 四十四話 四十五話 四十六話 四十七話 四十八話 四十九話 五十話 五十一話 五十二話 最終更新日 ７月１５日 WCR投票【読んだら押してくれると嬉しい】 twitter【エロいことも言うので注意】 ツイート 仕事【いろいろやってます】 ピーチボーイリバーサイド【他所でやってるWEB漫画】 商業作品一覧
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
