画面間の値の受け渡しSessionStorageの活用
この記事は以下のターゲットを対象としています。
★5 Django の開発経験が 3 年以上。
★4 Django の開発経験が 1 年以上。
★3 WEB サイト開発経験あり。これから Django を学習します。
★2 Python 初級者。簡単なプログラムコードが書けます。
★1 プログラミング未経験。
Session Storageについて考える
こんにちは、グローバルウェイの有浦です。
今回はWebアプリ開発時に役立つSession Storage機能についてのご紹介をさせていただきます。
Session StorageとはWebブラウザで提供されているWeb Storage APIの一部でブラウザにデータを一時保存する仕組みのことです。このAPIを使用することで、アプリケーションサーバーを介さずに画面遷移後に前の画面で入力した値を使用することが可能となります。
本稿ではSession Storageの機能の紹介とその使用方法について記載します。
Session Storageとは何か
前述したWeb Storage APIが登場したのは2009年にリリースされたInternet Explorer 8にて実装されました。他ブラウザ(Google ChromeやFireFox、Operaなど)の対応が同年行われ、その4年後にWeb Storage API第一版がW3C勧告として認められました。
Web Storage APIには、今回メインで取り扱う「Session Storage」と「Local Storage」の2つの主要なオブジェクトがあります。
両者のどちらもブラウザにデータを保存するものですが、データ保持に関しての仕様に差分があります。以下仕様差分の表となります。
<仕様の差分>
| Session Storage | Local Storage | |
| データの保存 | 一時的 タブを閉じると消滅 | 永久的 明示的に削除されるまで残り続ける。 |
| スコープ | 同一タブ内のみ有効 | 同じドメイン内で有効 |
仕様の共有点は以下のポイントが上げられます。
・共通点
- 容量
- 一般的に約5MB程度(ブラウザによって異なる)。
- Cookieよりも多く保存できる。※Cookieは約4MB
- データ形式
- 文字列のみ保存可能(オブジェクトは
JSON.stringify()で変換)。
- 文字列のみ保存可能(オブジェクトは
- セキュリティ
- サーバには送信されない(Cookieと違い、HTTPリクエストに含まれない)。
- JavaScriptでのみアクセス可能。
使い分けについてですが、Session Storageは同一タブ内となっておりますため、DBに保存されないようなフォームの内容などを画面遷移後に使用する際に便利なもとのなっております。
Session Storageの使用方法
Session Storageは現在のブラウザでは標準で使用可能な機能のため、特別な専用JavaScriptsのライブラリの参照は必要なく、以下のような記載を行うことで、参照・更新が可能です。
<参照>
- localStorage.getItem({任意のkey名})
- sessionStorage.getItem({任意のkey名})
<登録・更新>
- localStorage.setItem({任意のkey名}, “{格納したい値}”)
- sessionStorage.setItem({任意のkey名}, “{格納したい値}”)
<初期化>
- sessionStorage.clear()
- localStorage.clear()
<削除>
- localStorage.removeItem({任意のkey名})
- sessionStorage.removeItem({任意のkey名})
登録する際にすでに存在しているKeyの場合はValueの更新を行い、
存在していない場合はKeyとValueの値をセットで登録するUPSERTの仕様となっています。
<具体的な使用例>
画面1で入力した値を画面2に遷移した際に、復元させるHTML+JavaScriptとなります。
・画面1(入力画面)
例えば以下のようなHTMLを作成します。

入力画面のHTML

入力画面のプレビュー
2つのテキストボックスがあり、各入力フォームに入力した状態で、「進む」を押下した際に、入力された値をSession Storage、Local Storageに格納させます。
その際には以下のようなJavaScriptとなります。

入力画面のJavaScript
※以下のロジックとなっています。
- テキストボックスに入力された値を取り出してローカル変数に値を設定する。
- ローカル変数にいれた値をLocal Storage or Session StorageにそれぞれsetItemを用い設定する
- 次の画面へ遷移させる。
・画面2(表示画面)
入力画面で格納した値を取り出し、任意の要素にその文字列を格納させます。
下の例ですとinput-test-sessionにSession Storageの値を、input-test-localにLocal Storageの値を表示させたい場合は以下のようになります。

表示画面のHTML

表示画面のプレビュー

表示画面のJavaScript
WebStorage+getItemで値を取り出し、画面の要素に値を埋め込むことが可能です。
また現在どのようなKeyとValueの値が設定されているかはブラウザの開発者ツールを用いることで確認も可能となります。


Session Storageのメリット・デメリット
メリット
- サーバに送信されない
Cookieと違い、HTTPリクエストに含まれないため通信量を減らせます。
ただしサーバ側に送信されないため、Webアプリケーションとして入力値のValidationチェックを行う際にはサーバ側でのチェックができなくなります。
フロント側のみのValidationチェックは開発者ツールを使用することで無効にもできるため、チェックしなくて問題ないかの確認が必要となります。
(例:最終的な値はサーバサイドでのValidationチェックが入るため問題ない等) - 容量が大きい
Cookieの約4KBに対し、Session Storageは約5MB。 - 簡単な操作性
JavaScriptで簡単に読み書き可能。
特別なライブラリを入れることなく使用可能なため、導入すること難易度は低いです。 - セッション単位で管理できる
タブごとに独立したデータ管理が可能。
デメリット
- タブを閉じると消える
長期的なデータ保持には不向き。
ただしlocal Storageは値を明示的に削除しない限り消されないため注意が必要です。 - 同一タブのみ有効
複数タブ間で共有できない。
ログインのセッション情報などを持たせてしまうと異なるタブを開くたびにログイン画面に遷移してしまうことになるため、Session Storageに持たせるべき値なのか選定が必要です。 - XSS攻撃に弱い
JavaScriptでアクセスできるため、悪意あるスクリプトに注意が必要。
今回紹介しました通り、開発者ツールを用いれば誰でも簡単に中身を確認することが可能なため、認証トークンやパスワードといった機密情報はSession Storage格納することは避けたほうが賢明となります。
まとめ
Session Storageは、「一時的なデータ保持」や「セッション中の状態管理」に最適な仕組みです。フォーム入力の保持やショッピングカートなど、タブ単位で完結する機能に向いています。一方で、長期保存や複数タブ間の共有にはLocal Storageやサーバ側のセッション管理を組み合わせるのがベストです
参考文献
MDN Web Docs「ウェブストレージ API」
https://developer.mozilla.org/ja/docs/Web/API/Web_Storage_API
WHATWG HTML Standard「Web storage」
https://html.spec.whatwg.org/multipage/webstorage.html

