Size: a a a

2021 July 18

AA

Anri Asaturov in ctodailychat
понял, спасибо
источник

VG

Valentin Golev in ctodailychat
но на самом деле я и не думал о нем пока мне интерн не показал что как-то умудряется с его помощью кодить и не думать о том что пишет вообще 🤣
источник

AB

Afanasy Barbarov in ctodailychat
Он (tabnine) у меня дико батарею жрал, поначалу думал, что это intellij после обновления. У вас с этим как?
источник

AM

Aga Mahmudov in ctodailychat
А вы все каким планом пользуетесь? Бесплатным или pro?
источник

AA

Anri Asaturov in ctodailychat
Забыл тут запостить, Дима ответил на этот вопрос: Про книжку: я вообще одинаковые цены поставил и для kindle и для бумаги. С бумажной мне больший % перепадает, потому что если цена за киндл книжку больше 9.95, они забирают 70%
источник

AR

Anton Revyako in ctodailychat
источник

AA

Anri Asaturov in ctodailychat
Вопрос знатокам. Как вы прячете numeric serial primary key когда передаете его клиентам? Генерите дополнительный uuid с сохранением его в отдельной индексируемой колонке или шифруете primary key?
источник

IV

Igor V in ctodailychat
источник

AA

Anri Asaturov in ctodailychat
Do you have a question or comment that involves "security" and "hashids" in the same sentence? Don't use Hashids. 🙁
источник

IV

Igor V in ctodailychat
Hashids  не для sensitive data. Pk к sensitive data не относиться
источник

AA

Anri Asaturov in ctodailychat
ну это attack vector тем не менее, как секьюрити так и для конкурентного анализа, поэтому хочется его не просто сделать красивым для урла, но и безопасным
источник

AR

Anton Revyako in ctodailychat
но лучше все равно uuid )
источник

IV

Igor V in ctodailychat
Ничем не лучше
источник

AO

Alexander Ovchinniko... in ctodailychat
У меня первичные ключи (UUID) генерируются с помощью https://github.com/anthonynsimon/timeflake, поэтому не прячу их, что позволяет упростить код и избавиться от необходимости генерировать некий отдельный ID для внешних запросов
источник

AO

Alexander Ovchinniko... in ctodailychat
Собственно, мне нравится, что это выглядит как обычный UUID в итоге (и храниться может аналогичным образом), а генерируется при этом чуть лучше по сравнению с типичными вариантами UUID1 и UUID4
источник

A

Alex in ctodailychat
источник

AA

Anri Asaturov in ctodailychat
Короче я видимо неправильно задал вопрос.
Где по-вашему меньше боли
1. секьюрно енкодить/декодить цифровой PK (он уже цифровой и последовательный, никуда не деться) да так, чтобы еще url-safe и не 100 символов
2. генерить отдельный nanoid и обращаться к базе по нему (string index) когда нету PK
источник

AA

Anri Asaturov in ctodailychat
под секьюрностью понимается невозможность декодить не зная ключа
источник

AO

Alexander Ovchinniko... in ctodailychat
Мне был бы ближе 2. вариант если выбор ограничен этими двумя вариантами)
источник

AA

Anri Asaturov in ctodailychat
и невозможность понять последовательность и дистанцию между 2 id
источник