Skip to content

Mntor 5342 - #6817

Draft
GregHilstonMozilla wants to merge 21 commits into
mainfrom
mntor-5342
Draft

Mntor 5342#6817
GregHilstonMozilla wants to merge 21 commits into
mainfrom
mntor-5342

Conversation

@GregHilstonMozilla

Copy link
Copy Markdown
Collaborator

References:

Jira: MNTOR-
Figma:

Description

Screenshot (if applicable)

Not applicable.

How to test

Checklist (Definition of Done)

  • Localization strings (if needed) have been added.
  • Commits in this PR are minimal and have descriptive commit messages.
  • I've added or updated the relevant sections in readme and/or code comments
  • I've added a unit test to test for potential regressions of this bug.
  • If this PR implements a feature flag or experimentation, I've checked that it still works with the flag both on, and with the flag off.
  • If this PR implements a feature flag or experimentation, the Ship Behind Feature Flag status in Jira has been set
  • Product Owner accepted the User Story (demo of functionality completed) or waived the privilege.
  • All acceptance criteria are met.
  • Jira ticket has been updated (if needed) to match changes made during the development process.
  • Jira ticket has been updated (if needed) with suggestions for QA when this PR is deployed to stage.

Provisioning is not part of this integration, so POST /user does not
belong in the contract.
/api/v1/user/breaches is already the web app's session-authenticated
route. Presumably he front end develops against stage. info.version
disagreed with the /v1 in the path.
Remote Settings gives Firefox every breach keyed by HIBP name, so the
response only needs that name to join on. Says so at both the response
id and the request breachId, since a numeric id was the likelier read.
We keep a checked list, IE no timestamp, and no way back. A resolved
flag invites an undo we do not support.
The panel's one action is "Mark as done" on a password, and Firefox
already holds every breach's data classes from Remote Settings. Sending
a user's other exposures would be unnecessary data with no consumer, so
the server narrows this down to what is only used today. With an easy
way to extend this later, that is backwards compatible.
An empty batch is a client bug, not a convenience. Firefox's one write
is a single "Mark as done", so nothing computes an empty list. minItems
makes it a validation failure.
@GregHilstonMozilla GregHilstonMozilla self-assigned this Aug 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant