Feature request: get/update details of existing registration

[nhinds]

At the moment, a client with an existing registration can't interact with it (e.g. to accept the ToS) if the original Registration object is no longer available. This could be useful if the ToS ever change, or to update the contact details, or list the currently authorized domains and generated certificates.

e.g.

client = Acme::Client.new(...)
orig_registration = client.register(contact: '...')
# ... some time later
client = Acme::Client.new(...)
registration = client.register(contact: '...')
# => Acme::Client::Error::Malformed: Registration key is already in use

In this scenario, the ACME server returns a 409 with the URL of the existing registration:

If the server already has a registration object with the provided account key, then it MUST return a 409 (Conflict) response and provide the URI of that registration in a Location header field. This allows a client that has an account key but not the corresponding registration URI to recover the registration URI.

At the moment there's no way to get the Location header out of the Acme::Client::Error::Malformed error, and if we had it there's no way to get a Registration object out of it -- ACME requires a signed POST to this URL to retrieve the details:

If a client wishes to query the server for information about its account (e.g., to examine the “contact” or “certificates” fields), then it SHOULD do so by sending a POST request with an empty update. That is, it should send a JWS whose payload is trivial ({“resource”:”reg”}). In this case the server reply MUST contain the same link headers sent for a new registration, to allow a client to retreive the “new-authorization” and “terms-of-service” URI

What are your thoughts on handling this? I could see this going a couple of ways - a method on the exception to go request the existing registration details; automatically handling the 409 and passing on the given contact details as an "update" to the existing account; or maybe a new method on the client to retrieve the existing registration which assumes it already exists.

If one of those were implemented, it's probably also worth adding another couple of methods on the Registration object to get the current authorizations, certificates, and contact information, and perhaps to update the contact information. (For new registrations the authorizations and certificates are going to be empty anyway, and the contact is the one that was just passed in, so I can see why they're not exposed at the moment)

[unixcharles]

What are your thoughts on handling this? I could see this going a couple of ways - a method on the exception to go request the existing registration details; automatically handling the 409 and passing on the given contact details as an "update" to the existing account; or maybe a new method on the client to retrieve the existing registration which assumes it already exists.

We should be possible to retrieve the registration object from the exception that is clear. It should be relatively straight forward to add an exception for this.

I think it should also be able to retrieve the registration object without raising. I'm not sure of the use case but that seem like the logical thing to do.

In any case, it doesn't seem right to me that the only way to fetch the registration is by triggering an error. I'll open an issue in acme to see what they think about this.

[nhinds]

This is now possible in the recently-released version 2.0 via either client.new_account (which automatically updates & returns existing accounts) or client.account (which requires the account to already exist)