ログイン後に何が変わるか
ログイン後のページは、URLだけでなくブラウザ状態に依存します。- 認証済みであることを示すセッションCookie
- フォーム送信やAPI呼び出しに必要なCSRF tokenやheader
- SPAが使うlocalStorage/sessionStorage
- 未ログイン時に
/loginへ戻すredirect - 時間、非操作、IP変更、セキュリティ検知による期限切れ
方法1: Cookieを再利用する
もっとも一般的なのは、一度ログインして得たCookieを保存し、次回以降の実行で再利用する方法です。セッションが数時間から数日有効で、IPや端末に強く紐づいていないサイトで有効です。 Cookieは認証情報と同等に扱います。ソースコードに直書きせず、安全に保存し、期限切れ時に更新します。サーバーサイドレンダリングのページや、ブラウザと同じCookieでAPIが使えるサイトでは特に有効です。一方、短命token、端末チェック、頻繁な再認証があるサイトでは壊れやすくなります。方法2: ブラウザでログインする
JavaScriptが重いログインページ、リダイレクト、OAuth/SSO、localStorageを使うサイトでは、実ブラウザでログイン操作を再現する方が安定します。ブラウザでログインし、完了後のstorage stateを保存し、次回はその状態から開始します。 この方法はHTTPだけの実装より重くなりますが、ログインフロー全体を自然に通過できるのが利点です。Octoparseのようなビジュアルツールもこの考え方に近く、内蔵ブラウザで一度ログインしてCookie/セッションを保存するか、タスク内でログイン操作を再現できます。方法3: ログインAPIを再現する
ログインフォームが単純なPOSTリクエストを送っているだけなら、HTTP clientで再現できる場合があります。ただし、多くの認証フローにはCSRF token、bot check、端末指紋、hidden field、リダイレクトが含まれます。Networkタブで確認し、単純に再現できる場合だけ使います。MFAとSSO
MFAを回避しようとするべきではありません。人がログインしてセッションを保存する、公式APIやservice accountを使う、セッション期限切れを前提にrefresh/re-loginを設計する、といった形で扱います。個人アカウントを無人の本番ジョブに使うのは避けるべきです。 SSOは組織ポリシー、複数ドメイン、セキュリティプロンプトが絡みます。永続ブラウザプロファイルや公式連携の方が、素のHTTP clientより現実的なことが多いです。セッション安全性
- タスクごとにアカウントを分離する
- 1セッション内ではIPとブラウザIDを安定させる
- ログイン後ページでは特にrate limitを守る
- ログアウトページをデータページとして誤解析しない
- Cookie、storage state、認証情報を安全に保存する
- ログに個人情報や認証情報を書かない