Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102102
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <fd871a6a-b101-3c19-5603-51b119a86de7@librelamp.com>
References: <CANUQDCibQPMi8v7jPvHk2EKhaO81cW3OrMLc2vit1rd+xTxe2w@mail.gmail.com>
 <CAL0xaBG32fRc5trMGkZYApHteJ7T-3HhF+40Vnk1C2vUh88K=w@mail.gmail.com> <fd871a6a-b101-3c19-5603-51b119a86de7@librelamp.com>
Date: Fri, 11 May 2018 12:50:49 +0200
Message-ID: <CAL0xaBHBBQ9ThdMxQJ2qZVdXBqTFvuH4hzR5HMNAbzceGmF6CQ@mail.gmail.com>
To: Alice Wonder <alice@librelamp.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000086a5b1056bebea8c"
Subject: Re: [PHP-DEV] [RFC] Deprecation of uniqid()
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--00000000000086a5b1056bebea8c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2018-05-11 12:36 GMT+02:00 Alice Wonder <alice@librelamp.com>:

> On 05/11/2018 01:59 AM, Arvids Godjuks wrote:
>
>> 2018-05-10 16:33 GMT+02:00 Niklas Keller <me@kelunik.com>:
>>
>> Hey,
>>>
>>> I hereby propose to deprecate uniqid(). There have been attempts to fix
>>> it
>>> (
>>> https://wiki.php.net/rfc/uniqid), but those were rejected during
>>> discussion, because there's no possible fix without breaking BC. Instea=
d
>>> of
>>> a subtle BC break, this RFC favors the deprecation and moving users to
>>> other functions.
>>>
>>> It's to be discussed whether the function should be removed with PHP 8.=
0
>>> or
>>> just deprecated to avoid fully breaking things where it's not strictly
>>> necessary. A deprecation will probably avoid most new usages, which is
>>> the
>>> main goal.
>>>
>>> RFC: https://wiki.php.net/rfc/deprecate-uniqid
>>>
>>> Kind Regards,
>>> Niklas
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>> Hello,
>>
>> as a userland user of this function I do disagree with it's outright
>> removal. It has it's uses.
>> What can be done with it is drop the $more_entropy flag and make it
>> generate at least as long strings and use random_bytes under the hood fo=
r
>> a
>> better random.
>> It can also adopt a length parameter so you can vary the random part as
>> much as you need it.
>>
>> You don't always need a truly random token - I have a system that uses
>> uniqid to generate tens of thousands tokens per request and it's actuall=
y
>> a
>> good thing they are time based at the start of it with a random part at
>> the
>> end (as I said the random part should be improved and get rid of that
>> stupid dot when generating with $more_entropy =3D true).
>>
>>
> It seems to me that for your use case, you could just use the time()
> function to get part of your unique id and then use libsodium to generate=
d
> a nonce for the "random" part, using sodium's function for increment the
> nonce between each use.
>
> Predictable, sure, but your use case says they don't need to be a truly
> random token - just unique (essentially a non-random nonce) but with a ti=
me
> component.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hello Alice,

Sure, there is lots I can do about that project, including what you have
described. One thing though - client does not need it or want it or want's
to pay for that work. That whole project is a poster child for a "side
project on a bare minimum, but done by a competent developer instead of a
student so it actually works in the long run"

--=20
Arv=C4=ABds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

--00000000000086a5b1056bebea8c--