ロジックが外に漏れ出ると、外も修正が必要になる。
危険レベルが80%を超えたら赤で表示というのを、サーバーサイドとフロントで持ってしまうと、90%で赤にしたいという仕様変更で、2箇所修正になる。
フロントが来たものをそのまま表示するとなっていると、サーバーサイドでやればよくなる。けど、単純にControllerから赤と指定すると、結果変わらないので、status:creticalみたいな感じなら、良い気がします。
つまりデータだけ送るのが良いかと。表示側は送られてきたデータを見て、表示を作る。
通常のsession
昨日のsessionの話ですが、初めてアクセスしたときにkeyが割り当てられて、それを元に認証するのであれば、keyごとにユーザ情報が紐づく形になると思います。 その状態で、
リフレッシュトークン アクセストークン
を用意して、都度リクエスト時にアクセストークンを書き換えていけば、 どちらかのアクセストークンがダメだった際に、リフレッシュトークンを消せば、 両方アウトに出来ると思いました。
この仕様なら、マルチブラウザでも問題ないと思います。 この仕様のポイントは、ログイン時に生成されるトークンが２つになることで、 変化するものとしないものに分かれ、 変化しないものを消せば、両方ダメに出来るところですね。
SSLStripやSSLSniff
長々と語ったが、今回のエントリで主張したことをまとめると、次のものに集約される。
- データベース設計時にはドメインを意識する
- 表示とデータは分ける
- 同じ意味のカラムには同じ名前をつける
- IDとなるドメインの設計時には運用まで視野にいれておく
これらを実践することで、冒頭に述べた次のような判断が的確に行えるようになるだろう。
- 一つのカラムとして定義して良いのか、あるいは分けるべきか
- SQLのデータ型は何にするべきか
- 制約をつけるべきか
- パスワード変更にはtokenが必要。
- 最終的には、token付きでパスワード変更リクエストを投げる。
ブルートフォースでアタックされた場合、変更可能。トークンが発行されるのは、第二パスワードが分かった場合だし、たとえ発行されたとしても、トークンの期限切れ前にブルートを成功させる必要がある。さらに、変更された場合、メールが届く。おかしければ、停止措置を。