2 ms·

Thanks for the insightful comment; makes good sense. Could you kindly share your view on the security implications of this approach - in particular with refere

Thanks for the insightful comment; makes good sense. Could you kindly share your view on the security implications of this approach - in particular with reference to the security context outlined in section 5 of the IETF draft: > For idempotent request handling, the resources MAY make use of the value in the idempotency key to look up a cache or a persistent store for duplicate requests matching the key. If the resource does not validate the value of the idempotency key prior to performing such a lookup, it MAY lead to various forms of security attacks and compromise.

nivertech 5y ago
Yes, that's the case if you use it for unauthenticated users or public API calls. For that reason I do not support idempotent retries for public API calls. For the authenitcated users, you cache/store the idempotency keys scoped by the currently authenticated user, i.e: {user_id, idempotency_key} You can add more parts to thie key for better security, i.e.: {user_id, api_call_name, idempotency_key} or even {user_id, api_call_name, input_args_hash, idempotency_key} etc.