フレームワークに任せきりにせずに自分でアレコレやるのが好きな、ユゲタです。
Webサイトにおけるセッション管理って、これまでPHPのsession機能に任せっきりにしていましたが、
sessionデータの管理やブラウザのcookie有効期限などとの乖離によるトラブルも何度も経験してきて、
いっそのことSessionデータって、クライアント側のブラウザに持っておいた方がいいのではないかと思って調べてみると、
SessionStorageっていう機能があるのを見つけました。
LocalStorageとSessionStorageの違い
これまでは、JavascriptのCookieではなく、LocalStorageの機能を使って、まあまあ大きめのデータを保持する機能はたくさん利用してきたんですが、
SessionStorageは、使った事がありませんでした。
でも、SessionStorageもLocalStorageも、ほぼ同じ使い方ができるので、プログラミング的な混乱は全く心配なかったですね。
この２つの明確な違いは、LocalStorageは、消さない限りデータが残り続けるのに対して、SessionStorageは、セッションを閉じると消えてしまうという、
セッションの為の保存領域であることが理解できました。
セッションって一体なに？
ローカルストレージとの違いも明確に分かったけど、そもそもセッションって一体何なんでしょう。
辞書で調べてみると
セッション
1.
《名》
会合や授業を行う期間（時間）的な一続き。
「この―で解決しよう」
2.
《名・ス自》
ジャズなどで、演奏者が集まって演奏すること。
▷ session
単語の意味は、なんとなく分かるんですが、IT（特にweb）におけるセッションはというと・・・
コンピューターネットワークにおけるセッションとは、通信の開始から終了までを指します。
クライアントとサーバーで通信を行う場合であれば、クライアントからサーバーへ接続した時点でセッションが始まり、サーバーから切断するとセッションが終了します。この一連の流れを管理することをセッション管理と言います。
参考 :
https://ntt.com/bizon/glossary/j-s/session.html
なるほど、サーバーに接続てから、切断するまでか〜。
って、それリクエストからレスポンスまでっていう事じゃないよね？
WEBマーケティングでいうところの、セッションとページビューとユニークユーザーの違いが分かるとわかりやすいんですが、
同じドメイン（サイト）に訪れて、そのサイトを閲覧して、別のドメインに遷移した場合、同じドメインを遷移している間はセッションをキープしている感じということで分かったような、分からないような・・・
SessionStorage調査
実際にデータを書き込んでみるとわかるので、実際にやってみました。
ちなみに、LocalStorageやSessionStorageの書き込み方、読み込み方、などは、リファレンスサイトに親切に書かれているので、ご自身でやりたい人はそちらを参照してください。
ページにSessionStorageでsetItemして、任意keyに対してデータを書き込んで、そのまま、同じドメイン内のページリンクをクリックすると、データは書き込まれたまま残っています。
GoogleChromeブラウザで、別のタブを立ち上げてみると、そこには、データは書き込まれていません。
タブを戻して同じようにドメイン内のリンクをクリックしても、さきほどのデータが保持されています。
この時点で、タブが違うとセッションが違うという事がわかります。
そして、別ドメインのリンクをクリックして、また元のドメインに戻ってくると、同じタブでも先ほどのデータが消えてしまっていました。
なるほど、やはり想定通り、サイトにおとづれてからサイトを離れるまでセッションをキープしてくれるという仕様であることがわかりました。
ログインセッションを保持するのに最適かも
改めてサーバー側（PHP）でセッションを管理するのではなく、クライアント側でデータを保持しておいた方が便利で扱いやすいという思考になってきました。
ログインしたら、任意IDを発行して、SessionStorageに保持して、この時に保持したいデータも一緒に保存しておくことで、セッションをキープしている間はサーバーに問い合わせをしなくても、ローカルだけ（オフライン）でデータを持っておける。
かなりサービスがサクサク動きそうな気がする。
でもセキュリティはどうなんだろ？ログイン情報をそのまま平文でストレージに入れておくのは、デバッグツールで丸見えになってしまう。
そんな時は、簡易なケースだと、json化して保持するデータや文字列データなどをbase64変換しておくだけで、簡単に平文認識できなくなります。
もちろん簡単にハックされてしまうので、zip圧縮できる、RawDeflateツールなどを利用して、圧縮化することで、よほどのハッカー技術を持ったエンジニアじゃない限り解読不能の可逆データとして利用できるようになります。
ユゲタの場合は、独自でそうしたセキュリティ対策コードを、これまでいくつか作ってきていたので、それらを利用すると、めちゃくちゃ便利にローカルでのセッション管理できるシステムを構築することができました。
サーバー負荷も減るし、webの無駄な問い合わせも無くなるし、もちろんページのスピード効率も良くなるし・・・
な〜んか、良い事だらけで、何故これまでこの機能使わなかったんだろう・・・
ということで、これから作るwebサイトの仕様がSessionStorageになることが確定した今回の調査でした。
0 件のコメント:
コメントを投稿