Continuing on this topic, I have incorporated the node-uuid lib into AeroGear.js. Here is
the commit on my fork for review before I merge upstream
I have also started incorporating some status tracking of the data in preparation for data
synchronization so I am hoping for feedback on that as well in terms of both the states
being monitored and how that data is handled. I haven't started any actual sync code
Any feedback is appreciated.
Also, Doug, based on our conversation with legal about licensing, please let me know if I
have our bases covered. The license file is in the repo with the lib, the license header
is in the unminified version of our lib but is removed on minification.
On Sep 13, 2012, at 9:52 AM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Agreed! Let's move forward with kborchers document and think
about the same problem guys.
Sorry, I didn't notice that.
"The measure of a man is what he does with power" - Plato
Volenti Nihil Difficile
On Thursday, September 13, 2012 at 11:10 AM, Kris Borchers wrote:
> Should these documents be merged?
> On Sep 13, 2012, at 9:08 AM, Bruno Oliveira <bruno(a)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
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
>> Volenti Nihil Difficile
>> On 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 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
>>>>> 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 - 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
>>>> +0 from me.
>>>> aerogear-dev mailing list
>>> aerogear-dev mailing list
>> aerogear-dev mailing list
> aerogear-dev mailing list
aerogear-dev mailing list