今週の技術日記

（この日記は殴り書きです）

新規プロジェクト（既存プロジェクトからの派生）の認証周りの設計が一段落した

今回の新規開発と同時に既存のモノリシックなサーバーを将来マイクロサービス化していくための土台も整えていく
また既存システムはAPI化されていないため、今回大部分をAPI化していく（その際graphQLを使う予定）
API化するにあたって認証周りの既存との兼ね合いをどうしようかと悩んだ
既存はいわゆる普通のOAuth認証を実装してるWebサーバー
ここにネイティブアプリが入ってきたら認証はどうすればいいのか

考えた結果今回は
ネイティブのウェブビュー使ったOAuth認証→セッションが張られるのでウェブビューのcookieをネイティブコードと共有してそのセッション情報を使って認証サーバーに別途認証トークン発行をリクエスト→生成されたトークンを使用して、それ以降のAPIサーバーへのリクエストを送る
という形にした
トークンはjwtで生成。マイクロサービスのいわゆる分散システムなので、トークンによる認証はセッションより都合が良い
トークンの検証は、ゲートウェイAPIサーバーから認証サーバーに投げる形で行う
各サービスでそれぞれ検証すべきか？とも思ったけどあまり必要性も感じなかった

OAuth認証でよくある認証サーバーから返ってくる認証codeの存在意義が今までいまいちわかってなかったんだけど今週ついに理解した
codeを返す時
認証サーバーからサービスのサーバーにcodeを返してるようにイメージしがちだったけど、正確には認証サーバーからリダイレクトで一旦ブラウザ通ってからサービスのサーバーに行くっていうのが正しい流れだった
なのでcodeじゃなくて直接access tokenを返した場合、ブラウザにaccess tokenが流れてしまうので、access tokenが不正に傍受されるリスクがあるっぽい
しかしcodeを使用すれば、access tokenのやり取りは認証サーバーとサービスサーバーの間だけに限定されるのでよりセキュアになる
こんな理解

今週はもう一つ、grpcを既存のspring bootアプリに入れることをやった（まだやりきれてはいない）
何もわからなかった&ドキュメント読んでても眠くなったので、とりあえず手を動かそうってことで、手元でprotocol buffers試してみたりしてからgrpc-javaを入れてみた
ところがgradleのバージョンがこれまた低くて(2.7だったorz)アプデする必要がでてきた
gradleはエラーログがわかりにくすぎて結構手間取ってしまった(githubのissueにもエラーログわかりにくいから改善したほうが良い的なものがあった。だよね！！と共感せざるにいられなかった)
最初IntelliJでgradle buildしてる時のgradleバージョンどこで指定してるのかわからなかったけど、gradle-wrapper.propertiesというファイルで指定してた
最初あまりにも動かないしエラーも意味不だしだったからてっきりpluginsの書き方とか古いから問題あるのかなーとか思ってたけど、結論ほとんどspring-boot-gradle-pluginのバージョン上げてなかったのが原因だったからなんやねーんという感じだった
gradleむずかしい..
gradleも整ってgradle buildでprotocol buffersのコンパイルもできるところまでとりあえずできた
しかしマイクロサービスでリポジトリも分けようかなと思っているんだけど、protoファイルはどう管理すればよいやら...

０ベースの新規開発と、既存システムとの兼ね合いを考えながらの新規開発はまた違った感じで面白い

文章だけだとわかりにくいな
図を載せたいけどいちいちブログのために作るのもめんどくさいから、普段のメモをipadとかにとってそれをそのままブログに貼り付けたい
または普段わりとUMLで作図するからはてブロにUMLかければいいんだけど