Allow clients to specificy their own UUIDs, and not use the auto generated o...

[Jesus M. Rodriguez]

Bryan,

why are we allowing clients to specify their own UUIDs?
Seems like there could be collisions. Also, it seems odd
that the copy ctor doesn't actually make an exact copy.

jesus

Sent to you by jmrodri via Google Reader: Allow clients to specificy
their own UUIDs, and not use the auto generated ones. via Fedora Hosted
Git Repositories - candlepin.git/rss log by Bryan Kearney
 on 3/18/10

Allow clients to specificy their own UUIDs, and not use the auto
generated ones.

- [DH]
proxy/src/main/java/org/fedoraproject/candlepin/model/Consumer.java
- [DH]
proxy/src/test/java/org/fedoraproject/candlepin/model/test/ConsumerTest.java
- [DH]
proxy/src/test/java/org/fedoraproject/candlepin/resource/test/ConsumerResourceTest.java
Things you can do from here:
- Subscribe to Fedora Hosted Git Repositories - candlepin.git/rss log
using Google Reader
- Get started using Google Reader to easily keep up with all your
favorite sites

[Bryan Kearney]

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

On 03/18/2010 01:49 PM, jmrodri wrote:
> Bryan,
>
> why are we allowing clients to specify their own UUIDs?
> Seems like there could be collisions. Also, it seems odd
> that the copy ctor doesn't actually make an exact copy.
>
> jesus
>   Sent to you by jmrodri via Google Reader:
>
>
> Allow clients to specificy their own UUIDs, and not use the auto
> generated ones.
> <http://git.fedoraproject.org/git/?p=candlepin.git;a=commitdiff;h=8ccf4d991c090bf237f6fa39f5f130f732cb9195>
>
> via Fedora Hosted Git Repositories - candlepin.git/rss log
> http://git.fedoraproject.org/git/?p=candlepin.git;a=summary by Bryan
> Kearney  on 3/18/10
>
> Allow clients to specificy their own UUIDs, and not use the auto generated ones.
> * [D
>   <http://git.fedoraproject.org/git/?p=candlepin.git;a=blobdiff;f=proxy/src/main/java/org/fedoraproject/candlepin/model/Consumer.java;fp=proxy/src/main/java/org/fedoraproject/candlepin/model/Consumer.java;h=b3ba26e1c966bc6b4c374052940a78be626f3fa0;hp=066f21bc9334960dfcc469ef956ba2d68f066f3e;hb=8ccf4d991c090bf237f6fa39f5f130f732cb9195;hpb=bf053d58ddf143779f1313eca593b83ca4dd6324>H
>   <http://git.fedoraproject.org/git/?p=candlepin.git;a=history;f=proxy/src/main/java/org/fedoraproject/candlepin/model/Consumer.java;h=8ccf4d991c090bf237f6fa39f5f130f732cb9195>]
>   proxy/src/main/java/org/fedoraproject/candlepin/model/Consumer.java
> * [D
>   <http://git.fedoraproject.org/git/?p=candlepin.git;a=blobdiff;f=proxy/src/test/java/org/fedoraproject/candlepin/model/test/ConsumerTest.java;fp=proxy/src/test/java/org/fedoraproject/candlepin/model/test/ConsumerTest.java;h=9e8f6499a58cae1ed703724251dbe14cd7e2aa28;hp=19c5f7c5db45287df222d890dfad470196cee406;hb=8ccf4d991c090bf237f6fa39f5f130f732cb9195;hpb=bf053d58ddf143779f1313eca593b83ca4dd6324>H
>   <http://git.fedoraproject.org/git/?p=candlepin.git;a=history;f=proxy/src/test/java/org/fedoraproject/candlepin/model/test/ConsumerTest.java;h=8ccf4d991c090bf237f6fa39f5f130f732cb9195>]
>   proxy/src/test/java/org/fedoraproject/candlepin/model/test/ConsumerTest.java
> * [D
>   <http://git.fedoraproject.org/git/?p=candlepin.git;a=blobdiff;f=proxy/src/test/java/org/fedoraproject/candlepin/resource/test/ConsumerResourceTest.java;fp=proxy/src/test/java/org/fedoraproject/candlepin/resource/test/ConsumerResourceTest.java;h=0f20954dc33395e15f9f74a7cef7dd1ee7b3f073;hp=074ca6069db70682fd54f10b081719e4771bbbd2;hb=8ccf4d991c090bf237f6fa39f5f130f732cb9195;hpb=bf053d58ddf143779f1313eca593b83ca4dd6324>H
>   <http://git.fedoraproject.org/git/?p=candlepin.git;a=history;f=proxy/src/test/java/org/fedoraproject/candlepin/resource/test/ConsumerResourceTest.java;h=8ccf4d991c090bf237f6fa39f5f130f732cb9195>]
>   proxy/src/test/java/org/fedoraproject/candlepin/resource/test/ConsumerResourceTest.java
>
>
>   Things you can do from here:
>
> * Subscribe to Fedora Hosted Git Repositories - candlepin.git/rss
>   log
>   <http://www.google.com/reader/view/feed%2Fhttp%3A%2F%2Fgit.fedoraproject.org%2Fgit%2F%3Fp%3Dcandlepin.git%3Ba%3Drss?source=email>
>   using *Google Reader*
> * Get started using Google Reader
>   <http://www.google.com/reader/?source=email> to easily keep up
>   with *all your favorite sites*
>
>
>
> candlepin mailing list
> [e-mail]
> https://fedorahosted.org/mailman/listinfo/candlepin

[Devan Goodwin]

On Thu, Mar 18, 2010 at 3:19 PM, Bryan Kearney  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

[Bryan Kearney]

On 03/22/2010 11:50 AM, Devan Goodwin wrote:
> On Thu, Mar 18, 2010 at 3:19 PM, Bryan Kearney  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.

Given security.. yes. And, to be clear.. this is UUID, not DB ID. But, 
it is in the URL.

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.

So.. our ID is the ID or the consumer. The UUID is the mapping, or we 
can generate one for them.

-- bk