AM
это будет не UUID а просто рандомная строка )
Согласно стандарта — не будет; согласно формата — будет. И не обязательно строка. Представление данных может быть разным.
Size: a a a
2020 December 12
A
То есть dump не выводит весь хвост после точки?
И никогда не выводил.
A
То есть dump не выводит весь хвост после точки?
Там есть настройка, которая указывает количество символов которые надо учитывать и обычно оно меньше чем нужно чтобы увидеть ошибку.
VC
Согласно стандарта — не будет; согласно формата — будет. И не обязательно строка. Представление данных может быть разным.
строка - это да, не подумав написал, конечно, 16 октетов ). Если любые 128 бит называть UUID то и результат
random_bytes(16) - UUID. Вопрос закрыт? )AM
строка - это да, не подумав написал, конечно, 16 октетов ). Если любые 128 бит называть UUID то и результат
random_bytes(16) - UUID. Вопрос закрыт? )Этого никто и не отрицал (более того, ряд пхпшных либ random_bytes и использует). Вопрос был в том, скорее, почему люди должны отказаться от uuid в пользу random_int.
AM
Этого никто и не отрицал (более того, ряд пхпшных либ random_bytes и использует). Вопрос был в том, скорее, почему люди должны отказаться от uuid в пользу random_int.
Кстати, 128 битное число в пхп просто так не заиспользуешь (без либ)
VC
Этого никто и не отрицал (более того, ряд пхпшных либ random_bytes и использует). Вопрос был в том, скорее, почему люди должны отказаться от uuid в пользу random_int.
потому что под uuid обычно понимается не 128 случайных бит, а 128 следующих стандарту
AM
потому что под uuid обычно понимается не 128 случайных бит, а 128 следующих стандарту
Ок, допустим это. Почему мы должны отказаться от uuid в пользу рандом_инт?
VC
Кстати, 128 битное число в пхп просто так не заиспользуешь (без либ)
а как число она нам и не нужно обычно )
AM
а как число она нам и не нужно обычно )
Так а предложение random_int тогда с какого перепуга?
VC
Так а предложение random_int тогда с какого перепуга?
просто как вариант генерации криптостойких псевдослучайных значений, может 64 бит или меьше буде достаточно, можно два раза вызвать и "склеить"
A
Сорян за скриншоты. Что за дичь тут происходит? Почему только 4.6? Почему не воспроизводится в консоли?
php > var_dump(4.6);
php shell code:1:
double(4.5999999999999996447286321199499070644378662109375)
за точность вывода отвечает параметр precision
AM
просто как вариант генерации криптостойких псевдослучайных значений, может 64 бит или меьше буде достаточно, можно два раза вызвать и "склеить"
Если 64 бит будет достаточно, то и безопасности юида тоже будет явно достаточно. Проигрышь будет разве что в размере хранимых данных, что на фоне других данных будет копейками.
> можно два раза вызвать и "склеить"
Каким образом склеить? В строку? А как потом конвертировать это в удобное хранение?
> можно два раза вызвать и "склеить"
Каким образом склеить? В строку? А как потом конвертировать это в удобное хранение?
VC
Если 64 бит будет достаточно, то и безопасности юида тоже будет явно достаточно. Проигрышь будет разве что в размере хранимых данных, что на фоне других данных будет копейками.
> можно два раза вызвать и "склеить"
Каким образом склеить? В строку? А как потом конвертировать это в удобное хранение?
> можно два раза вызвать и "склеить"
Каким образом склеить? В строку? А как потом конвертировать это в удобное хранение?
random_int и random_bytes - аналогичны для задачи сгенерировать N случайных байт. Что лучше использовать в конкретном случае зависит от этого случая
AM
Пользователь загружает в систему картинку с приватными данными (например паспорт).
С фронтенда загружается картинка, получается её uuid.
Делается запрос с uuid картинки на создание какого-нибудь ресурса, на просмотр которого у него (пользователя) будут права.
Проблема в том, что если другой пользователь угадает uuid уже существующей картинки и создаст свой ресурс с её (картинки) uuid - он сможет просматривать эту картинку.
Как можно решить эту проблему?
Мне в голову пришло только шифровать идентификаторы. Но никто так не делает вроде, поэтому я сомневаюсь
С фронтенда загружается картинка, получается её uuid.
Делается запрос с uuid картинки на создание какого-нибудь ресурса, на просмотр которого у него (пользователя) будут права.
Проблема в том, что если другой пользователь угадает uuid уже существующей картинки и создаст свой ресурс с её (картинки) uuid - он сможет просматривать эту картинку.
Как можно решить эту проблему?
Мне в голову пришло только шифровать идентификаторы. Но никто так не делает вроде, поэтому я сомневаюсь
> если другой пользователь угадает uuid уже существующей картинки
Можешь представить себе uuid в виде 58bit идентификатора + 64bit ключа доступа. Я сомневаюсь, что вы забьёте все 58bit изображениями (это очень много в штуках) и ещё больше сомневаюсь, что обычный человек сбрутит 64bit ключ через http api интерфейс.
Можешь представить себе uuid в виде 58bit идентификатора + 64bit ключа доступа. Я сомневаюсь, что вы забьёте все 58bit изображениями (это очень много в штуках) и ещё больше сомневаюсь, что обычный человек сбрутит 64bit ключ через http api интерфейс.
k
> если другой пользователь угадает uuid уже существующей картинки
Можешь представить себе uuid в виде 58bit идентификатора + 64bit ключа доступа. Я сомневаюсь, что вы забьёте все 58bit изображениями (это очень много в штуках) и ещё больше сомневаюсь, что обычный человек сбрутит 64bit ключ через http api интерфейс.
Можешь представить себе uuid в виде 58bit идентификатора + 64bit ключа доступа. Я сомневаюсь, что вы забьёте все 58bit изображениями (это очень много в штуках) и ещё больше сомневаюсь, что обычный человек сбрутит 64bit ключ через http api интерфейс.
это да, я тоже сомневаюсь
DT
Чем обычный авторизационный доступ плох?
DT
Пусть угадывает, пока у него нет прав - не увидит. As easy as it is
AM
Чем обычный авторизационный доступ плох?
Обсуждали выше https://t.me/prophp7/250688
AM
Придётся привязывать картинку к юзеру