Согласна, сам подход для генерации токена лучше использовать другой. История со сроком жизни токена — из серии «вот если бы хотя бы не… то ничего бы не произошло». Если бы мы по-тупому не генерировали токены или хотя бы uuid при генерации использовали или срок жизни, если бы мы не удалили пользователей из базы, если бы мы прогнали сценарий на тестовой площадке и т.д и т.п.
Но факапы рождаются, только если они продрались через этот лес условностей)
Не горжусь этой историей, но и не считаю, что ее стоит замалчивать. Да, мы накосячили. В команде не было многоопытного товарища, который сказал бы — ребята, так не делается. Сами же мы тогда посчитали, что быстрое и работающее решение — достаточные критерии качества. Опытным путем выяснилось, что это не так
и вечный токен, который генерировался однозначно из этого id.
вы абсолютно правы, проблема именно в повторяемой генерации, что я и имела ввиду под однозначно. Один и тот же id давал один и тот же токен, без вариантов.
на описанную ситуацию вы бы нарвались даже с короткоживущим токеном, достаточно уложиться в срок его жизни.
Здесь не согласна. Короткоживущий токен содержит информацию о времени жизни, а это уже даст разные токены для одинаковых id, тк добавляет еще одну зависимость в генерацию.
Логичнее, но суть в том, все комменты в любом случае будут идти от одного и того же аккаунта, токен/логин-пароль которого вы давали при настройке системы. То это будет либо условный Вася Иванов, либо отдельно созданный для технических целей пользователь GitLab. Второй вариант выглядит аккуратнее, но да, будет болтаться лишний юзер, и тут уже выбор за вами, как удобнее.
Информация
В рейтинге
Не участвует
Откуда
Калининград (Кенигсберг), Калининградская обл., Россия
Но факапы рождаются, только если они продрались через этот лес условностей)
Здесь не согласна. Короткоживущий токен содержит информацию о времени жизни, а это уже даст разные токены для одинаковых id, тк добавляет еще одну зависимость в генерацию.