I'm working on a private message system and I want to assign a unique conversation number so I can Identify if multiple users are taking part to the same conversation. I was thinking to assign the Userid of the person who send the message + microtime() like this:
$conversation_number = md5($_POST['user_id']+microtime());
Would this code originate always a unique number or it may also possible that, accidentally, it generate the same number for the subsequent messages?
You could use uniqid, which is used to generate a unique ID.
I think php uniqid is sufficient
From PHP DOC
If set to TRUE, uniqid() will add additional entropy (using the combined linear congruential generator) at the end of the return value, which increases the likelihood that the result will be unique
try
uniqid('id', true)
However there are approximately 3.402823669209387e+38 different values in a 32 digit hex value (16^32) in md5 the your odds are phenomenally small that there will be a duplicate all the same
Why not use the UniqId() function?
Related
I am developing a event organization website. Here when the user registers for an event he will be given a unique random number(10 digit), which we use to generate a barcode and mail it to him. Now,
I want to make the number unique for each registered event.
And also auto increment
One solution is to grab all the auto increment numbers in an array and generate a auto increment number using laravel takes the form (0000000001 to 9999999999) and loop through and check all the values. Grab the first value that doesn't equal to any of the values in the array and add it to the database.
But I am thinking that there might be a better solution to this. Any suggestion?
Select Maximum number stored in your DB and add 1 in it like:
SELECT (MAX(Column_Name)+1) AS Max_val FROM Table_Name;
I suggest simple timestamp-based solution using the Carbon class to produce a unique number using timestamp. It's fairly simple to have a basic unique and random stamp generation using timestamp.
You can use as given below,
use Carbon\Carbon;
$current_timestamp = Carbon::now()->timestamp; // Produces something like this 1552296328
You can use it as a unique identifier. If you want the next numbers, just +1. But keep in mind, you have to manage another number batch in a timely manner. (i.e if you have generated 500 numbers for now by increment, You should not generate another number for the next 500 seconds. Otherwise, it will repeat the number). If you want to know more, you can read here.
The solution with rand() function may not work here because it can re-produce the existing number in the database and you will be errored for Unique Constraint Violation(i.e. If you have column unique in DB).
No matter what approach you use, it would never be truly random. It will be PRNG. For your case, I think auto increment with zero fill should be enough.
But if you are set on using random number then using rand() function of PHP should be enough. 10 digit means 10000000000 unique number.Unless your project has millions of events it should realistically be no problem. So, approach 1 should be no problem. Also, you can check after generating any random number that whether that number is already present(There is 0.000001% or something like that chance.). If it is present then try to generate a random number again.
But if your project gets very successful (I.E. millions of events) then problems similar to Y2K might creep up.
MySQL UUID would give you truly unique is: Store UUID v4 in MySQL
You don’t need to worry about auto incrementing.
I'm trying to generate a unique order number for my ecommerce application, this is my code:
<?php
$bytes = random_bytes(3);
$random_hash = bin2hex($bytes);
$order_num = $random_hash . "1";
echo strtoupper(hash('crc32b', $order_num));
The order number (in the example is 1), is going to be an auto-increment value retrieved from MySQL.
Does this ensure me uniqueness?
I wanted a short max 8-10 chars unique final value.
An only numbers solution would be fine too.
As far as I know, most hash algorithms make no guarantee of when collisions might occur, so you're probably just as likely to get a collision with your proposed code as using the random part on its own.
If the auto-increment part is unique, and the random part is just to avoid guesses, you could just concatenate the two parts together (i.e. everything in your example before the hash call). That way if the same random number comes up twice, it will have different numbers on the end.
If that results in something too long, you could do something with base_convert or asc to convert the number into a shorter representation.
The hash function will not provide any uniqueness to the id, it only obfuscates the id a bit.
If you have lets say 100 possible values, you would get 100 possible hashes from them, no more. If an attacker wants to brute-force the hashes, he can pick the 100 possible hashes and try them.
In your case with 3 bytes of randomness, you would not get all possible combinations before you get a duplicate. So the same random number would be generated much earlier than with 3 bytes of possible combinations.
There are two common approaches when it comes to unique ids:
You let the database automatically increment the id, this makes sure that the id is unique.
You generate a UUID (global id with 16 bytes) which offers such a huge keyspace, that a duplicate is extremely unlikely. In practice one can neglate the possiblilty of duplicates.
The UUID has a lot of advantages and one disadvantage:
(+) UUID's can work decentralized e.g. in an offline scenario.
(+) One can generate the id before it is inserted in the database, so one has not to wait before the row is created in the db.
(+) The ids are not deterministic, so an attacker cannot guess the next id.
(-) They use more storage space and are a bit slower when searching.
I'm generating a 5 letter uniqid in PHP this way:
$id = substr(uniqid(),0,5);
And every single time I call it, I get the value 5004b. Why is that happening?
If I remove the substr, the 5004b part stays constant while the remaining changes. Isn't this severely reducing the entropy of the GUID being generated?
uniqid() is based on microtime(), the beginning is going to be the same for a long time.
My suggestion is that you just increment every time or something if you need a 5 digit long uniqid.
uniqid() only works if you take the full value. It would make more sense to take the last five characters rather than the first:
$id = substr(uniqid(),-5);
However, after just one second you'll get repeating values. You really should just take the full uniqid().
To increase the entropy of the output, you can use uniqid('', true);. According to the doc, this "will add additional entropy (using the combined linear congruential generator) at the end of the return value, which increases the likelihood that the result will be unique."
If you need a unique ID, don't use uniqid() as it only returns the an ID based on the current time. If your computer is fast enough, it will produce the same values again and again.
Enlarging the entropy (by passing "true" as the second argument) helps, but it cannot hide the fact that this function is flawed, and should not be used more than once in a script.
you could use something like substr(uniqid(rand(),1),0,7). this generates unique ids from a random seed. then again if you are saving them to a database you may need to check whether they exist before generating again. Do something like:
function idExists($id){
//query database and check if the id already exists
}
//then use this to generate
$id=null;
do{
$id=substr(uniqid(rand(),1),0,7);
}while(idExists($id));
//then you get your unique id here
In order to produce a unique Id I suppose I must use the uniqid function in php.
But uniqid produces a 13 digits long HEXA number, by default.
4f66835b507db
I would like to reduce this number to 7 digits long NUMERIC number but I want to conserve the unicity. Is it possible ?
4974012
This number will be used as User Id. The authentication will be done with thid Id and a password.
Some people say uniqid is not unique ! Is it a bad choice ?
Any "unique" number will eventually have a collision after generating enough records. To ensure uniqueness, you need to store the values you generated into a database and when generating next one, you need to check if there is no collision.
However, in practice, applications usually generate IDs as a simple sequence 1,2,3,... That way you know you won't get a collision until you run out of the datatype (UINT is usually 32 bits long, which gives you 4 billion unique ids).
Uniqid is not guaranteed to be unique, even in its full length.
Furthermore, uniqid is intended to be unique only locally. This means that if you create users simultaneously on two or more servers, you may end up with one ID for two different users, even if you use full-length uniqid.
My recommendations:
If you are really looking for globally unique identifiers (i.e. your application is running on multiple servers with separate databases), you should use UUIDs. These are even longer than the ones returned by uniqid, but there is no practical chance of collisions.
If you need only locally unique identifiers, stick with AUTO_INCREMENT in your database. This is (a little) faster and (a little) safer than checking if a short random ID already exists in your database.
EDIT: As it turns out in the comments below, you are looking not only for an ID for the user, but rather you are forced to provide your users with a random login name... Which is weird, but okay. In such case, you may try to use rand in a loop, until you get one that does not exist in your database.
Pseudocode:
$min = 1;
do {
$username = "user" . rand($min, $min * 10);
$min = $min * 10;
} while (user_exists($username));
// Create your user here.
Write a while loop that generates random letters and numbers of a desired length, which loops until it creates an ID that is not already in use.
Well, by reducing it to 7 characters and only numeric, you are reducing the 'uniqueness' by a lot.
I suggest using an auto increment of the user ID and start at 1000000 if it has to be 7 digits long.
If you really must generate it without auto increment, you can use mt_rand() to generate a random number 7 digits long:
$random = mt_rand(1000000, 9999999);
This is not ideal because you will need to check if the number is already in use by another user.
If you are using a Database. Define an id column as unique and auto-incremented, and then let the database manage your ids.
It's safer.
Read more : mysql-doc
Take a lookt at this article
Create short IDs with PHP - Like Youtube or TinyURL
It explains how to generate short unique ids, like youtube does.
Actually, the function in the article is very related to php function base_convert which converts a number from a base to another (but is only up to base 36).
I'm making an anonymous commenting system for my blog. I need the users to have a randomly picked username from an array I have made, it has 600 usernames. I can't just make it random because then people wouldn't know if it was the same person posting a reply, so I have given each post a randomly generated key between 1-9999, using the key and the users ID I want to do some sort of calculation so that number will stay consistent through that particular post. The result has to be within 1-600.
something like:
user_id x foo(1-9999) = bar(1-600)
Thanks.
What you're probably looking for is a hash function. To quote Wikipedia:
A hash function is any algorithm or subroutine that maps large data sets of variable length, called keys, to smaller data sets of a fixed length.
So you can use a standard hash function, plus modular arithmetic to further map the output of that hash function to your username range, like so:
function anonymise($username, $post_key) {
$hash = hash("adler32", "$username/$post_key");
$hash_decimal = base_convert($hash, 16, 10);
$anonymised_id = $hash_decimal % 600;
return $usernames[$anonymised_id];
}
So, what you really want is a unique identifier for every poster?
Why not use http://php.net/ip2long modded 600?
of course, you'll have to do some collision detection with that too.
You can try using md5 on the concatinated id and post key. it gives you a consistent 32 byte hash of that. And it is actually a hexadecimal string, so you can actually covet it to a number easily by doing a hex to int conversion.
Edit: Based on your feedback. you can take the generated int and modulas it by 600.