I've been toying with the idea for a few days but have yet to figure out a good way to implement it. I'm wanting to replace auto_increment ID's with UUID's. Any suggestions on how I should do that?
I've been toying with the idea for a few days but have yet to figure out a good way to implement it. I'm wanting to replace auto_increment ID's with UUID's. Any suggestions on how I should do that?
1. PHP has a uuid extension, but I haven't tried it. It supposedly implements all 5 versions of RFC 4122.
2. If you're desparate, MySql has at UUID function. I believe it is RFC 4122, Version 1 compliant on Linux. On Windows, it uses a pseudo-random number for the node field (roughly, section 4.5 of the RFC).
The attached pair of files implement Version 1. I probably went a bit overboard, even saving state as per the RFC. It requires a db table defined for MySql as:
Also, my implementation uses the PHP extension GMP.
Your config file main.php will need:
where serverMAC is the MAC address of the webserver (faked in this example with all zeros) and uuidsPerTick is 0.01 * the number of nanoseconds per clock tick on your webserver.
Use as follows:
It all seems like overkill, but it works.
I wrote UuidGenerator as a singleton to reduce overhead when generating multiple uuid's. That's the reason for the getInstance() call.
I hope this helps.
I think it can be done the way described in cookbook (for timestamps):
http://www.yiiframew…oc/cookbook/10/
but instead of new CDbExpression(‘NOW()’) you should use something like String::uuid()
As for me, I've borrowed uuid() function from CakePHP.
Quote
http://www.yiiframew…oc/cookbook/10/
but instead of new CDbExpression('NOW()') you should use something like String::uuid()
This looks like a good solution, certainly simpler than mine.
Quote
Although advertised as RFC 4122 compliant, I'm not so sure that CakePHP's implementation really is: it appears to be based the server's IP address rather than it's MAC address. But I just took a cursory look.
I rolled my own because some data exchange standard I'm trying to meet specifies not only the RFC but it's Version 1. This will not be required by most apps.
If the goal is just to create unique id's without auto_increment, then the following is simple and will be adequate in many situations:
With the last option, be aware that the probability of an id clash is infinitesimal but not 0.
Aye, I was thinking of snagging CakePHP's but like you said, I'm not sure it's RFC 4112 compliant and there has been some discussion running around that CakePHP's has a high (comparatively speaking of course) collide rate. I'm not really opposed to auto_increment but I need a random hash to prevent URL guessing anyway and a UUID seems the easiest with the benefit of being just about 100% unique.
I'll poke around and will release whatever I come up with.
So far I'm thinking that
is the simplest way. Just going to add a isUnique requirement and the one in a trillion chance that someone has an id collide I'll just nicely ask them to re-submit the form. Probably will just have it automatically re-generate a hash eventually. I suspect I'm doing something wrong with this unique check but since I can't really force a UUID to collide I'd like an opinion on this.
Am I doing anything particularly wrong there or not?
True UUID's aren't good for combating URL guessing. The sha1 option works better for that.
Quote
Really? Not sure I understand your reasoning. (Not being a smartass here.) UUID's are intended to be highly unique and 'should' be nearly impossible to generate the same UUID twice. The length would make it impossible for a human to guess and pretty difficult for a script to guess.
They have much less randomness then they seem at first appearance. The last last 12 digits are always are the MAC address of your computer (at least for v. 1 UUID's). Four digits are the "clock sequence" and are only used if you're generating UUID's faster than the resolution of your system clock. The rest are tied to the time created. If you server clock ticks 1000 tines per second, and we know what day the id was generated, then we are down to about 8.6 million guesses. Guessing that the id was generated during business hours brings us down under 3 million guesses needed. That's quite a lot when typing your guesses by hand, but not so bad when applying some computer umph to the job.
Quote
Aye, I hear what your saying. 3 million guesses seems a hell of alot to guess just to find a single profile. And even if they 'did' find it there wouldn't be much useful information to get from it so I don't think that's an issue in this case.
You DO make a great point however that UUID's shouldn't be used as a lone security measure since as you just said, they can be guessed to a certain degree.