HTTPがStateless であることを理解できた話

Ruby on Railsを学習中。Rails Tutorial を始め、８～10章あたりで躓いた際の発見。

Sessionのあたりが鬼門だった

　Sessionが絡んできたのが混乱の原因。わかっていることをメモ。

• Sessionはサーバが保管している
• CookieにSessionの中身をそのまま格納するのはSecurity的にNGなので、Session ID のみをCookieに格納する方式を採用
• サーバは、CookieのSession ID を参照して、Sessionを確認する（らしい）
• CookieとはHTTPヘッダ内のテキストデータ
• Rails では session メソッドを使うことで、session を設定できる
• session が結局どこに保管されるのかは不明（必要が生じたら調べる）

　HTTPはステートレスであることは知っていたのだが、Sessionがサーバに保存される、Cookieはブラウザに保存される、などの情報を聞いて混乱していた。
　Sessionはブラウザを閉じるまでの間のみ保持されるものであり、Cookieは永続化すれば20年もブラウザで保持されるものであり・・・
　しかし、結局Sessionがサーバのどこに保存されるのかはわからないし、Cookieはブラウザに保持されるらしいが、同時にHTTPヘッダに格納されて毎回送信されている。
　ここらへんが混乱のもとだった。

State less とはこういうことか

　発想のヒントになったのは、現場でテストを作成した経験を思い出したこと。
　Webアプリのプログラムにおいて、URLを直接編集した際に認証をくぐり抜けてしまうバグが発覚した。そのため、そこのテストを急遽書いた、という経緯。
　Webアプリでは、リンクやボタンを用意してユーザが迷わず行動できるように仕組む。だがリンクを直接編集すれば、予期しない動作も出来るのだ、と。
　（因みに、ある程度知識が有ると、Formからデータを送信したように仕組むことも出来る。Securityって大変だね(´・ω・｀) ）

　つまり、ユーザがどのボタンを押すのか、どのページからアクセスしてくるのか、何のデータをPOSTしてくるのか、は全く予想がつかないことになる。
　ということは、どこからアクセスされて、どんなデータが送信されても大丈夫なように仕組んでおく必要がある。
　この発想に至って、全てのアクションには想定外の挙動をはじく仕組みが用意されているべきだ、ということに気付けた。
　これが before_action を実装する際に求められる発想であるわけだ。

　Eureka！（発見の喜び）

発想を理解すること

　今回のような発見、納得は、技術系を習得する上では特に重要だと思う。
　プログラミングにおける実装の方法というのは沢山あるので、この発想で最適化が出来れば、余計なコードを書かずに済むし、実装までの時間が短縮されるだろう。
　個人的には、発達障害者が行動を変える上でも「納得」は重要だとも思っているので、そこにも言及しておく。
　おわり！