保存した認証情報が自動処理で使えないときの確認手順 - Smart Work Lab

自動処理を動かしたのに「認証情報が見つからない」と表示される。保存し直すべきか迷いますが、今回の作業では、値を入れ直す前に確認すべき場所のずれが原因でした。

この記事では、ブログの更新作業で実際に起きたことと、同じ症状が出たときの確認順をまとめます。会社名、サービス名、認証情報の中身は掲載していません。

先に確認すること：設定と処理コードの置き場所

自動処理の認証情報は、保存した場所からどの実行環境でも自動的に読めるとは限りません。まず次の二つを見比べます。

この二つが違えば、設定が正しく保存されていても、実行側からは未設定に見えることがあります。値を何度も貼り直す前に、実行先の画面と設定先の画面で、対象が一致しているかを確認します。

ブログ記事の更新を自動化するため、保存済みの認証情報を使う処理を準備しました。最初の実行では認証情報が見つからない状態になりました。

調べると、設定を保存した場所と、処理コードを置いた場所が別でした。処理コードを別のリポジトリに作ってしまったのは、こちらの作業手順の誤りです。設定を入れ直す必要はありませんでした。

コードを設定済みのリポジトリへ移して実行し直すと、認証確認が通り、対象記事の更新も完了しました。実際の値はログに出さず、認証が通ったかどうかだけで確認しています。

失敗した実行履歴を開き、どのリポジトリ、ブランチ、ワークフローが動いたかを確認します。似た名前のリポジトリが複数ある場合は、表示名だけで判断せず、実行履歴のURLと設定画面のURLを照らし合わせます。

認証情報が、実行先と同じリポジトリに保存されているかを確認します。組織共通や環境別の設定を使う場合は、対象リポジトリへの利用許可や、実行時に選ばれた環境も確認します。

手動実行、定期実行、別ブランチからの実行では、設定の参照条件が異なることがあります。ワークフローの条件分岐や環境指定を見て、今回の起動方法で設定が使えるか確かめます。

ログに認証情報そのものを出すのは避けます。必要なら、値が空かどうかだけを判定して「設定あり／なし」と表示します。画面共有やスクリーンショットを使う場合も、値やユーザー名が写っていないか確認してから共有します。

いきなり本番データを書き換えず、まず読み取り専用の認証確認を行います。認証が通ったあとで、更新対象と処理内容を確認し、必要な変更だけを実行します。失敗した場合は、HTTPの状態とエラーコードを記録し、レスポンス本文や認証ヘッダーは記録しません。

保存した認証情報が自動処理で使えないときは、すぐに再入力するより、まず「設定の保存先」と「コードの実行先」が一致しているかを確認します。今回のケースでは配置先のずれを直すことで認証と記事更新が通りました。

認証情報は再掲せず、実行場所、利用範囲、起動条件の順に確認する。この順番なら、値を不用意に表示したり、同じ設定を何度も作り直したりせずに原因を絞れます。

この記事は、実際の更新作業で確認できた経緯をもとに作成しています。環境や設定方法によって確認項目は異なるため、画面の名称や手順は利用中の仕組みに合わせてください。