ログインせずにお気に入り機能を実装するための考察


ログインせずにお気に入り機能を実装するための考察をしてみたのでまとめ。

簡単仕様比較

名前 Cookie Session sessionStorage localStorage
有効期限 指定可能 削除操作をするまで ブラウザを開いている間 削除操作をするまで
容量 4KB 実装による 5MB-(ブラウザによる) 5MB-(ブラウザによる)

仕様まとめ

Cookie

概要

RFC 6265などで定義されたHTTPにおけるウェブサーバとウェブブラウザ間で状態を管理する通信プロトコル、またそこで用いられるウェブブラウザに保存された情報のことを指す。ユーザ識別やセッション管理を実現する目的などに利用される。(by wikipedia)

セキリティ面

  • セッションハイジャック
  • トラッキング・クッキー

らへんが一般的。

Session

概要

ログインしてログアウトするまでの一連の動作や時間のことで、
サーバサイドで情報を扱いたい時に、識別できるidなどの要素だけを保存して該当の操作が終了する段階で削除するのが一般的。

セキリティ面

  • セッションハイジャック
  • セッション固定攻撃

Web storage

概要

Cookie を使用するよりも直感的な方法で、ブラウザがキーと値のペアを保存できる仕組み。
sessionStorageとlocalStorageの2 種類で、仕様はそれぞれこんな感じです。

  • sessionStorage
    • ページのセッション中 (ページの再読み込みや復元を含む、ブラウザを開いている間) に使用可能な、生成元ごとに区切られた保存領域を管理します。
  • localStorage
    • 上記に加えて、ブラウザを閉じたり再び開いたりしても持続します。

セキリティ面

該当サービスにてアカウントの乗っ取りをされた場合に、挙動を変更されてしまう。

ユーザAとしてローカルストレージを用いた機能操作をした際に、ユーザBとして振る舞うことができる。

のでアカウントが乗っ取られても問題ない範囲で使う。

ここまでで一旦個人的な理解を整理すると

  • webStorage
    • クライアント側だけでデータをちょっと持っておきたい場合は、これ一択。
  • cookie
    • ユーザを識別してなんらかの事象を保持しておきたい時に使うが基本稀。
  • セッション
    • ある一定の一連の流れでだけ使いたい場合に最適。
  • まとめ
    • 基本的には、全ての操作は乗っ取られても問題ない情報しか載せない。

実装に入る

今回自分がやりたかったこと的には、webStorageのlocalStorageかなと思いその用途だけ確認。

と思ったらかなりまとまってるページがあったのでこれでいいかな。
https://dev.classmethod.jp/references/webstrorage_favorite-condition/

終わり

これから実用段階で使ってみて問題なければlocalStorage使ってみようと思います。