蚊帳の中の日記

ゆるく生きてます

2018/06/11

diary 開発

雑多なアウトプット

  • API関連の開発を行っているのだけど、認証トークンとかアクセストークンとかIDトークンとかリフレッシュトークンとか、「トークンっていっぱい種類ありすぎ！」ってなった。
    • 認証用トークン：その名の通りの役割。サーバー側（リクエストを受け取る側）で事前にトークンを発行しておき、ユーザーなどのクライアント側はその認証トークンを利用して、プライベートな情報を取得したり操作したりする。ユーザーはメールやパスワードを入力をしなくても認証トークンを一回ゲットしてしまえば、以降はそれで操作ができるというメリットがある。しかし、基本的に認証用トークンは内容が不変の想定なので、盗まれたりしたら不味い。
    • アクセストークン・リフレッシュトークン：上の認証トークンが基本的に不変な内容なため、セキュリティ面で危ういという話をしたが、アクセストークンは「有効期限」をつけて、その有効期限が過ぎていたらトークンは無効になるというセキュリティ面を考慮したメリットがある。しかし、だいたいこの有効期限は短く設定されており、この有効期限が切れたらユーザーに再度ログインをしてもらう必要がある。でもそれもちょっとユーザーからしたら面倒くさい。なので、リフレッシュトークンと一緒に発行することが多い。リフレッシュトークンはアクセストークンと一緒にブラウザに保存され、有効期限も長く？、最初の方でアクセストークンがあるので使わない。もしアクセストークンが有効期限切れだった場合、このリフレッシュトークンを見て、新しいアクセストークンを発行するという仕組み。これなら、ユーザーは再度ログインする手間が省ける（OAuth2.0の由来）。サーバ側では、２つのトークンをテーブルに保存しておく必要がありそう。
    • 参考
    • OAuth2.0
  • ちょっと大きめのPRをリリースできた。ディレクターさんとかにも「評判いいよ〜」って褒めてくれて嬉しい。次も頑張りたい。早くこうけんできるようになりたいな〜。そのためにも、主体的なやっていきが必要だな。うん。
  • 7月からは他のエンジニアの方とか、デザイナーさんと協力して、フロントを整備していきたい（なんで７月かっていうと、その月から正式な自分の目標設定とかをしだす時期。このミッションを自分の目標に入れてしまいたい）。
  • ニュース見て新幹線乗るの怖くなってきた。。。

反省点

この間、デプロイの最中に（テスト環境だけど）ちょっとした問題が起きた焦った。で、焦って先輩エンジニアに聞いて「とりあえず落ち着きましょう。とりあえずステージングだし。もし本番なら切り戻しを先にやるのも手です。」とアドバイスを頂けた。
ほんと、これでとりあえず焦ってしまうのだ。
ほんと焦る。本番デプロイとか焦る。何かデプロイでエラーでユーザが使えないとかなると、それだけで機会損失なわけだ。前職では別にエラーを起こすデプロイにはなっていないけど、自分のミスで一部のデプロイが遅れて「機会損失だろ」って罵られた苦い経験がある（詳細は書かないけど、未だにあれは自分だけのせいではないと思っている笑。）
でもそういった焦りそうな画面のときこそ、「冷静になってログを見る。本番とかなら落ち着いて切り戻しを行い、ログを確認するんなどの調査を行う。わからなければ相談したりする」。とにかく最初にすることは調査とか切り戻しとかではなく、「一つ深呼吸をして落ち着く心をもつ」だと思った。
結構焦りだすと、ほんと訳わからんミスする質でして、自分。。。これは改めて反省したいと思った。

コラム

やっぱり「落ち着く精神・冷静な心」って適切な判断をする上で重要なことだと思う。

面白かった・参考になったリンク