On Thu, Mar 18, 2010 at 3:19 PM, Bryan Kearney bkearney@redhat.com wrote:
Cool.. I did not think of exposing that to reader... cool.
Here is the use case. Assume I have a tool which aready assigns system ids. The use case would be that I create a system in that tool, and that tool calls candlepin saying "create me a consumer for system id 22".
It is up to them to make it unique in that case. The ID (the PK of the table) is still owned by Candlepin. However, the UUID "could" be owned by candlepin.
-- bk
I've been wondering if there's some potential for abuse here, right now this ability for a consumer to specify their own database ID (which is a string, and gets used in various URLs) looks like it's exposed to any consumer registration, one could trivially modify any client tooling and make use of it. As far as specific abuse the only two things I can think of are seeking out pre-existing IDs by hunting for a collision, or stuffing characters into it that will break Candlepin URLs. Neither of which is particularly devastating and I'm not even sure how far you could get with them, but if nothing else it's a possible starting point for someone looking to cause trouble.
Ultimately though I was wondering if we actually need to have a consistent identifier across all applications that integrate with Candlepin, or if we could requirement to maintain a mapping between their ID and our UUID? If so that's fine, we probably just need some validation on incoming UUID strings, but I thought I'd pose the question just in case.
Cheers,
Devan