環境 windws11 node => v20.11.0 npm => 10.4.0 nuxt => 3.10.1 install 公式の手順に従っていく。 Installation · Get Started with Nuxt npx nuxi@latest init <project-name> ❯ Which package manager would you like to use? ● npm ○ pnpm ○ yarn ○ bun 上記を実行すると、エラーが発生した。 npm ERR! gyp ERR! cwd C:~\node_modules@parcel\watcher npm WARN cleanup Failed to remove some directories [ npm WARN cleanup [ npm WARN cleanup 'C:\\project\\project-name\\node_modules', npm WARN cleanup [Error: EPERM: operation not permitted, scandir 'C:\project\project-name\node_modules\resolve\test\resolver\multirepo\packages\package-a'] { npm WARN cleanup errno: -4048, npm WARN cleanup code: 'EPERM', npm WARN cleanup syscall: 'scandir', npm WARN cleanup path: 'C:\\project\\project-name\\node_modules\\resolve\\test\\resolver\\multirepo\\packages\\package-a' npm WARN cleanup } npm WARN cleanup ], npm WARN cleanup [ npm WARN cleanup 'C:\\project\\project-name\\node_modules\\@vercel', npm WARN cleanup [Error: EPERM: operation not permitted, rmdir 'C:\project\project-name\node_modules\@vercel\nft\node_modules\@rollup\pluginutils\dist'] { npm WARN cleanup errno: -4048, npm WARN cleanup code: 'EPERM', npm WARN cleanup syscall: 'rmdir', npm WARN cleanup path: 'C:\\project\\project-name\\node_modules\\@vercel\\nft\\node_modules\\@rollup\\pluginutils\\dist' npm WARN cleanup } npm WARN cleanup ] npm WARN cleanup ] npm ERR!...

最近鳴りを潜めていたブログをリニューアルしたいという欲望が、新年早々むくむく頭をあげてきたので、欲望のままにリニューアルすることにした。 今までのブログ歴 初めてブログを立ち上げた時は、WordPressの無料テーマを使った。確かあれは新卒で入社したWebサイト制作会社を退職した時で、コードを書くことに飢えていた。そこでブログを立ち上げ、「実験だ」と、無料テーマをカスタマイズしては楽しんでいた。 それから1年後くらいにWordPressの自作テーマを作りたくなり、リニューアルした。リニューアルした後も色々新規ページを作って楽しんだりしていた。記事のメインは技術についてで、それなりに見てくれる人も多く、有難いことに副業の依頼もいただけたりした。 徐々にWordPressに慣れてくると、次にWordPress以外のプラットフォームでブログを作りたいという欲求がむくむくと頭を上げ始めた。 そこで当時話題になっていたmicroCMSとNetlifyとNuxt2で静的ブログを作成した。これもまたいい経験であった。転職活動の時にいいポートフォリオになってくれたし、それなりの知見を得ることができた。 そのあと、またWordPressに戻り2度ほどテーマを作成し、拡張機能(Create Eye Catch For Classic)も作成した。 そして今に至るのである。 書いた記事は資産になるはずだがどこかに消えた ということで今まで、5回ブログをリニューアルしている。テーマだけを変えればいいのだが、そのたびサーバーを変えているので、記事の記録はすべて引き継がれていない。これは自分が悪いのだが、エクスポートするのもそれなりに面倒くさいことはわかってほしい。 そんな面倒なことはしたくないが、きっと今後もブログはリニューアルし続けるに違いない。そのたびに今までのように記事が失われるのは避けたいということで、Githubで記事を管理することにした。Githubで記事を管理し、それをWordPressにポストする。これが最適解に思えたのだが、運用してみるとこれが何とも面倒くさい。 特に編集するときが面倒くさい。 まずGithubで変更し、そのあと修正をWordPressの投稿画面でチェックする。問題がなければ公開する。なんとも面倒で仕方ない。 Githubでcommitするたびに記事が公開されればいいのに、という思いになり、静的サイトジェネレータを使うことにした。 ヘッドレスCMSでもいいのだが、すべてのソースコードがGithubに集約されているので、管理画面をこれ以上増やしたくない。 そういうことでこのブログを立ち上げることにした。 ブログリニューアルした っていうのも6回目となる。 どうせまたリニューアルするけど、記事はそのまま資産にできる。

