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

ACMEv2: "orders" field missing in account info #3335

Open
joernheissler opened this Issue Jan 7, 2018 · 6 comments

Comments

4 participants
@joernheissler

joernheissler commented Jan 7, 2018

When I POST an empty update to my account URL I get this:

{
    "id": 5337306,
    "key": {
        "kty": "RSA",
        "n": "<redacted>",
        "e": "AQAB"
    },
    "contact": [
        "mailto:<redacted>"
    ],
    "agreement": "https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf",
    "initialIp": "<redacted>",
    "createdAt": "2018-01-05T01:29:21Z",
    "status": "valid"
}

There is no orders field as required by https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.1.2

@cpu

This comment has been minimized.

Show comment
Hide comment
@cpu

cpu Jan 8, 2018

Member

We should implement this field - @jsha @rolandshoemaker I remember the question of pagination/truncation of the "orders" field came up before w.r.t this spec feature. What are your thoughts about that here? Should we expect to return all orders? all unexpired orders? The first n unexpired orders?
I was remembering a point in the spec where the orders field was itself an array of URLs instead of a URL from which one can retrieve URLs.

Member

cpu commented Jan 8, 2018

We should implement this field - @jsha @rolandshoemaker I remember the question of pagination/truncation of the "orders" field came up before w.r.t this spec feature. What are your thoughts about that here? Should we expect to return all orders? all unexpired orders? The first n unexpired orders?
I was remembering a point in the spec where the orders field was itself an array of URLs instead of a URL from which one can retrieve URLs.

@buschtoens

This comment has been minimized.

Show comment
Hide comment
@buschtoens

buschtoens Jan 29, 2018

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2

orders (required, string): A URL from which a list of orders
submitted by this account can be fetched via a GET request, as
described in Section 7.1.2.1.

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2.1

Each account object includes an "orders" URL from which a list of
orders created by the account can be fetched via GET request. The
result of the GET request MUST be a JSON object whose "orders" field
is an array of URLs, each identifying an order belonging to the
account. The server SHOULD include pending orders, and SHOULD NOT
include orders that are invalid in the array of URLs. The server MAY
return an incomplete list, along with a Link header with a "next"
link relation indicating where further entries can be acquired.

  HTTP/1.1 200 OK
  Content-Type: application/json
  Link: <https://example.com/acme/acct/1/orders?cursor=2>, rel="next"

  {
    "orders": [
      "https://example.com/acme/acct/1/order/1",
      "https://example.com/acme/acct/1/order/2",
      /* 47 more URLs not shown for example brevity */
      "https://example.com/acme/acct/1/order/50"
    ]
  }

buschtoens commented Jan 29, 2018

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2

orders (required, string): A URL from which a list of orders
submitted by this account can be fetched via a GET request, as
described in Section 7.1.2.1.

https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-7.1.2.1

Each account object includes an "orders" URL from which a list of
orders created by the account can be fetched via GET request. The
result of the GET request MUST be a JSON object whose "orders" field
is an array of URLs, each identifying an order belonging to the
account. The server SHOULD include pending orders, and SHOULD NOT
include orders that are invalid in the array of URLs. The server MAY
return an incomplete list, along with a Link header with a "next"
link relation indicating where further entries can be acquired.

  HTTP/1.1 200 OK
  Content-Type: application/json
  Link: <https://example.com/acme/acct/1/orders?cursor=2>, rel="next"

  {
    "orders": [
      "https://example.com/acme/acct/1/order/1",
      "https://example.com/acme/acct/1/order/2",
      /* 47 more URLs not shown for example brevity */
      "https://example.com/acme/acct/1/order/50"
    ]
  }
@buschtoens

This comment has been minimized.

Show comment
Hide comment
@buschtoens

buschtoens Feb 28, 2018

Considering that ACME v2 was scheduled to go live yesterday, is there currently a way to retrieve a list of pending orders?

I'm sure you're busy with getting boulder ready, in order to ship ACME v2 for Let's Encrypt, so please don't feel pressured. I just happened to trip over this again.

buschtoens commented Feb 28, 2018

Considering that ACME v2 was scheduled to go live yesterday, is there currently a way to retrieve a list of pending orders?

I'm sure you're busy with getting boulder ready, in order to ship ACME v2 for Let's Encrypt, so please don't feel pressured. I just happened to trip over this again.

@cpu

This comment has been minimized.

Show comment
Hide comment
@cpu

cpu Feb 28, 2018

Member

@buschtoens We still have not implemented the "orders" field on account objects and we're not considering this a required feature for the V2 launch. I expect it will be a little bit after the launch before we implement it. I recommend that your client maintain the IDs of orders it creates with the newOrder endpoint in the meantime.

The best way to watch for progress is to keep an eye on this issue, particularly when it gets assigned to a milestone for a sprint. Thanks for your patience!

Member

cpu commented Feb 28, 2018

@buschtoens We still have not implemented the "orders" field on account objects and we're not considering this a required feature for the V2 launch. I expect it will be a little bit after the launch before we implement it. I recommend that your client maintain the IDs of orders it creates with the newOrder endpoint in the meantime.

The best way to watch for progress is to keep an eye on this issue, particularly when it gets assigned to a milestone for a sprint. Thanks for your patience!

@cpu cpu added this to Backlog in v2 API Mar 2, 2018

@bkromhout

This comment has been minimized.

Show comment
Hide comment
@bkromhout

bkromhout Aug 13, 2018

@cpu, can we expect to see any movement on this anytime soon? The ACME spec draft appears to be quite close to its final form, pending the whole process of making it an actual RFC. While I agree the "orders" field is a convenience, it is still a required part of the spec, yet this has been sitting idle for months now.

bkromhout commented Aug 13, 2018

@cpu, can we expect to see any movement on this anytime soon? The ACME spec draft appears to be quite close to its final form, pending the whole process of making it an actual RFC. While I agree the "orders" field is a convenience, it is still a required part of the spec, yet this has been sitting idle for months now.

@cpu

This comment has been minimized.

Show comment
Hide comment
@cpu

cpu Aug 20, 2018

Member

@cpu, can we expect to see any movement on this anytime soon?

Unlikely. It's a non-trivial amount of work for a convenience and there is still substantial higher priority work to be done in other areas.

this has been sitting idle for months now.

@bkromhout PRs are welcome.

Member

cpu commented Aug 20, 2018

@cpu, can we expect to see any movement on this anytime soon?

Unlikely. It's a non-trivial amount of work for a convenience and there is still substantial higher priority work to be done in other areas.

this has been sitting idle for months now.

@bkromhout PRs are welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment