On 9/11/12 4:20 PM, Kris Borchers wrote:
> I have been thinking about this a bit lately and am also hoping to
> people's thoughts on whether or not this may be overkill. The
> reason I
> say that is that really the only reason you would need such a
> unique id
> is if there will be a chance of something else (another client,
> etc.) generating an id for a piece of data that would conflict with
> one. What I was thinking though is that is only an issue at sync
> As long as you know the id is unique in the client, and the status
> that piece of data (new, modified, removed), then at sync time, you
> rectify those id's that are out of sync with what is generated at
> server and you have one point of id generation.
I've always been a fan of server-side ID generation, just because I
always tend to think about malicious or badly-written clients. It's
possible for someone to pollute the ID pool such that a real ID that
later client generates for a new object is rejected as a duplicate -
so we'd need to account for that possibility and have the UUID
regenerated in that case. Edge case, to be sure, but those are often
where the problems lie.
ID generation only happens upon create operation. And it's a UNIQUE constraint on
relational DB that can be used, or a simple EXISTS check to see if an entity with the ID
exists already. And if it does, that's an error that cancels the operation. So, if you
can guess a UUID about to be produced by someone else, and use it before they do (sync
your entity to the server, before they do theirs) you can cause theirs to fail to sync -
I can imagine such a denial of service attack possible if there is an issue with UUID
I can also imagine a duplicate UUIDs generated if there is an issue with UUID generator or
the way it is used.
Adding a autorecovery that would automatically regenerate UUIDs on the client and perform
updates would add to reliability, but adds bloat.
It's an interesting issue for sure.
That said, as long as we're careful I'm fine with client-gen'ed
+0 from me.
aerogear-dev mailing list