On Thursday, September 13, 2012 at 11:10 AM, Kris Borchers wrote:
Should these documents be merged? https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1.0.0/AeroGearPersistence.asciidocOn Sep 13, 2012, at 9:08 AM, Bruno Oliveira <bruno@abstractj.org> wrote:Hi my friends, we have a great discussion here and we can't miss it, for this reason I've created this document https://github.com/aerogear/beta.aerogear.org/blob/master/docs/reference/PersistenceApi.asciidoc feel free to tweak, change, delete sections as needed.I'd like to have UUID generation details there, in this way we don't lose it. Probably the server will handle this UUID generation, but assuming that it will affect all platforms would be nice to start a minimum description.--"The measure of a man is what he does with power" - Plato-@abstractj-Volenti Nihil DifficileOn Wednesday, September 12, 2012 at 10:39 AM, Marko Strukelj wrote:
Hey Kris,On 9/11/12 4:20 PM, Kris Borchers wrote:I have been thinking about this a bit lately and am also hoping togetpeople's thoughts on whether or not this may be overkill. Thereason Isay that is that really the only reason you would need such aunique idis if there will be a chance of something else (another client,server,etc.) generating an id for a piece of data that would conflict withthisone. What I was thinking though is that is only an issue at synctime.As long as you know the id is unique in the client, and the statusofthat piece of data (new, modified, removed), then at sync time, youcanrectify those id's that are out of sync with what is generated attheserver and you have one point of id generation.I've always been a fan of server-side ID generation, just because Ialways tend to think about malicious or badly-written clients. It'spossible for someone to pollute the ID pool such that a real ID thatalater client generates for a new object is rejected as a duplicate -andso we'd need to account for that possibility and have the UUIDregenerated in that case. Edge case, to be sure, but those are oftenwhere 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 - be rejected.I can imagine such a denial of service attack possible if there is an issue with UUID generator used.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'edUUIDs.+0 from me.--Glen_______________________________________________aerogear-dev mailing list_______________________________________________aerogear-dev mailing list_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev_______________________________________________aerogear-dev mailing list