wfe: Handle empty JSON to /acme/acct like POST-as-GET #7844
Conversation
ACME clients can make an empty request to /acme/acct for their reg object. wfe.Account handles a truly empty request correctly, but has routed empty JSON objects to updateAccount, even though an update is not appropriate. This only happened to work because UpdateRegistration's impl takes an entire Registration and returns it even if unchanged. This preserves ACMEv1 backwards compatibility when UpdateRegistration is simplified.
There was a problem hiding this comment.
I'd rephrase the PR description to more fully describe this behavior. Something like:
Early drafts of the ACME spec said that clients should retrieve their existing account information by POSTing the empty JSON object
{}to their account URL. This instruction was removed in the final version of ACME, replaced by the concept of POST-as-GET which uses a wholly empty body to accomplish the same goal. However, Boulder has continued to incidentally support this behavior: when we receive an empty JSON object, our updateAccount code in the RA applies their desired diff (none) on top of their current account, writes it back to the database, and returns the updated account object... which hasn't actually changed. This behavior is also half-tested by TestEmptyAccount, but that test is actually testing that the MockRA implements the same behavior as the real RA; it's not truly testing the WFE's behavior.This PR changes the WFE to explicitly treat receiving the empty JSON object as a request to retrieve the account data unchanged, rather than implicitly relying on internal details of the RA's account-update logic.
There was a problem hiding this comment.
This is a prerequisite for #7827, right? Would be good to link that in the description for ease of understanding ("when the updateAccount flow is simplified" was only enough for me to find it because I have the context paged in right now, but pull requests are used in the future to understand why changes were made).
Otherwise looks good. Nice to break out this improvement on its own. Oh, which reminds me - do we already have a test for the "{}" case?
Co-authored-by: Jacob Hoffman-Andrews <jsha+github@letsencrypt.org>
We did, but not for the empty string |
Early drafts of the ACME spec said that clients should retrieve their existing account information by POSTing the empty JSON object
{}to their account URL. This instruction was removed in the final version of ACME, replaced by the concept of POST-as-GET, which uses a wholly empty body to accomplish the same goal. However, Boulder has continued to incidentally support this behavior: when we receive an empty JSON object, ourupdateAccountcode in the RA applies their desired diff (none) on top of their current account, writes it back to the database, and returns the updated account object...which hasn't actually changed. This behavior is also half-tested byTestEmptyAccount, but that test is actually testing that the MockRA implements the same behavior as the real RA; it's not truly testing the WFE's behavior.This PR changes the WFE to explicitly treat receiving the empty JSON object as a request to retrieve the account data unchanged, rather than implicitly relying on internal details of the RA's account-update logic, which are expected to change in #7827.