Serve notifications for the validated account only

[hiveuprss]

The body's user field still chose whose feed /private-api/notifications read after a code validated, so a signed-in caller could ask for another account. The account now comes only from ValidateCode, matching UnreadNotifications. A body that names someone else is ignored, and the upstream path segments stay percent-encoded.

[qodo-code-review]

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 1fedcd9f-cd4e-4df2-a4b4-461e3e1c5492

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Serve notifications only for the validated account

🐞 Bug fix 🧪 Tests 🕐 10-20 Minutes

AI Description

• Use the validated code, not the request body, to select the notifications account.
• Keep full-feed access limited to that account and preserve encoded upstream paths.
• Test mismatched account names, invalid codes, and the resulting upstream requests.

Diagram

graph TD
  A["Notifications request"] --> B["Validate code"] --> C{"Valid account?"} -->|Yes| D["Select code account"] --> E["Build encoded path"] --> F["Enotify feed"]
  C -->|No| G["Unauthorized response"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Reject mismatched body users

• ➕ Makes a conflicting account name explicit to callers.
• ➖ Breaks callers that send a different user field, rather than serving the authorized account.

Recommendation: Keep the PR's code-derived account selection: it closes the account-override path while preserving requests that include a user field. Rejecting mismatches is worth considering only if the API intends that field to be a validated assertion rather than ignored input.

Files changed (2) +138 / -35

Bug fix (1) +30 / -21

PrivateApi.UserData1.csBind the notifications feed to the validated account +30/-21

Bind the notifications feed to the validated account

• The resolver now returns only the account established by code validation, with full scope, or denies requests without a validated account. Replaceable validation and upstream delegates enable handler tests; existing path-segment encoding remains in place.

dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs

Tests (1) +108 / -14

NotificationsAuthorizationTests.csCover code-only notification authorization through the handler +108/-14

Cover code-only notification authorization through the handler

• Revises resolver tests to require the validated account regardless of the body's user value. Adds handler tests that record upstream requests and verify full-scope paths, ignored mismatched names, and HTTP 401 without an upstream call for invalid codes.

dotnet/EcencyApi.Tests/NotificationsAuthorizationTests.cs

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

1. Deck columns mislabel notifications 🔗 Cross-repo conflict ≡ Correctness

Description

ResolveNotificationsTarget now ignores the body's user and returns the validated account with
full scope. In vision-web, a notifications deck column sends its selected account as user
alongside the signed-in account's code, then displays the returned feed under the selected account's
name.

Code

dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[R38-39]

+        _ = requestedUser;
+        return (validatedUsername, true);

Evidence

The PR always selects the validated username. Vision-web sends a separately configured username in
the request and renders the response in a column headed with that configured username.

vision-api -> vision-web
dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[28-39]
External repo: ecency/vision-web, apps/web/src/app/decks/_components/columns/deck-notifications-column.tsx [94-115]
External repo: ecency/vision-web, apps/web/src/app/decks/_components/columns/deck-notifications-column.tsx [137-165]
External repo: ecency/vision-web, packages/sdk/src/modules/private-api/requests.ts [105-139]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Vision-web's notifications deck requests a selected account's feed using the signed-in account's code. The API now returns the signed-in account's feed instead, which the deck labels as the selected account.

## Fix Focus Areas
- dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[28-39]
- apps/web/src/app/decks/_components/columns/deck-notifications-column.tsx[94-115]
- packages/sdk/src/modules/private-api/requests.ts[105-139]

## Recommended Fix
Keep code-validated access restricted to its own account. Coordinate a vision-web change so cross-account deck columns use an explicitly supported restricted public feed, or disable that selection; reject mismatched `user` values in the API rather than silently returning a differently named account's feed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Notification changes lack a parity record 📘 Rule violation ▣ Testability

Description

ResolveNotificationsTarget now ignores the body's user field and serves the validated account,
but this endpoint has no corresponding entry in the parity divergence list. Requests that name
another account now produce a different upstream path than the reference implementation, while the
parity harness has no record explaining that intentional difference.

Code

dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[R38-39]

+        _ = requestedUser;
+        return (validatedUsername, true);

Evidence

Rule 2667942 requires both a matching automated test change and a parity divergence entry for an
observable endpoint change. The resolver now returns the validated account regardless of the body
field, and the new handler test covers that case, but the parity harness's divergence list contains
no notifications entry.

Rule 2667942: Require tests and parity divergence docs for observable endpoint behavior changes
dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[28-39]
dotnet/EcencyApi.Tests/NotificationsAuthorizationTests.cs[138-154]
dotnet/parity/driver.py[273-342]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The notifications handler changes which account is served when the body names someone other than the validated account, but the parity harness does not document the difference from the reference implementation.

## Fix Focus Areas
- dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[36-39]
- dotnet/parity/driver.py[273-342]

## Recommended Fix
Add a notifications entry to the parity divergence list that names the endpoint and explains the validated-account behavior versus the reference implementation. Keep the endpoint tests covering that behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 21 rules

✅ Cross-repo context — repo relationships

  Explored: repo: ecency/vision-web (sha: 2ab507fb) — View relationship

Review mode: ⚖️ Balanced: This is a security-sensitive authorization change affecting account selection and upstream notification access, warranting a complete careful review.

Tip of the day

💡 Did you know, you can keep summaries lean with Findings visible per group, which tucks the rest behind a View link

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

2. Notification changes lack a parity record 📘 Rule violation ▣ Testability

ResolveNotificationsTarget now ignores the body's user field and serves the validated account,
but this endpoint has no corresponding entry in the parity divergence list. Requests that name
another account now produce a different upstream path than the reference implementation, while the
parity harness has no record explaining that intentional difference.

Agent Prompt

## Issue description
The notifications handler changes which account is served when the body names someone other than the validated account, but the parity harness does not document the difference from the reference implementation.

## Fix Focus Areas
- dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[36-39]
- dotnet/parity/driver.py[273-342]

## Recommended Fix
Add a notifications entry to the parity divergence list that names the endpoint and explains the validated-account behavior versus the reference implementation. Keep the endpoint tests covering that behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

1. Deck columns mislabel notifications 🔗 Cross-repo conflict ≡ Correctness

ResolveNotificationsTarget now ignores the body's user and returns the validated account with
full scope. In vision-web, a notifications deck column sends its selected account as user
alongside the signed-in account's code, then displays the returned feed under the selected account's
name.

Agent Prompt

## Issue description
Vision-web's notifications deck requests a selected account's feed using the signed-in account's code. The API now returns the signed-in account's feed instead, which the deck labels as the selected account.

## Fix Focus Areas
- dotnet/EcencyApi/Handlers/PrivateApi.UserData1.cs[28-39]
- apps/web/src/app/decks/_components/columns/deck-notifications-column.tsx[94-115]
- packages/sdk/src/modules/private-api/requests.ts[105-139]

## Recommended Fix
Keep code-validated access restricted to its own account. Coordinate a vision-web change so cross-account deck columns use an explicitly supported restricted public feed, or disable that selection; reject mismatched `user` values in the API rather than silently returning a differently named account's feed.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools