[aerogear-dev] UUID Generation

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] UUID Generation

Kris Borchers
Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs. That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.

I have been thinking about this a bit lately and am also hoping to get 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, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.

Would really appreciate others' thoughts on this.

Kris

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Bruno Oliveira
+10000


And iOS seems to have the same implementation, I just need to check if it make use of the variant 4


Probably our iOS and Android hackers can talk more about it.


-- 
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile

On Tuesday, September 11, 2012 at 5:20 PM, Kris Borchers wrote:

Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs. That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.

I have been thinking about this a bit lately and am also hoping to get 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, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.

Would really appreciate others' thoughts on this.

Kris
_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

qmx
Administrator
In reply to this post by Kris Borchers

On Sep 11, 2012, at 5:20 PM, Kris Borchers wrote:

> Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs.
+9001

> That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.
>
> I have been thinking about this a bit lately and am also hoping to get people's thoughts on whether or not this may be overkill.
It's not overkill at all, it's standard practice when you don't have 100% server uptime (which is easily to see over a 3G connection)

> 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, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.
Using UUID's will save us a lot of headaches on the long run - even having sync statuses for our data

>
> Would really appreciate others' thoughts on this.
>
> Kris
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- qmx


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Kris Borchers

On Sep 11, 2012, at 3:33 PM, Douglas Campos <[hidden email]> wrote:

>
> On Sep 11, 2012, at 5:20 PM, Kris Borchers wrote:
>
>> Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs.
> +9001
>
>> That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.
>>
>> I have been thinking about this a bit lately and am also hoping to get people's thoughts on whether or not this may be overkill.
> It's not overkill at all, it's standard practice when you don't have 100% server uptime (which is easily to see over a 3G connection)
>
>> 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, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.
> Using UUID's will save us a lot of headaches on the long run - even having sync statuses for our data

I guess I am just not sure what a UUID gets us that epoch time doesn't. If I assign an id based on epoch time in milliseconds, that will be unique client side. Then when I sync, I can change that id to what ever the server is using, which may not be a UUID, it could just be in integer in which case trying to assign an id server side based on a UUID generated client side would fail. Maybe I'm missing some point though.

>
>>
>> Would really appreciate others' thoughts on this.
>>
>> Kris
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> -- qmx
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

qmx
Administrator

On Sep 11, 2012, at 5:39 PM, Kris Borchers wrote:

>
> On Sep 11, 2012, at 3:33 PM, Douglas Campos <[hidden email]> wrote:
>
>>
>> On Sep 11, 2012, at 5:20 PM, Kris Borchers wrote:
>>
>>> Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs.
>> +9001
>>
>>> That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.
>>>
>>> I have been thinking about this a bit lately and am also hoping to get people's thoughts on whether or not this may be overkill.
>> It's not overkill at all, it's standard practice when you don't have 100% server uptime (which is easily to see over a 3G connection)
>>
>>> 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, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.
>> Using UUID's will save us a lot of headaches on the long run - even having sync statuses for our data
>
> I guess I am just not sure what a UUID gets us that epoch time doesn't. If I assign an id based on epoch time in milliseconds, that will be unique client side. Then when I sync, I can change that id to what ever the server is using, which may not be a UUID, it could just be in integer in which case trying to assign an id server side based on a UUID generated client side would fail. Maybe I'm missing some point though.
Tons of advantages of using UUIDs as ids - except that we should provision compatibility for server-generated ids too


>>
>>>
>>> Would really appreciate others' thoughts on this.
>>>
>>> Kris
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> -- qmx
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- qmx


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Daniel Passos-2
Hi All!

I don't know if UUID is the "best" solution or it will solve all problems. However working with states is complicated. Mainly when we have conflicts.

About this on Android, it's so easy :)

2012/9/11 Douglas Campos <[hidden email]>

On Sep 11, 2012, at 5:39 PM, Kris Borchers wrote:

>
> On Sep 11, 2012, at 3:33 PM, Douglas Campos <[hidden email]> wrote:
>
>>
>> On Sep 11, 2012, at 5:20 PM, Kris Borchers wrote:
>>
>>> Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs.
>> +9001
>>
>>> That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.
>>>
>>> I have been thinking about this a bit lately and am also hoping to get people's thoughts on whether or not this may be overkill.
>> It's not overkill at all, it's standard practice when you don't have 100% server uptime (which is easily to see over a 3G connection)
>>
>>> 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, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.
>> Using UUID's will save us a lot of headaches on the long run - even having sync statuses for our data
>
> I guess I am just not sure what a UUID gets us that epoch time doesn't. If I assign an id based on epoch time in milliseconds, that will be unique client side. Then when I sync, I can change that id to what ever the server is using, which may not be a UUID, it could just be in integer in which case trying to assign an id server side based on a UUID generated client side would fail. Maybe I'm missing some point though.
Tons of advantages of using UUIDs as ids - except that we should provision compatibility for server-generated ids too


>>
>>>
>>> Would really appreciate others' thoughts on this.
>>>
>>> Kris
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> -- qmx
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- qmx


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Kris Borchers
Just a quick followup, this looks like the most up to date version of that UUID project https://github.com/broofa/node-uuid.

On Sep 11, 2012, at 4:58 PM, Daniel Passos <[hidden email]> wrote:

Hi All!

I don't know if UUID is the "best" solution or it will solve all problems. However working with states is complicated. Mainly when we have conflicts.

About this on Android, it's so easy :)

2012/9/11 Douglas Campos <[hidden email]>

On Sep 11, 2012, at 5:39 PM, Kris Borchers wrote:

>
> On Sep 11, 2012, at 3:33 PM, Douglas Campos <[hidden email]> wrote:
>
>>
>> On Sep 11, 2012, at 5:20 PM, Kris Borchers wrote:
>>
>>> Hey everyone, I just wanted to let you know I have been doing a little research around generating id's on the client side. I have found a little JS utility lib that I am thinking about using that generates RFC4122 compliant UUIDs.
>> +9001
>>
>>> That library is here http://www.broofa.com/Tools/Math.uuid.js if you are interested. Bruno thought it would be a good idea that I send this out for everyone as it may be a good idea to see what is available in the Android and iOS world in terms of generating similar id's.
>>>
>>> I have been thinking about this a bit lately and am also hoping to get people's thoughts on whether or not this may be overkill.
>> It's not overkill at all, it's standard practice when you don't have 100% server uptime (which is easily to see over a 3G connection)
>>
>>> 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, server, etc.) generating an id for a piece of data that would conflict with this one. What I was thinking though is that is only an issue at sync time. As long as you know the id is unique in the client, and the status of that piece of data (new, modified, removed), then at sync time, you can rectify those id's that are out of sync with what is generated at the server and you have one point of id generation.
>> Using UUID's will save us a lot of headaches on the long run - even having sync statuses for our data
>
> I guess I am just not sure what a UUID gets us that epoch time doesn't. If I assign an id based on epoch time in milliseconds, that will be unique client side. Then when I sync, I can change that id to what ever the server is using, which may not be a UUID, it could just be in integer in which case trying to assign an id server side based on a UUID generated client side would fail. Maybe I'm missing some point though.
Tons of advantages of using UUIDs as ids - except that we should provision compatibility for server-generated ids too


>>
>>>
>>> Would really appreciate others' thoughts on this.
>>>
>>> Kris
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> -- qmx
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- qmx


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Glen Daniels
In reply to this post by Kris Borchers
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 get
> 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, server,
> etc.) generating an id for a piece of data that would conflict with this
> one. What I was thinking though is that is only an issue at sync time.
> As long as you know the id is unique in the client, and the status of
> that piece of data (new, modified, removed), then at sync time, you can
> rectify those id's that are out of sync with what is generated at the
> 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 a
later client generates for a new object is rejected as a duplicate - and
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.

