Comment 35 for bug 1617918

Revision history for this message
gordon chung (chungg) wrote :

"""The UUID translation is not user nor project scoped, it's "creator" scoped (see the recent patch branch). Which in the Keystone case is user_id:project_id.
So if you don't know user/project (but you can know it by listing the resources) you can't guess the uuid of a named resource, sure."""

iirc, the original reason we had this translation was because we had some cases where our 'resource_id' had a '/' in it which broke api. the more we expand that, it seems like the translation are very hidden unless you know about it... even now i'm not entirely sure what i'd get if i put use /v1/resource/generic/foobar. i feel like it should be simple from REST pov (if you ask for v1/resource/generic/<blah> you should get whatever resource has primary key <blah>.

""""foobar" is not an uuid so it will never try "foobar". Even if it does, the server will translate it to an uuid5(foobar, creator).

Same answer for the "scope", it's creator (which is user:project)."""

so the scope is what my original concern was. this seems to break (my) use case of i am admin user and i want to grab everything from my project.