code on a screen

Nuxt3での簡易の認証フローを構築する

Nuxt3でアクセストークンを使った簡易な認証フローの構築をしてみます。

簡易な認証フローでは、route middlewareを使います。route middlewareはNuxt2にも同様にあった仕組みです。サーバーサイド(SSRサーバ初回アクセス時)、クライアントサイドで動作し、ページ遷移時に認証などのフィルタを挟んだりすることができます。ページコンポーネントに以下のように記述することで、ミドルウェアを宣言的に適用することができます。

参照:ミドルウェアディレクトリ 

なお、server/middlewareという仕組みもありますが、これはサーバーリクエストごとに動作するミドルウェアです。ドキュメントにもあるように、何らかのチェックやヘッダの操作、ロギングなどに使用する用途のようです。expressでrouteをマウントしても呼ばれます。Nuxt3の内部で使われているh3 httpフレームワークのミドルウェアとして登録されます。

https://v3.nuxtjs.org/guide/features/server-routes#server-middleware

そのため今回は、route middlewareの仕組みを使って構築してみます。

テスト環境

  • nuxt@3.0.0-rc.8

今回のフロー

以下のような構成にしてみます。nuxt-auth moduleもcookieを使った同様の機構があります。

  • トークンはcookieに保存、ログイン時にcookieに書き込む。クライアント側でもread/writeするのでHttpOnly属性はなし。
  • SSR時は、cookieからトークンを読み出して使う。
  • route middlewareでは、cookieから値を読み出しログイン済みかどうかをチェックする。

この他、以下の仕組みを使うので補足します。

route middleware

route middlewareですが、middlewareディレクトリに配置すると自動でインポートされます。.globalというサフィックスをつけることで、全体に対して適用することができます。

  • middleware/auth.ts
    • definePageMetaでページコンポーネントに対してミドルウェアを適用する
  • middleware/auth.global.ts
    • 全体に渡ってミドルウェアが適用される

useCookie

useCookieというcomposableライブラリを使用します。useCookieは、サーバサイドとクライアントサイドで使えます。useCookieによる返り値に対しvalueを書き込みすることで、裏でNuxtが上手いこと処理をしてくれます(具体的には後述の通り)。

これにより、SSR時でもアクセストークンを取得し、フェッチリクエスト時にヘッダにトークンを埋め込むことができるようにします。

クライアントサイドの動作

クライアントサイドでは、document.cookieより指定したcookieを取得します。そのため、HttpOnlyが指定されたcookieは使えません。useCookieにより得たcookieはrefオブジェクトとなっており、valueに値を書き込むことでdocument.cookieにシンクされます。

サーバサイドの動作

サーバサイドでは、フックのタイミングでレスポンスヘッダにcookieが書き込まれます。

route middlewareを使った例

では、実際に構築してみます。フローを確認するためのサンプルなので、エラーチェックやその他バリデーションなど厳格さは欠いていますことご容赦ください。

server/api/login.ts

今回は、トークンを返すだけの簡易な処理としています。

server/api/posts.ts

ログイン後に何らかの投稿記事一覧を返す処理とします。リクエストヘッダから、Authorizationヘッダを読みトークンを確認します。トークンがあれば、ひとまず記事一覧を返すとします。

middleware/auth.global.ts

useCookieを使っています。ログインに成功すると、cookieに値を書き込みます。同時にdocument.cookieにも書き込まれます。

pages/login.vue

pages/dashboard.vue

以下のような感じで動きます。

 参考リンク

中小企業診断士 1次試験(令和4年度)を受けてきた

8月6日(土)、7日(日)と中小企業診断士試験を受けてきました。令和3年はコロナの移動制限もあって受験を断念。なので、今回が初めての独学での受験となります。試験対策としては、21年のSTUDYINGさんの教材とTACのスピ問(ほぼこれを中心に学習)で望みましたが、結果は合格点にあと僅か及ばず。6科目なので合計360点以上で合格となりますがあと僅か足らずの結果だったので1次突破ならず😭

特に財務・会計で点を採れなかったのが大きかったです。この財務の穴埋めを他の教科でカバーできずに撃沈🙀

ただ科目合格は2科目はいってそう。また、来年チャレンジしてみます。2次試験の勉強を一切できていなかったので、来年を見据えて2次試験の勉強から再出発してみたいと思います。

code on a screen

Nuxt3のruntimeConfigで環境変数を設定する

はじめに

nuxt3には、実行時に設定値をロードするための仕組みとしてruntimeConfigというものがある。コンポーネント内からはuseRuntimeConfigや$configで値にアクセスすることができる。サーバサイド(private)、クライアントサイド(frontend)で公開範囲を区別することもできる。本記事では、runtimeConfigの設定方法と使い方についてざっと整理する。

privateとpublic configuration

runtimeConfigの下に定義されているプロパティはprivate、publicやappブロックに定義された値はfrontendに公開される。

.envからの定義を渡す

nuxt.config.tsのruntimeConfigに定義することで利用できるが、よくやる方法として、.envに定義した値をruntimeConfigにセットするというアプローチがあるだろう。以下のような感じだ。

この方法でも問題ないが、毎回.envの値をruntimeConfigにセットしない方法もある。次に、.envの特定の値を動的にruntimeConfigに反映する例を見てみる。

.envからの定義を動的に渡す

.envに特定のプリフィックスNUXT_またはNITRO_をつけた値は、runtimeConfigに定義されていればruntimeConfigに動的に設定されるようになっている。なお、この際runtimeConfigのjson構造の階層と合わせてやる必要がある。具体的な例を見てみる。

この定義を動的に読み込むためのnuxt.config.tsは以下のようになる。

コンポーネントでは以下のようにアクセスできるだろう。

