Implement proper support for the me() endpoints

[mvantellingen]

The me() endpoints should return values based on the scope (anonymous_id: xx, customer_id: xx)

[korsvanloon]

A concrete instance of this, in 4.3.1, in case it is useful for scoping.

GET /{projectKey}/in-store/key={storeKey}/me/orders/{id} returns any order, including one belonging to a different customer. MyOrderService registers instance.get("/orders/:id", this.getWithId.bind(this)) and inherits getWithId from AbstractService, which resolves the id straight out of the repository:

async getWithId(request, reply) {
  const params = request.params
  const result = await this._expandWithId(request, params.id)
  if (!result) throw new CommercetoolsError({ code: "ResourceNotFound", … }, 404)
  return reply.status(200).send(result)
}

No customer or anonymous-id predicate is applied anywhere on the path.

The effect on consumers is not a false failure but a false pass: a test asserting that a shopper cannot read or act on somebody else's order succeeds against the mock whether or not the code under test actually scopes its request. We hit this writing a payment mutation — the ownership check is real against commercetools and unassertable against the mock, so the test had to be dropped rather than left as reassurance it could not provide.

The list endpoints have the same shape: GET /me/orders returns every order rather than the caller's.

If it helps prioritise, the id-lookup case seems the more damaging of the two, precisely because a wrong result there looks like a passing authorisation test.

[korsvanloon]

Triage note: this is implementable, but it needs one decision that shouldn't be made in a PR without the maintainers, so labelling help wanted.

What is already there. The OAuth store puts the identity in the token scope: getCustomerToken emits customer_id:<id> and getAnonymousToken emits anonymous_id:<id>, and the middleware already resolves a bearer token back to its entry. So plumbing the customer/anonymous id into RepositoryContext next to projectKey/storeKey is straightforward, and MyOrderService/MyCartService/… can filter on it.

The decision. enableAuthentication and validateCredentials both default to false, and most consumers inject requests with no Authorization header at all. So what should /me/orders do when there is no customer-scoped token?

• Scope only when a token carries an identity, and stay unscoped otherwise — backwards compatible, but the false pass @korsvanloon describes above survives for everyone who doesn't enable auth, which is the majority.
• Fail closed whenever the identity is missing (empty list, 404 on id lookup) — makes the ownership assertion real, but breaks existing tests that read /me without a token.
• Make it opt-in with a CommercetoolsMock option, so the behaviour changes only when asked for.

The third seems most likely to be wanted, but it is an API decision for this package.

Worth doing first, independently of that: the id-lookup case @korsvanloon notes. MyOrderService inherits getWithId from AbstractService, which resolves straight out of the repository with no customer predicate — so /me/orders/{id} and /in-store/key={key}/me/orders/{id} return any order, including someone else's. Whichever of the three options is chosen, that path needs its own predicate rather than the inherited one.