SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa
アクセストークンをWebWorkerで扱う - console.lealog();
というアプローチを紹介してる記事があって、なるほど？と思ったのでまとめてみる。 元記事はこちら。 Leveraging Web Workers to Safely Store Access Tokens – The New Stack 毎度のことながら、今にはじまったことではない。 元記事いわく WebWorkerであれば、メインスレッドで実行されるであろうXSSや3rdのコードから触れないので安全！ 設計としては、 メイン: まず`Worker`をロード メイン: 初期化のメッセージを`postMessage()` クレデンシャルがあるならそれを渡す ワーカー: アクセストークンの準備 受け取ったやつ or そこで`fetch()`して、オンメモリに保存 （これで準備OK） メイン: APIにリクエストしてほしいと`postMessage()` ワーカー: APIに向けてアクセストークン
2021年の密かなトレンド？ “型安全ルーティング”の概観
2020年は、型安全ルーティングが密かに盛り上がりを見せた年でした。この記事では、TypeScript周りのエコシステムで発生した型安全ルーティングという概念とこれまでの流れを振り返ってご紹介します。 ルーティングとは この記事でいうルーティングは、URL（特に/user/uhyoといったパス部分）を見てコンテンツを出し分ける機構のことを指します。ルーティングは、主にSPA (Single Page Application) で必要となります。SPAはどのようなURLでも同じHTMLとJavaScriptが動作し、JavaScriptによってアドレスに対応したコンテンツが表示されます。まさに、ルーティングがSPAの根幹となっています。また、一般のウェブサーバーも、異なるURLに対するリクエストには異なるレスポンスを返しますから、ここでもルーティングが行われていることになります。 従来は、文
Frontend Study #1: 基調講演 - Frontend 領域を再定義する
Front-End Study #1「Cloud Native時代のフロントエンド」 - connpass の発表内容のテキスト版です。 発表に載せられなかった参考資料集 StatCounter Global Stats - Browser, OS, Search Engine including Mobile Usage Share The "Developer Experience" Bait-and-Switch - Infrequently Noted JavaScriptよ。文明を捨て、自然に還れ。 ::ハブろぐ Deno - A secure runtime for JavaScript and TypeScript Rome Toolchain Blitz.js - The Fullstack React Framework | Blitz.js ⚡️ Prisma - Da
Webpack チャンク最適 テクニック - Qiita
ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では
SPA + SSR + PWA の作り方とセキュリティについて - hiroppy's site
<script nonce="xxxxx" id="initial-data" type="text/plain" data-json="${preloadedState}" ></script> このpreloadedStateはエスケープ処理が必要なので注意してください。 クライアント側の読み込み方 const initialData = JSON.parse( document.getElementById("initial-data")!.getAttribute("data-json")!, ); const { store } = configureStore(initialData); https://github.com/hiroppy/ssr-sample/blob/master/src/client/index.tsx#L21-L22 useEffect SSR では、
SPA が、ウェブ開発のベストプラクティスになる時代 - mizchi's blog
最近のフロントエンドに関するお気持ち。正直まとまってはない。 最近、こんな感じのツイートや記事が増えた。 web 技術をキャリアの中心にしない シングルページアプリケーション (以下SPA) の台頭により、私の観測範囲ではモダンな Web サイトは SPA で作られるようになった。サーバーサイドは JSON を返す API サーバーとなり、DB やバックエンドシステムのプロキシのような存在になりつつある。 私はサーバーサイドエンジニアとしてキャリアを積んできた。SPA が流行りだした頃、いずれサーバーサイドエンジニアは不要になって自分のキャリアを考え直さなくてはいけない時期がくるのではないかと戦々恐々としていた。 自分も元々、SPA を他サイトとの「差別化技術」と定義していた。ブラウザのタブページのライフサイクルにおいて、初期化プロセスを一回にまとめてシームレスな遷移を実現する技術。たとえ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
