Automating Business Login Checks with Playwright: Eliminate Manual Verification

Introduction

In environments with many business systems protected by a common CAS/SSO, operators often wonder whether the services are merely "up" or actually usable. Simple ping or HTTP checks confirm the service is running, but users may still encounter login failures caused by DNS issues, incorrect callbacks, routing problems, or cookie domain mismatches.

Why Simple Checks Aren’t Enough

The real verification needed is the full login flow: open the business entry, follow the CAS redirect, fill credentials, click login, and finally reach the business homepage.

Open entry → CAS redirect → Fill credentials → Click login → Successful landing on business home page

Comparison of Monitoring Approaches

方式: 基础设施监控 (Zabbix, Prometheus, 云监控等) | 在监控什么: CPU、内存、端口、进程、HTTP 存活 | 优点: 成熟、告警快、适合 7×24 | 局限: 只知道「服务在跑」，不知道「登录链路通不通」

方式: APM / 链路追踪 (SkyWalking, Pinpoint) | 在监控什么: 接口耗时、错误率、调用链 | 优点: 定位后端问题很强 | 局限: 对 SSO 跳转、前端路由、iframe 登录页覆盖有限

方式: 人工登录验证 | 在监控什么: 真人点一遍 | 优点: 最真实，能顺带看 UI | 局限: 靠人、不可定时、容易漏、无法覆盖全部系统

方式: HTTP / API 探测 | 在监控什么: 固定 URL 返回码、JSON 字段 | 优点: 轻量、易集成 CI | 局限: 当 CAS 需要 Cookie、302 链复杂时，与真实浏览器行为不一致

方式: 模拟登录（浏览器自动化） | 在监控什么: 真 Chrome 填表、点按钮、看跳转 | 优点: 最接近用户 | 局限: 较重，要维护账号、成功条件、运行环境

方式: Synthetic 监控 (Datadog Synthetics, Pingdom) | 在监控什么: 云端定时跑脚本 | 优点: 省运维、有截图录像 | 局限: 内网系统往往出不去，还要考虑账号安全

方式: 前端埋点 / 监控 (Sentry、自研上报) | 在监控什么: JS 错误、白屏、接口失败 | 优点: 抓真实用户侧问题 | 局限: 用户没访问就发现不了，登录前断链也可能无埋点

方式: 健康检查接口 (/actuator/health 等) | 在监控什么: 应用自报状态 | 优点: 简单 | 局限: 多数不包含 SSO 全链路

Design of the sys‑monitor Tool

The tool, named sys-monitor , uses Playwright’s real‑browser automation to execute the login flow for each configured target. It runs as a scheduled job (cron) or can be triggered manually via HTTP endpoints.

定时任务 / 手动 HTTP 触发
    ↓
Java 读取 yml 中的「要测哪些系统」
    ↓
每个目标：启动一个 Node 进程，Playwright 打开 Chrome
    ↓
打开入口 URL → CAS 填账号 → 点登录 → 校验成功
    ↓
汇总结果 + 失败发送邮件

Key Design Points

Failure of one target does not block subsequent targets (e.g., DNS failure of task‑management does not stop EHR checks).

Separate dev and prod profiles: dev profile tests many systems; prod profile tests a limited core set.

Success criteria are URL‑based (e.g., the final URL must contain tianluodev.com/admin) to avoid brittle DOM selectors.

Local debugging can run with a headed browser to visually confirm the steps.

Configuration Example (excerpt)

monitor:
  cron: "0 0 8 * * ?"   # 每天早上 8 点
  interval-between-targets-ms: 5000
  targets:
    - name: 【浏览器】任务管理-tianluodev-管理后台登录
      url: https://tianluodev.com/admin.com/api/v1/task-service/cas/login?url=...
      mode: browser
      browser-success-url-contains: "tianluodev.com/admin"

Credentials are stored in a private yml (outside Git) and passed to the Playwright script via environment variables.

Key Source Code

Java Side – Launch Node Process

ProcessBuilder pb = new ProcessBuilder(pw.getNodePath(), "run-probe.js");
pb.directory(scriptDir);
Map<String, String> env = pb.environment();
env.put("ENTRY_URL", target.getUrl());
env.put("USERNAME", resolveBrowserUsername(target, cas));
env.put("PASSWORD", resolveBrowserPassword(target, cas));
env.put("SUCCESS_URL_CONTAINS", target.getBrowserSuccessUrlContains());
env.put("HEADLESS", String.valueOf(pw.isHeadless()));
// ... start process and parse JSON output {"ok":true/false,...}

Node Side – Playwright Login Flow

await page.goto(entryUrl, {waitUntil: 'domcontentloaded'});
const loginRoot = await resolveLoginRoot(page, timeoutMs); // supports iframe CAS
await loginRoot.locator('input[name="username"], #username, ...').first().fill(username);
await loginRoot.locator('input[type="password"]').first().fill(password);
await clickCasLogin(page, loginRoot);
page = await waitLeaveCas(page, browser, timeoutMs);
if (successUrlContains) {
  await page.waitForFunction(part => window.location.href.includes(part), successUrlContains, {timeout: timeoutMs});
}
console.log(JSON.stringify({ok: true, url: page.url(), costMs: ...}));

On failure the script captures a screenshot and HTML snapshot for later analysis.

Linux Deployment

On Windows developers run headed Chrome for interactive debugging. On headless Linux servers the following steps install dependencies and run the monitor:

sudo ./startup/install-centos.sh   # installs JDK, Node, Playwright Chromium, graphics libs
vi application-prod-private.yml   # configure CAS account and alert email
mvn package && cp target/sys-monitor-*.jar sys-monitor.jar
export PLAYWRIGHT_BROWSERS_PATH=/opt/sys-monitor/playwright-browsers
export MONITOR_HEADLESS=true
./startup/runStart.sh start

Important considerations:

Headless mode is required because servers lack a desktop.

Install system libraries via playwright install-deps.

Ensure network can resolve and reach SSO and business domains (VPN / internal DNS).

Use dedicated low‑privilege accounts; keep passwords out of code repositories.

Cron runs daily, but systemd timers or external schedulers are also possible.

Each target launches a browser sequentially; testing six systems takes a few minutes.

Conclusion

When many services share a unified SSO, "service up" does not equal "users can log in".

Infrastructure monitoring, APM, and manual checks each have value, but none cover the full login chain.

Playwright‑based simulated login provides the most realistic verification, with configurable targets, failure alerts, and non‑blocking execution.

The solution runs on Linux headlessly via a simple install script, while Windows is convenient for interactive debugging.