Add Authenticated Portal Monitoring use case#64
Add Authenticated Portal Monitoring use case#64nibzard wants to merge 1 commit intohesamsheikh:mainfrom
Conversation
|
Note
|
| Cohort / File(s) | Summary |
|---|---|
Documentation Updates README.md |
Added reference entry for "Authenticated Portal Monitoring" use case in Productivity/Social sections. |
New Use Case Guide usecases/authenticated-portal-monitoring.md |
New comprehensive guide documenting the authenticated portal monitoring feature, including problem description, capabilities, setup steps, examples, and best practices. |
Estimated code review effort
🎯 1 (Trivial) | ⏱️ ~4 minutes
Suggested reviewers
- hesamsheikh
Poem
🐰 A portal monitored, with login in hand,
Screenshots and PDFs, as scheduled they stand,
Dashboards extracted from realms behind glass—
OpenClaw watches, reports come to pass! 📊✨
🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
| Check name | Status | Explanation |
|---|---|---|
| Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | ✅ Passed | The title directly and clearly summarizes the main change: adding a new use case documentation for authenticated portal monitoring. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
✏️ Tip: You can configure your own custom pre-merge checks in the settings.
✨ Finishing Touches
🧪 Generate unit tests (beta)
- Create PR with unit tests
- Post copyable unit tests in a comment
Tip
Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.
Comment @coderabbitai help to get the list of available commands and usage tips.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
usecases/authenticated-portal-monitoring.md (1)
62-74: Clarify where “changed from yesterday” state is stored.The example depends on comparing the current run to a previous run, but the doc never explains that the workflow needs a persisted baseline. Without that, “changed from yesterday” is underspecified.
Suggested addition
3. Create a recurring task or cron job. Example prompt: + +For any "changed since last run/yesterday" checks, persist the prior extracted values +or artifact metadata in memory/storage and compare against that baseline on the next run. ```text Every weekday at 8:30 AM, open the Acme partner portal and check:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@usecases/authenticated-portal-monitoring.md` around lines 62 - 74, The example cron job that checks "If the balance changed from yesterday" is missing a description of the persisted baseline; update the recurring-task example to state that the workflow must persist the previous-run state (e.g., store yesterday's balance and page snapshot in a durable store) and describe how to compare it on the next run: save a timestamped record (balance, page URL, optional PDF/screenshot) after each run and on subsequent runs fetch the last record to compute "changed from yesterday"; reference this stored key/name (e.g., "partnerPortal:lastRun:<date>" or "partnerPortal:lastBalance") and include instructions to update the record after sending the Telegram summary so the next run has the baseline.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@README.md`:
- Line 78: The README badge that displays the total use-case count still shows
"36" after adding the new entry; update the use-case count badge near the top of
README.md to reflect the new total (change "36" to "37") so the badge text and
any numeric alt/title text match the added table row for "Authenticated Portal
Monitoring"; ensure both the visible number in the badge markdown and any
tooltip/alt text are updated.
In `@usecases/authenticated-portal-monitoring.md`:
- Around line 42-74: Add an explicit "Secret handling" section to the doc that
tells readers not to embed credentials, cookies, or MFA data in standing
instructions or prompts (update the standing instruction block example and the
cron job example to reference this). In that section describe how to supply
credentials safely: use a secrets manager or environment variables injected at
runtime, use ephemeral session tokens or OAuth flows, delegate MFA to secure
device/manual step, rotate credentials regularly, restrict task access via RBAC,
and redact secrets from logs and outputs; also show a short example phrase to
place in prompts like "Credentials will be provided at runtime via the workspace
secret store" to make safe handling explicit.
---
Nitpick comments:
In `@usecases/authenticated-portal-monitoring.md`:
- Around line 62-74: The example cron job that checks "If the balance changed
from yesterday" is missing a description of the persisted baseline; update the
recurring-task example to state that the workflow must persist the previous-run
state (e.g., store yesterday's balance and page snapshot in a durable store) and
describe how to compare it on the next run: save a timestamped record (balance,
page URL, optional PDF/screenshot) after each run and on subsequent runs fetch
the last record to compute "changed from yesterday"; reference this stored
key/name (e.g., "partnerPortal:lastRun:<date>" or "partnerPortal:lastBalance")
and include instructions to update the record after sending the Telegram summary
so the next run has the baseline.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bddcfad5-3d7d-41a7-919e-738d169553b4
📒 Files selected for processing (2)
README.mdusecases/authenticated-portal-monitoring.md
| | [Second Brain](usecases/second-brain.md) | Text anything to your bot to remember it, then search through all your memories in a custom Next.js dashboard. | | ||
| | [Event Guest Confirmation](usecases/event-guest-confirmation.md) | Call a list of event guests one-by-one to confirm attendance, collect notes, and compile a summary — fully automated via AI voice calls. | | ||
| | [Phone Call Notifications](usecases/phone-call-notifications.md) | Turn your agent's alerts into real phone calls — morning briefings, price drops, urgent emails — with two-way conversation. | | ||
| | [Authenticated Portal Monitoring](usecases/authenticated-portal-monitoring.md) | Log into JS-heavy portals, extract updates, and send scheduled screenshot/PDF reports from OpenClaw. | |
There was a problem hiding this comment.
Update the use-case count badge.
After adding this entry, the badge on Line 14 still advertises 36 use cases, so the README becomes inconsistent immediately.
Suggested fix
-
+📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | [Authenticated Portal Monitoring](usecases/authenticated-portal-monitoring.md) | Log into JS-heavy portals, extract updates, and send scheduled screenshot/PDF reports from OpenClaw. | | |
|  |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@README.md` at line 78, The README badge that displays the total use-case
count still shows "36" after adding the new entry; update the use-case count
badge near the top of README.md to reflect the new total (change "36" to "37")
so the badge text and any numeric alt/title text match the added table row for
"Authenticated Portal Monitoring"; ensure both the visible number in the badge
markdown and any tooltip/alt text are updated.
| ## How to Set It Up | ||
|
|
||
| 1. Add the `steel-browser` skill to your OpenClaw workspace. | ||
|
|
||
| 2. Give OpenClaw a standing instruction like this: | ||
|
|
||
| ```text | ||
| You monitor authenticated web portals for me. | ||
|
|
||
| When I give you a portal-monitoring task: | ||
| - use the steel-browser workflow | ||
| - log in and navigate the site step by step | ||
| - extract only the fields I ask for | ||
| - capture a screenshot or PDF when the page is important or when something changed | ||
| - return a concise summary first, then attach evidence | ||
| - if login fails or the page structure changes, report exactly where it failed | ||
|
|
||
| Do not guess values. If a field is missing or unclear, say so explicitly. | ||
| ``` | ||
|
|
||
| 3. Create a recurring task or cron job. Example prompt: | ||
|
|
||
| ```text | ||
| Every weekday at 8:30 AM, open the Acme partner portal and check: | ||
| - new orders | ||
| - failed orders | ||
| - unread support escalations | ||
| - account balance | ||
|
|
||
| Send me a short summary in Telegram. | ||
| If failed orders or escalations exist, include a screenshot of the relevant page. | ||
| If the balance changed from yesterday, export the billing page as PDF. | ||
| ``` |
There was a problem hiding this comment.
Add explicit secret-handling guidance for portal credentials.
This setup walks readers through authenticated monitoring, but it never says how to supply credentials safely. In practice, people will copy passwords, session cookies, or MFA material into standing instructions unless the doc tells them not to.
Suggested addition
## How to Set It Up
1. Add the `steel-browser` skill to your OpenClaw workspace.
+
+2. Store login credentials outside prompts and version-controlled files.
+ - Use your platform's secret store, environment variables, or an interactive login/session flow.
+ - Do not paste passwords, session tokens, or MFA seeds into README snippets, cron definitions, or checked-in config.
-2. Give OpenClaw a standing instruction like this:
+3. Give OpenClaw a standing instruction like this:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@usecases/authenticated-portal-monitoring.md` around lines 42 - 74, Add an
explicit "Secret handling" section to the doc that tells readers not to embed
credentials, cookies, or MFA data in standing instructions or prompts (update
the standing instruction block example and the cron job example to reference
this). In that section describe how to supply credentials safely: use a secrets
manager or environment variables injected at runtime, use ephemeral session
tokens or OAuth flows, delegate MFA to secure device/manual step, rotate
credentials regularly, restrict task access via RBAC, and redact secrets from
logs and outputs; also show a short example phrase to place in prompts like
"Credentials will be provided at runtime via the workspace secret store" to make
safe handling explicit.
This adds an authenticated portal monitoring use case plus the matching README entry.
The workflow shows how OpenClaw can monitor JS-heavy portals that do not have stable APIs: log in, extract the fields you care about, and attach screenshots or PDFs as evidence when something changes.
Related links:
Example use cases covered in the new page:
Summary by CodeRabbit
New Features
Documentation