Posts

独自ドメインを導入したら、ブログの表示崩れが発生したので原因と対策を調べた。 予兆 事件の予兆は発生していた。 GitHubで独自ドメイン設定をした後git pushがうまくいかない。 原因はGitHub側で生成されるファイル「CNAME」。 CNAMEの内容としては設定している独自ドメインが記載されているだけ。 上記のgit pushエラーに対してはgit pullを行うことで解消した。 git pull origin master git pullを経て無事git pushが成功した。 表示崩れが発生 上記git pushの結果表示崩れが発生した。 GitHub上の独自ドメイン設定を確認するとドメイン設定が消えている。 gitのログを見るとCNAMEファイルの削除が発生していた。 何が起きたか hugoコマンドでCNAMEが消されていた。 詳細には、–cleanDestinationDirオプションをつけて、毎回不要ファイルの削除を行っている。 この削除対象にCNAMEファイルが入っているようで、毎回削除された状態でGitHubにpushされていたようだった。 対策 CNAMEファイルのマスターを退避し、毎回コピーするscriptに差し替えた。 現状のdeploy用のスクリプトは以下の通り。 #!/bin/sh echo -e "\033[0;32mDeploying updates to GitHub...\033[0m" hugo --cleanDestinationDir cp ./CNAME docs git add docs/ msg="rebuilding site `date`" if [ $# -eq 1 ] then msg="$1" fi git commit -m "$msg" git push origin master

はじめに 引き続き読み進めていく。 RFCらしい文体が目立ってきた。 2.クライアント登録 クライアントは事前に認可サーバへの登録が必要。 2.1クライアントタイプ 2つのクライアントタイプがある。 コンフィデンシャル クレデンシャルの秘密が保持できるクライアント。セキュアなサーバなど。 パブリック クレデンシャルの秘密が保持できないクライアント。スマホアプリなど。 2.2クライアント識別子 文字列。秘密じゃないので、これだけで認証に使うのは禁止。 2.3クライアント認証 クライアントタイプがコンフィデンシャルな場合は、クライアントの認証を行う。 方式はパスワード認証か、それ以外か。 2.3.1クライアントパスワード クライアントIDとクライアントシークレット（ID/パスワード）を利用して認証する。 ここには、いくつか注意事項の記載がある。「basic認証のサポートは必須」「TLSの利用が必須」「ブルートフォースアタック対策は必須」など。 2.3.2その他の認証方式 その他の認証方式を利用してもいいけど、明確にすることが必須。 2.4未登録クライアント 未登録クライアントを利用してもいい。（「本仕様で利用を排除するものではない」というRFCらいし書き方。） ただし、そのような利用は、本仕様のスコープ外。各自、セキュリティに気をつけて考えてね。

