On 18/11/13 12:15, Mitsuru Kanabuchi wrote:
On Fri, 15 Nov 2013 12:46:44 +0100
Zane Bitter <zbit...@redhat.com> wrote:
Yes, but you don't know the UUID until you know it, and by then it's too
late (the resource has been created). So the idempotency token has to be
something passed in by the user.
I completely agree with you that token has to be something passed in by
the user.
You could allow the user to supply the UUID (you would obviously check
it for uniqueness). There is however, many possible ways in which that
could go horribly wrong (e.g. if you sharded based on UUID, an attacker
might be able to exploit that to overload one of your machines; the
uniqueness check leaks information from other tenants, &c.)
Umm...
Thank you for important comments.
I understood your comment imply that idempotency token has to generate by
trusted services. (e.g. keystone?)
The question from Chris implied that we could use the user-supplied
idempotency token as the ID of the resource. I don't believe there is a
safe way to do this.
One of other hand, I'm thinking for easily way to implement idempotency token.
In my idea, idempotency token has to:
- be String (Don't use UUID)
# for avoiding UUID generate problem
It can be a UUID (or anything), but you can't use it as the ID of the
resource.
- isolate per tenant
# for avoiding uniqueness check leaks
+1
is appropriate. What do you think about that?
Yes, the implementation proposed in your blueprint[1] looks fine to me.
cheers,
Zane.
[1] https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