apiKeyはprivateなので見えない。frontendConfigはpublicのためフロントエンドで見える。ssrのレスポンスを見るとwindow.__NUXT__の定義のruntimeConfigプロパティとし見えるのが分かる。

NITRO_とNUXT_の両方が定義されている場合

NITRO_の優先順位が高くなっているので、両方定義されている場合はNITRO_の定義が勝つ。

独自のprefixを指定したい

NUXT_でなく、MYAPP_のような独自のprefixをつけたい場合は、以下のようにnitroのenvPrefixを書き換える。

参考リンク

 

code on a screen

Nuxt3でtailwindcssを使う

はじめに

nuxt3でtailwindcss(bootstrapのようなcssフレームワーク)を使えるようにします。nuxt3は、本記事掲載時点ではバージョンrc4となっており正式リリースはされてない状況ですが、少しずつ触っていきたいと思います。公式サイトのロードマップを見るとmidsummerとなっているのでもうすぐリリースでは!?と楽しみにしてます。

nuxtでは、tailwindcss向けのモジュールが提供されているので、モジュールを使うことで簡単に導入することができます。では、実際に入れて試してみたいと思います。

https://tailwindcss.nuxtjs.org/

まずはNuxt3を入れる

公式の通りです。

@nuxtjs/tailwindcssの導入

続いてtailwindcssを入れます。@nuxtjs/tailwindcssモジュールを入れます。

@nuxtjs/tailwindcssは、すでにnuxt3対応されています。続いて、nuxt.config.tsにモジュールを使用する指定を追加します。

これで基本的には動作するようになります。

tailwindcssのconfiguration

@nuxtjs/tailwindcssではモジュール起動時にデフォルトの設定を適用するようになっているため、設定ファイルを用意しなくともすぐに使えるようになっています。tailwindcssでは、通常tailwind.config.jsというconfigurationファイルで設定を記述するようになっています。@nuxtjs/tailwindcssでは、configurationの記述場所としてtailwind.config.jsを含めて3つの方法が用意されています。

  1. tailwind.config.js
  2. nuxt.config.ts
  3. nuxt hook

参考:https://tailwindcss.nuxtjs.org/tailwind/config

今回は、tailwindcssの通常である1の方法で設定を上書きしてみます。

設定を変更したい場合は、設定ファイルをプロジェクトトップに置きます。(なお、この場所は変更可能となっているようです)。以下のコマンドでtailwind.config.jsの雛形が生成されます。

今回は、tailwindcssのcss定義にtw-というプリフィックスをつけるよう設定してみましょう。ここでは、prefixのみを指定していますが、本設定は@nuxtjs/tailwindcssが用意するデフォルト定義にマージされます。マージ動作については、上記のconfig説明ページに書かれていますが、defuライブラリが使われています。

これで、tailwindcssを使う準備ができました。

動かしてみる

では、実際に使ってみましょう。サンプルアプリは以下の構造です。

app.vue

pagesのファイルを表示するようにしています。

pages/index.vue

ただのHello Worldを表示するだけのページです。tw-でプリフィックスをつけてます。

npm run devすると以下のようなページが表示され、cssが効いていることを確認できます。

また、開発モードでnuxi devで動かしている場合は、tailwind viewerも使えます。カタログを見るような感じでコードの記述が捗ります。

http://localhost:3000/_tailwind/

いい感じに動いてそうですね。

参考リンク

「アマゾンの最強の働き方」を読んだ

書店で見かけ気になったので購入して読んだ。数々のイノベーションを起こしてきたアマゾンではどのような働き方を実践しているのか、自分の職場や働き方をアップデートするヒントを得たい、というのが本書に向き合うモチベーションだ。

アマゾンといえば、「地球上で最もお客様を大切にする企業になる」という企業理念で知られている。多くの企業がマインド・アイデンディティである『企業理念』なるものを掲げているが、なかなか組織の活動や意思決定プロセスの細部まで、組織メンバーの大勢が徹底して実践できている企業は多くはないのではなかろうか。本書を読んで強く印象に残ったのは、理念を具体化した行動規範である「リーダーシップ・プリンシパル」があらゆる仕事とプロセスで実践されている、ということだ。バリューとも言えるだろうか。これは、一朝一夕で成されるものでなく、長い年月をかけて築き上げられるものである。こうして積みあげられた組織カルチャーが模倣困難性を高め、持続的な優位性の獲得につながっているのだと感じる。もちろん、AWSのような巨大なクラウドコンピューティングサービスを実現する技術もとんでもなくすごい。

本書では、現在アマゾンで展開されている、または、立ち上がったものの軌道にのることができなかった事業やサービスについて、実際に立ち上げに関わった著者の視点で当時の状況が説明されている。意思決定のプロセス、失敗に学ぶ姿勢など、まさにリーダーシップ・プリンシパルが実践されている様を感じとることができる。徹底的なこだわり、顧客志向の考え方など、学ベることが多い。

本書の中で、私が仕事の中ですぐに実践していきたいコミュニケーション手法の1つにナラティブ形式による資料というものがあった。1つは、有名な6ページ資料、もう1つは顧客ニーズを起点として新商品開発を行うワーキング・バックワーズである。いずれの手法も、練りに練られた思考を凝集し言語化したアウトプットの塊が成果物である。パワーポイントのような資料は一本道でストーリーを語るには適しているかもしれないが、深い思考を伴う検討が必要なプロセスにおいてはナラティブ形式が適しているというものらしい。このナラティブ形式のアイデア元は、イエール大学エドワード・タフテ教授の論文と記されている。私も企画でアイデア出しに関わることがある。パワーポイントのようなストーリーを語る形式とナラティブ形式を状況に合わせて使い分けていきたい。