|Info||Documentation||View files (13)||Download .zip||Reputation||Support forum||Blog||Links|
|Ratings||Unique User Downloads||Download Rankings|
|Not yet rated by the users||Total: 81||All time: 9,937 This week: 174|
|uuid64type 1.0.0||BSD License||7.3||Databases, Data types, PHP 7, Traits|
This package provides a custom Doctrine data type for UUID v4 values.
A custom Doctrine datatype for UUIDv4 values in database tables that offers a more compact format that can be useful for primary key columns. Also, includes helper traits to make integration easier.
Use composer to install from packagist.
composer require dragonrun1/uuid64type
For an example of integrating with Doctrine cli configuration have a look at:
For examples of using Uuid64Type in a Doctrine project see my related project on github:
Look at the
config/cli-config.php for how to register the custom type in
See any of the
src/Model/Entities/* table class files for using the helper
If this project was just another UUID v4 (random) library there would be little point as there are already several fine ones out there for PHP, but where they just do UUIDs this library tries to solve a limitation in common database designs as well. The limitation is how database engines typically generate their IDs which I'll detail next.
Database engines be they MySQL, PostgreSQL, SQLite, or any other all have some way to generate sequences for ID columns. How they do it is nearly as varies as the engines themselves since ID generation falls outside of the existing SQL standards, but the end result is generally the same in that you end up with a simple auto-incrementing integer sequence. So where does the limitation come in and how is it bad? Two words: auto-incrementing and sequence. Add two more words: bad actors. Combining these four words and some of you may have started see the possible problems. Next I'll show why combining a bad actor with the first two words can become an issue.
First a question for you. How often have you directly exposed a database table ID in a web form on the Internet? If you are like most developers including me I think we have all done this without thinking about it more than once. We may have made it a hidden field but, it's plain to see for anyone looking directly at the page code. Let's now think about auto-incrementing sequence and what it can tell us about the underlying DB table. The universal default for the sequences is they start at 1 and increase by 1 for each row added to the table. By causing the site to add a row to the table and looking at that new row we can make a good guess to how many rows there are in it and by add a second row make a good guess at how fast it is growing. How is that information useful? What if the table holds users accounts, and it's their account ID? Now they have some idea how many actual user accounts they can get in a data breach or are available to be attacked. Say they get just a list of user names, and the IDs which ones should they attack first? I'd attack the first accounts made as they are likely to be admin or test accounts with greater access. I'm sure you can think of many other ways that simple incremental sequences could be attacked that you probably never thought of before I pointed out the risks.
Expected use will be in Doctrine entities instead of using auto-increment IDs.
A UUID is 128-bits long in binary and, most programming language can only support it in some kind of string or integer array format. Most commonly binary strings will be used for compactness where strings can contain (nul) chars. This format normally isn't seem except in functions were the UUID is being created as it's hard for programmers to visualize it easily. The normal formatted string version with 36 characters or as a hexadecimal string with 32 characters are much more commonly used. Both of these formats trade off two times or more memory usage to make them easier to work with. By using a base 64 encoding it increases the memory usage by less than 40 percent (22 chars) over a binary string (16 chars).
So in summary these are the benefits to using this custom base 64 encoded format:
* Database compatible - Can be directly stored in any of the following field
types: VARCHAR, CHAR, BINARY, etc.
* URL compatible - Doesn't contain any chars that require special
escaping in URLs.
* HTML compatible - Doesn't include any special chars that need to be escaped
when used in html forms or tag property values. HTML 5 relaxed the rule requiring all ID property values to start with a letter.
* More Human readable - Since base 64 is shorter that other formats most
people find it easier to read.
* The best memory to speed trade-off - The binary string takes up the
least memory but, it needs to be converted to and from other formats when using it in URLs etc. which can cause un-needed server load issues. The normal and hexadecimal forms are both longer which adds to both memory and server load issues. The custom format hits the sweet spot where no conversions aren't required and, it doesn't use a lot of extra space either.
Please note that this project has a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.
Please make sure to update or add tests as appropriate.
Copyright (c) 2019 Michael Cummings. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|bin (4 files)|
|config (1 file)|
|src (1 file, 2 directories)|
|Version Control||Unique User Downloads||Download Rankings|
|Applications that use this package|
If you know an application of this package, send a message to the author to add a link here.