Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify RA and SA Registration-modifying codepaths #5554

Open
aarongable opened this issue Jul 29, 2021 · 0 comments · May be fixed by #7911
Open

Simplify RA and SA Registration-modifying codepaths #5554

aarongable opened this issue Jul 29, 2021 · 0 comments · May be fixed by #7911
Assignees

Comments

@aarongable
Copy link
Contributor

Idea: Let's get rid of the UpdateRegistration RPCs entirely.

According to RFC8555, there are only 3 ways that a client can initiate a change to their Account object:

  • POSTing to the Account endpoint with status: Deactivated (this deactivates the account)
  • POSTing to the Account endpoint with different Contacts (this updates the contacts)
  • POSTing to the separate KeyChange endpoint (this updates the Key)

The first and second of these use the same client-facing endpoint.
But in our codebase, the second and third of these use the same RA and SA codepath (UpdateRegistration).

We should instead have three wholly separate codepaths, so that we don't have to deal with generic functions like mergeUpdate which make it likely that we accidentally allow clients to modify accounts in ways they shouldn't be able to.

@jprenken jprenken self-assigned this Oct 1, 2024
@aarongable aarongable added this to the Sprint 2024-10-01 milestone Oct 1, 2024
jprenken added a commit that referenced this issue Oct 2, 2024
…methods in RA & SA

Clear contact field in DeactivateRegistration

Part of #7716
Part of #5554
jprenken added a commit that referenced this issue Nov 6, 2024
…methods in RA & SA (#7735)

Introduce separate UpdateRegistrationContact & UpdateRegistrationKey
methods in RA & SA

Clear contact field during DeactivateRegistration

Part of #7716
Part of #5554
@jsha jsha modified the milestones: Sprint 2024-11-05, 2024-11-12 Nov 12, 2024
aarongable added a commit that referenced this issue Dec 18, 2024
The RA's DeactivateAccount method expects the account provided to it by
the WFE to still have status Valid. The new WFE deactivation code was
hardcoding the status to Deactivated. Fix the WFE to pass the account's
current status instead.

Add an integration test to confirm both the breakage and the fix. Also
leave behind some TODOs to simplify this codepath further, and not
require the status to be provided at all.

Part of #5554
@jprenken jprenken linked a pull request Jan 4, 2025 that will close this issue
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 a pull request may close this issue.

4 participants