タイトルにあるようにSwaggerで作成したいのであれば、yamlを作成すればいい。 だけど、そんなことをするのは面倒くさい。 というのもNestJsではデコレーターを追加するだけで自動でSwagger UIを作成してくれた。 そこでGoでも同様な手順で実現できるライブラリを探してみた。 swaggo/swag swaggo/swagを使えばできそうだったので試してみた。 インストール go install github.com/swaggo/swag/cmd/swag@latest アノテーションを作成する main.goにアノテーションを追加する。 // @title sample api // @version 1.0 // @description this is sample apigw // @host localhost:18080 // @BasePath /api/v1 // @tag.name accounts // @tag.description about accounts request func main() { handlers.HandleRequests() } 記入後にswag initを実行する。 . ├── docs.go ├── swagger.json └── swagger.yaml すると上記ファイルたちが生成される。 UIで確認する これがいまいちわかなかったので、https://editor.swagger.io/に生成されたyamlファイルをコピペして見る方法にしているけど、localhost:18080/api/v1で見られるんだと思われる。 …見れないので、要調査。 ⚠️ 違った。 localhost:18080/api/v1 上のURLはBaseURLだった。 まあ、問題ないので、いったん上記方法で行く。 追記：2023.12.30 Swagger ViewerVSCodeの拡張機能があった。 個別APIのアノテーションを作成する // GetAccount // @summary アカウントの情報を返します // @description user_idを元にアカウント情報を返します // @tags accounts // @produce json // @success 200 // @failure 401 // @router /accounts [get] func FetchUserById(w http....

アクセストークンの有効期限は短く ログイン認証を作るうえで、アクセストークンの有効期限は短い方がいい、という情報を得た。 アクセストークンが盗まれた時に、備えてのことらしい。 例えば15分とか、って例で書かれていた。 そうすると15分ごとにログインをし直させなければならない。 それはユーザビリティ的にどうなのだろうか。という疑問が生まれた。 それを解決するのがリフレッシュトークンらしい。 アクセストークンとリフレッシュトークン リフレッシュトークンはアクセストークンを再発行するために必要になる。 例えば、ログインをしアクセストークンを取得する。 15分後、アクセストークンが切れた場合はリフレッシュトークンを使用し、アクセストークンを再発行する。 その際、リフレッシュトークンも最新化する。 これで15分ごとにユーザーがログインし直すという苦痛から解放することができる。 アクセストークンは危険で、リフレッシュトークンは安全なの？ アクセストークンもリフレッシュトークンも一緒に得ることができ、同じように保存をしておく必要がある。 それなのにどうしてアクセストークンは危険で、リフレッシュトークンは安全なのだろうか。 ってずっと疑問だったけど、社内の博士に聞き解決した。 確率の問題 アクセストークン、リフレッシュトークンが盗まれるのは通信中である。 通信にアクセストークンを持たせて、15分間、何回通信をするだろうか。 それに比べてリフレッシュトークンはアクセストークンが失われた時にしか使用されないので、リフレッシュトークンに比べて安全だと言える。 ということ。

期待するもの 新規登録のAPIを作成したので、次はログイン機能を作成したい。 ログインは、メールアドレスとパスワードを送り一致したら、tokenを取得する。 で、tokenを使って認証付きのAPIを叩けるようになりたい。 tokenにはjwtを使用する。 jwtってなに？ これはどこかで調べてまとめる（気が向いた時）。 JWT認証を作成する パッケージのインストール github.com/dgrijalva/jwt-goパッケージの情報が多かったので、それに従うことにする。長い物には巻かれるべきで間違いない。 go get github.com/dgrijalva/jwt-go パッケージをインストールする。 Tokenを生成する まずjwt.goというファイルを作成する。 今回はauthフォルダの中に作成した。 それでは書いていく。 まずは、jwtを生成するためのシークレットキーを作成する。 var jwtKey = []byte("your_secret_key") ここでは任意の文字列（今回は"your_secret_key"）をバイト列に変換し、jwtKeyに代入している。 バイト列というのがピンとこないので、 fmt.Printlnで書き出しみると、[121 111 117 114 95 115 101 99 114 101 116 95 107 101 121]となった。なんとなく理解した。 このようにして文字列をバイト列に変換することは、多くの場面でデータの操作や処理に利用されます。JWTの署名などのセキュリティ関連の操作では、シークレットキーをバイト列として扱うことが一般的です。 とのことでした。 次に、JWTのクレームを表す構造体であるClaimsを定義する。 これは任意のJSONデータっていう意味っぽい。 type Claims struct { Name string `json:"name"` jwt.StandardClaims } 今回はnameを含めることにする。 と思ったけど、ユニークで必要がありそうなので、ユーザーIDにした。 下記のように変更する。 type Claims struct { UserID uint `json:"user_id"` jwt.StandardClaims } 次に、Tokenを作成する関数を作成する。 コードの詳細はコメントアウトに書いた。 func generateToken(userId uint) (string, error) { // トークンの有効期限を設定(この場合は15分) expirationTime := time....