RFCを読もう 業務でAPI GWの認証認可部分を担当することになった。 引継ぎ元となる先輩に認証認可の入門書のオススメを聞いたところ、 「世の中の入門書は中級者向けだから、RFC読めばいいよ」という、お言葉をいただいた。 そこで、はじめてRFCを読むわけだが、 人目見ただけで分量に嫌気が差した。 世の中には簡単に説明している記事はあるが、読みたいのはあくまでRFC。 そこで、あくまでRFCの記載内容にしたがって、簡単に要約してみる。 今回はRFC6749を読むことにする。 なお、実装にあたっては厳密性が重要になるため、原文（もちろん英語版）で理解することが前提とのこと。 1.はじめに 要約と言いつつ、さっそく銀行と通帳アプリで例えることにする。 通帳アプリに銀行のパスワード教えるのはいまいちだよね。 なぜなら 通帳アプリが利用者本人とまったく同じ権限使えるよね。 利用者が通帳アプリを複数使っていた場合、アプリごとに利用を停止できない。パスワード変更すれば停止できるけど、全部利用止まっちゃうよね。 通帳アプリの情報漏洩が問題だよね。 という理由。 そこで、権限移譲用の別のトークンを用意しよう！ 1.1登場人物 登場人物は以下の4種類。 リソースオーナー：通帳アプリの利用者（個人情報のオーナーってイメージ） リソースサーバ：銀行のサーバ。 クライアント：通帳アプリ 認可サーバ ：通帳アプリにトークンを発行するサーバ 。銀行のサーバと同じでもいいし、違うかもしれない。 1.2プロトコルフロー プロトコルフローは大きく分けると3つの工程で成り立っている。 クライアントとリソースオーナーのやりとり。 クライアントは認可を要求し、認可グラントを受け取る。 クライアントと認可サーバのやりとり。 クライアントは認可グラントを提示し、アクセストークンを受け取る。 クライアントとリソースサーバのやりとり。 クライアントはアクセストークンを提示し、リクエストが成立する。 1.3認可グラント ここからは用語の説明。 認可グラントは、リソースオーナーが認可したことを表すものだよ。 グラントタイプは4種類。 認可コード インプリシット リソースオーナーパスワードクレデンシャル クライアントクレデンシャル それぞれ説明します。 1.3.1認可コード 認可サーバが発行する秘密の文字列。 クライアントはリソースオーナーを認可サーバにリダイレクトする。 認可サーバ上で認証されたら、認可コードとともにリダイレクトされて、戻ってくる。 セキュリティ的にgood. 1.3.2インプリシット 認可グラントを渡さず、直接アクセストークンをクライアントに返す。 認可コードフローを短縮したもの。そもそも上で説明した認可コードフローと違うことをやってる。 1.3.3リソースオーナーパスワードクレデンシャル IDとパスワードのようなもの。 はじめにで記載されているイマイチな例。 ただし、クライアントがOSの一部の場合はいいんじゃないか、ということ。 1.3.4クライアントクレデンシャル 秘密の文字列。 あらかじめクライアントと認可サーバの間で取り決めておく。 認可範囲がクライアントの管理かである場合に使う。 1.4アクセストークン 秘密の文字列。リソースへアクセスする際に使う。 1.5リフレッシュトークン オプションの項目。 期限が切れたアクセストークンの代わりに、新しいアクセストークンをもらうために利用することができる。 アクセストークンの有効期限が切れるたび認可グラントを提示するのはセキュリティリスクが高まる。 リフレッシュの際には、専用のトークンを利用することで、認証情報のやりとりを減らすことができる。 リフレッシュトークンを利用する流れは以下の通り。 クライアントと認可サーバのやりとり（認可フローの2に相当） ...

AWS認定　Solution Architect associateに合格したので勉強したポイントを記録する。 インプット学習 まずは、有名な黒本をメルカリで購入した。正直あまり読んでない。 改訂新版 徹底攻略 AWS認定 ソリューションアーキテクト − アソシエイト教科書［SAA-C02］対応 徹底攻略シリーズ ひたすら、black belt Onlineセミナーをyoutubeで見ていた。 腹落ちしてない分野は2回、3回と繰り返し確認。 アウトプット学習 udemyの試験対策講座を受講した。 「問題を解く」→「間違った分野のblackbeltセミナーや公式documentを見返す」ということを繰り返す。（2-3テスト分） 申し込み前には、公式の模試を受験した。8割取れてたので、申し込みを決意。 試験当日 自宅から最寄りの試験会場を選択した。 試験開始1.5時間前には同じビルのスタバに入って追い込みをした。 復習のつもりでよくある質問を読み返していたら、はじめて知る知識もあって少し焦った。 つまづきポイント 自分がつまずいたポイントは以下の通り。 IAM ユーザ、ロール、ポリシーがごっちゃになった。 さらに（AWS）アカウントという用語もあり、整理が必要。 実際に触っているとすぐ腹落ちした。 EC2のコスト最適化 EC2のスポットインスタンス、RIやsaving plansなどが最後まで混乱していた。 自腹で実機を触っていれば感覚が違ったかも？ S3のコスト最適化 こちらも同じ。IAとかが最後まで頭の中でごっちゃになっていた。 上記EC2とまとめて、直前にまとめて整理すると理解できた。

hugoをHitHub pagesへのデプロイする際に利用するスクリプトを作成した。 local deploy コンテンツを生成し、ローカル確認するためにサーバーを起動する。 こちらは単純。 hugo; hugo server -D deploy 確認した結果を、GitHubリポジトリにpushするためのスクリプト。 全体の整合性を担保するために、リコンパイルを実施している。 #!/bin/sh echo -e "\033[0;32mDeploying updates to GitHub...\033[0m" hugo git add docs/ msg="rebuilding site `date`" if [ $# -eq 1 ] then msg="$1" fi git commit -m "$msg" git push origin master こちらを参考に作成した。