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.

Sign up for GitHub

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

Jump to bottom

Include account ID in authz/challenge URLs #7683

Open
aarongable opened this issue Aug 27, 2024 · 0 comments
Open

Include account ID in authz/challenge URLs #7683

aarongable opened this issue Aug 27, 2024 · 0 comments
Assignees
@jsha
Milestone
2024-11-12

Comments

@aarongable
Copy link
Contributor

We plan to horizontally shard our database in the new future, directing data into shards based on shard keys. It's very likely that our shard key will include the registration ID of the account owning the order, authz, or challenge. However, our public-facing API URLs for authzs and challenges do not currently include the owning regID, so if we get a query for one of those objects, we won't know which shard to look it up in.

We should augment the URLs that we provide in our API responses to embed the account's regID in the paths for authz and challenge objects.

Proposed RESTful URL scheme:

  • /accts/{RegID}
  • /accts/{RegID}/orders/{OrderID}
  • /accts/{RegID}/authzs/{AuthzID}
  • /accts/{RegID}/authzs/{AuthzID}/challs/{ChallStringID}

Alternate scheme (pro: less disruptive; cons: less obvious)

  • /acme/acct/{RegID} (no change)
  • /acme/order/{RegID}/{OrderID} (no change)
  • /acme/authz/{RegID}/{AuthzID}
  • /acme/chall/{RegID}/{AuthzID}/{ChallStringID}
@aarongable aarongable added this to the Sprint 2024-09-03 milestone Sep 3, 2024
@jsha jsha mentioned this issue Oct 24, 2024
Merged
@jsha jsha removed their assignment Oct 25, 2024
aarongable pushed a commit that referenced this issue Nov 6, 2024
@jsha
Allow account IDs in authz and challenge URLs (#7768)
2058d98 
This adds new handlers under `/acme/authz/` and `/acme/chall/` that
expect to be followed by `{regID}/{authzID}` and
`{regID}/{authzID}/{challengeID}`, respectively. For deployability, the
old handlers continue to work, and the URLs returned for newly created
objects will still point to the paths used by the old handlers
(`/acme/authz-v3/` and `/acme/chall-v3/`).

There are some self-referential URLs in authz and challenge responses,
like the Location header, and the URL of challenges embedded in an
authorization object. This PR updates `prepAuthorizationForDisplay` and
`prepChallengeForDisplay` so those URLs can be generated consistently
with the path that was requested.

For the WFE tests, in most cases I duplicated an entire test and then
updated it to test the `WithAccount` handler. The idea is that once
we're fully switched over to the new format we can delete the tests for
the non-`WithAccount` variants.

Part of #7683
@jsha jsha mentioned this issue Nov 7, 2024
Merged
@jsha jsha modified the milestones: Sprint 2024-11-05, 2024-11-12 Nov 12, 2024
aarongable pushed a commit that referenced this issue Nov 15, 2024
@jsha
wfe: orders link to authz IDs with acccount (#7790)
56f0ed6 
This means that most traffic will go to the authz URLs with account.
After this has been deployed for 30 days (the max lifetime of an order),
we can remove support for the old paths.

Part of #7683
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jsha jsha

Labels
None yet
Projects
None yet
Milestone
2024-11-12
Development

No branches or pull requests
3 participants
@jsha @aarongable @beautifulentropy