That said, as long as we're careful I'm fine with client-gen'ed UUIDs.

+0 from me.

--Glen


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Marko Strukelj

> 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
> > get
> > 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,
> > server,
> > etc.) generating an id for a piece of data that would conflict with
> > this
> > one. What I was thinking though is that is only an issue at sync
> > time.
> > As long as you know the id is unique in the client, and the status
> > of
> > that piece of data (new, modified, removed), then at sync time, you
> > can
> > rectify those id's that are out of sync with what is generated at
> > the
> > 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
> a
> later client generates for a new object is rejected as a duplicate -
> and
> 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 client-gen'ed
> UUIDs.
>
> +0 from me.
>
> --Glen
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Bruno Oliveira
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 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
get
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,
server,
etc.) generating an id for a piece of data that would conflict with
this
one. What I was thinking though is that is only an issue at sync
time.
As long as you know the id is unique in the client, and the status
of
that piece of data (new, modified, removed), then at sync time, you
can
rectify those id's that are out of sync with what is generated at
the
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
a
later client generates for a new object is rejected as a duplicate -
and
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 client-gen'ed
UUIDs.

+0 from me.

--Glen


_______________________________________________
aerogear-dev mailing list
_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Kris Borchers
Should these documents be merged? https://github.com/aerogear/beta.aerogear.org/blob/master/docs/planning/1.0.0/AeroGearPersistence.asciidoc

On Sep 13, 2012, at 9:08 AM, Bruno Oliveira <[hidden email]> 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 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
get
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,
server,
etc.) generating an id for a piece of data that would conflict with
this
one. What I was thinking though is that is only an issue at sync
time.
As long as you know the id is unique in the client, and the status
of
that piece of data (new, modified, removed), then at sync time, you
can
rectify those id's that are out of sync with what is generated at
the
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
a
later client generates for a new object is rejected as a duplicate -
and
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 client-gen'ed
UUIDs.

+0 from me.

--Glen


_______________________________________________
aerogear-dev mailing list
_______________________________________________
aerogear-dev mailing list

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Bruno Oliveira
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
-
@abstractj
-
Volenti Nihil Difficile

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.asciidoc

On Sep 13, 2012, at 9:08 AM, Bruno Oliveira <[hidden email]> 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 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
get
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,
server,
etc.) generating an id for a piece of data that would conflict with
this
one. What I was thinking though is that is only an issue at sync
time.
As long as you know the id is unique in the client, and the status
of
that piece of data (new, modified, removed), then at sync time, you
can
rectify those id's that are out of sync with what is generated at
the
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
a
later client generates for a new object is rejected as a duplicate -
and
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 client-gen'ed
UUIDs.

+0 from me.

--Glen


_______________________________________________
aerogear-dev mailing list
_______________________________________________
aerogear-dev mailing list

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] UUID Generation

Kris Borchers
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 https://github.com/kborchers/aerogear-js/commit/0c19ffad7a74b3c1cbaf0e86b43948d9c74b5eae. 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 yet.

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 <[hidden email]> 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
-
@abstractj
-
Volenti Nihil Difficile

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.asciidoc

On Sep 13, 2012, at 9:08 AM, Bruno Oliveira <[hidden email]> 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 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
get
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,
server,
etc.) generating an id for a piece of data that would conflict with
this
one. What I was thinking though is that is only an issue at sync
time.
As long as you know the id is unique in the client, and the status
of
that piece of data (new, modified, removed), then at sync time, you
can
rectify those id's that are out of sync with what is generated at
the
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
a
later client generates for a new object is rejected as a duplicate -
and
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 client-gen'ed
UUIDs.

+0 from me.

--Glen


_______________________________________________
aerogear-dev mailing list
_______________________________________________
aerogear-dev mailing list

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev