2019.11.12
Vueでカクテルデータベースをリファインする話#21【管理画面をつくろう#4】
バリデーション実装の話ってしましたっけ、validetorjsを使ったやつ･･････
まぁそれはそうとして、今現在バリデーションって2重でやってるんですよね。フロントエンド側でバリデーション定義して、サーバーサイドでもバリデーションを定義して･･････。
正直これってめちゃくちゃムダなんですけど、Laravelから送られてくるエラーをキャッチしてどうこうする、っていう思考が僕になかったので(笑)結果的にこうなっちゃいました。バリデーション時に通信を介することがないのはメリットなんですが、今回は使ってないですけどIDの一意性とかチェックする場合、どっちにしろサーバーサイドでのバリデーションが必要になるのでこの方針がベストとは限らんわけです。
で、何がしたいかっていうとバリデーション定義をサーバー側に一任したいっていうオーダーです。
それであればバリデーション定義が一箇所で済みますしね。サーバー側のバリデーション定義はセキュリティ上必須なので。
つまりサーバー側でのバリデーション結果がaxiosによって返却され、それを受け取ってコンポーネントを更新する、みたいなのをやりたいわけです。
で、今回の記事は具体的な実装例とかじゃなくて紹介なんですが、それを実現するのはcretueusebiu/vformとjaniskelemen/formvuelarがあるみたいですね。
今回はサンプルコードの関係でvformを使ってみますが、formvuelarがちょっとオシャレ感あるので、どっちも試してみたいと思ってます。そのうちね。
このあたりが前回の記事で「バリデーションエラーってどこでキャッチするんだろう？」と言ってた部分へのアンサーになりそうですね。なるほどなあ。
そんな感じで実装しようと試みたんですが丸1日ハマってるなうです･･････。しんどい･･････。
状況としてはこんな感じですね。見た目じゃまったくわかんないと思うのですが2種類の実装を試してます。どっちも別々の理由で上手く行ってません。
最も怪しい理由としてはこれですね。なんとtwitterではこのstatelessメソッドが何らかの理由で動かないらしいので代替手段を考える必要があります。
いろいろネット上には情報が転がってるんですが、プログラミングあるあるでどれも動かねえ。
で、埒が明かなさそうなのでどうすべきか考えます。とはいえ今後のためにSSOを諦めるワケにはいかないので、どうにかしてゴリ押しで開発するか、Socialiteを諦めるかみたいな選択を迫られるわけですね。
そこで僕が講じた最終手段がTwitterを切るという選択肢です。
まず僕がやりたいこととしてはSocialiteを活用したいってとこですね。サーバーサイドの安心感というか、こういうフレームワークのアーキテクチャを使った方が安全度は高いですし、使うSNSによって処理が分岐する、っていうのを最低限に抑えられます。この開発コストカットは僕みたいな個人開発だと必須です。
もちろんSocialiteを使わないっていう手もあるんですけど、そうなると認証周りのコードを自分で書くかどっかからライブラリを落としてこなくてはならず、結局また「動かねえじゃねえかクソボケ誰だよこれ書いたの」ってイラつくループにハマるんで、Socialiteを切るのはSocialite自体がダメだと断定できた時ですね。
LaravelはVueを公式サポートしてるはずなんだけどなぁ･･････Laravel+Vueのユースケースのリファレンスが少なすぎる･･････。Laravelって言えば国内でも人気のはずなんだけどなぁ。CakePHPとかいううんちっちの方がまだ人気なのか？←
とりあえず1日～2日かけてググってダメだったので方針を変えざるを得ません。次に僕がとる手段としてはTwitter切りです。
Twitter自体が諸悪の根源なのであればTwitterを切ればいい話ですね。具体的にはGoogleとFacebookのSSOができれば問題ないです。
というのも、僕が今後作る予定のプロダクトって、確定事項になってるだけで2種類ほどあるんですけど、そのどちらもビジネス寄りでして、例えばログインアカウントでtwitterを使うと、SNSの裏の顔が漏れるんじゃないか･･････！？みたいな心配をしちゃう人がいると思うんですよ。
なんで、需要はそこまでなさそうということで切っても問題なさそうだなと考えられます。もちろん実装するのに越したことないですし、例えばTwitterのつながりを元にしたグループを作る際は、Twitterアカウントでログオンできた方が便利そうな気もするんで･･････。
ただ、現状エコな方法で実装は不可能なので諦めたいと思います。はい。
ただ、そういやSSOってFacebookはステートフルでギリやったことありますけど、Googleに関してはノータッチですね･･････。と思って調べてみたら、なんとGoogleでSSOを使うには課金しなければいけない可能性があるとのことで。
うーーーーーん。どうしよう。SSOを諦めるという手もあるんだが、今後のことを考えるといちいちメールアドレスで認証すんの？？？みたいな話にはなってきますね。
あとさっきも言ったとおり、SSOを実装するのに投資が必要なサービスもあり、悩ましいところです。
･･････しょーーーがない。やっぱ自分でやるしかねえか･･････。
たまたまなんですが、jwt-authが入りました。やっとです。issueを読みまくってたらたまたまヒットしました。他に手段がないのでjwt-authで実装することに決めました。公式のリファレンスは未完成らしいですけどクイックスタートはあるので。
んで実装しようと思ったけどこれもうまく行かず･･････なんなんだ･･････。
完全なSPAでSSOは諦めた方がいいような気がする。ステートフルでのログイン自体は可能だと思われるので、じゃあそっちの線で将来性があるかどうかを考えてみるか･･････。
ちなみに、この時点で僕の力ではトークンを用いたOAuthログインはできないと諦めた形になります(笑)
Laravelのバージョンを下げればもうちょっと可能性は広がるのかも知れませんが、僕としてはあまり認証に関して深いレベルまで理解することを必須とは思ってないので、内部挙動に気を配らず実装がしたかったんで･･････。
リダイレクトを繰り返していけば認証自体はできると思いますし、それでトップページに飛ばすとかもたぶんできます。apiだとセッションが切れるそうですが、そこはwebルーティングに書くかサービスプロバイダに手を加えることでなんとかできるらしいです。
一応ソースはこのへんの話です。
問題なのはそれでちゃんと認証できるのかってとこですね。apiによるアクセスで「もし認証済だったら」みたいなのが判定できればいいんですが･･････。
vueのルーティングに関しては、vuexのストアに$userが入ってるかどうかでリダイレクトすれば･･････
っていう線でやってみようかな。っていうか手詰まりだからやるしかないんですけど。
ログインページでログインをクリックしたらSPAから脱して、トップページにリダイレクト、Laravel側にAPIを叩いてユーザー情報が取得できていたらひとまずゴールってことにしたい。
これが上手くいくなら、ログイン機構自体は従来のセッション方式なので原理的にはLaravelがサポートしているSSOログインならなんでも実装できることになる。たぶん。
あとはログアウトした後、管理画面にアクセスしようとしたらログインページに飛ばされる、みたいな動作が確認できれば大丈夫でしょ。このへんはvue-routerで対応可能だと思います。要するにログイン状態は全部Vuexで管理して、情報もそこに流し込みます。ログアウトボタンが押されたらVuexの情報を削除して、ログアウトさせるようなルーティングに飛ばしていけばおけおけ丸だと予想。
まぁこれ本来僕が最初に思いついた手なんですけど、実装例が見当たらないという理由でダメなのかなって思ってた手なんですけどね。
とりあえずtwitterログインで試してみます。ID/passを用いたログインなんてのはそれができればいくらでも作れるんで。
んじゃやってみましょ。コード自体は面白くないので載せません(笑)
とりあえず情報は簡単に抜き出せそうですね。
ここで引っこ抜いてきた情報を元に、新規登録なら新規登録、紐付けられそうなデータがあれば紐付けてみる、みたいな動作ができると良いですね。
今回のプロダクトは真面目にユーザー管理する気がないので、認証はtwitterのみ、ってことにしとこうかな。もしなんか不手際があったら僕が直接DBを弄ることで解決させましょう。コード書きたくない(笑)
つまりユーザー認証はIDでなんとかするって感じですかね。必要に迫られたら手を加える、みたいな感じでいいかな。
はい、ログインできました。使い慣れてる機能だと簡単ですね。
！？！？！？！？！？！？！？
リダイレクトしたら認証情報が消えた。どういうことだろう･･････？
そういや認証ミドルウェアをapiにしてたのを思い出し、webに戻したらちゃんと認証されてるっぽい動きになりました。とりあえずリダイレクトまではうまく行きましたね。
で、こっからですね。本題。
ここで、認証済ルートに到達した時点で、axiosでユーザーデータを取ってきます。ログイン時点でクッキーとかに埋め込んでいいのかも知れませんけど、いつまでも情報がクッキーに残るのはキモいしログイン時にVuexに格納したいわけですし、とりあえず手段としてはもうそれでいいかな感がしたのでとりあえず実装します。
とりあえずここでごにょごにょさせてみます。こういう流れのことができればガードはうまく働くと思います。ユーザー情報やりとりの実権はLaravel側が握ってるのでセキュアです。
はい。っぽいのを書きました。ストアの中身は簡単なので省略です。ゲッターの使い方がやっとわかった･･････笑
要認証ルートを通るたびにこの処理を挟ませることで、ログイン専用ページを実現できるわけですね。
ちゃんと未認証状態でアクセスするとアクセス自体がリジェクトされてます。いいですね。
一応認証ができました。めでたしめでたし。これでやーーーーーーーーーーーーーーーーーーーーーっと念願の管理画面が作れます。今日明日で完成させます。
当分は僕しか使わないページなのでアーキテクチャむちゃくちゃでとりあえず動けばいいみたいな構造になってますけど、どうやれば認証が実現できるかわかったのでオッケーということにしておきます。今後はこんな形で実装していこうかな。
ということで明日の記事はカクテルデータベースの今後の眺望というか、残ってる改善点のメモとかを書きなぐります。よろしゅう。