Size: a a a

2020 November 11

ДЩ

Дмитрий Щербаков... in phpGeeks
John D
теперь понял как она работает. Не плохо.
по ссылке там сразу реалтайм пример есть
источник

JD

John D in phpGeeks
Но даже используя jwt не похоже ли это на костыль ? как контролировать такое ? мы же ни где не будем иметь информацию про эти линки. Не сможем их удалить самостоятельно. Не будем знать когда юзер пытался сменить емайл, и то что он делал эти действия. А так имея эту таблицу отдельную, то у нас больше контроля над всем этим как по мне. Да и я лично не понимаю чем это тяжелее просто сделать отдельную таблицу с привязкой к юузер ид.
источник

JD

John D in phpGeeks
как по мне это тупо отдельная таблица, и при сверке кода активации ты её используешь вместо юзер таблицы
источник

SI

Sergei Ischuk in phpGeeks
2 варианта:
1 написан, удовлетворяет текущие потребности ничего не нужно менять
2 только обсуждается, хочет покрыть потребности которых может не быть, нужны изменения
источник

SI

Sergei Ischuk in phpGeeks
и продолжает тратить драгоценное время
источник

V

Victooor in phpGeeks
Дмитрий Щербаков
основной посыл jwt в том что там уже хранится информация любая как нужна и ее не нужно нигде хранить а доверяют ей по подписи которая также находится в jwt
получили обратно jwt проверили валидность подписи и данных, если гуд то верим что в jwt никто не лазил и ничего не подделал
Что-то навороченное сильно получается. Jwt тут ни к месту, имхо
источник

NG

Nik Gubin in phpGeeks
Ребят, у вас нет технического руководителя, который может разрешить спор? К чему, и правда, споры? У вас проблема не в хардах, а в софтах, что не умеете приходить к решению. У меня есть примеры, когда прав оказался бы один, и есть не меньше примеров, когда прав оказался бы второй.
источник

JD

John D in phpGeeks
Sergei Ischuk
2 варианта:
1 написан, удовлетворяет текущие потребности ничего не нужно менять
2 только обсуждается, хочет покрыть потребности которых может не быть, нужны изменения
Ты ссылаешься на то что уже так сделано и сойдет так. Но я именно обсуждаю какой вариант правильнее и почему.
То есть ты можешь оставить реализацию также как она сейчас у тебя сделана, но тут мы обсуждаем вариант который правильный не учитывая то что ты уже это сделал )))
Для того чтобы на будущие был использован именно правильный вариант.
источник

V

Victooor in phpGeeks
John D
Ты ссылаешься на то что уже так сделано и сойдет так. Но я именно обсуждаю какой вариант правильнее и почему.
То есть ты можешь оставить реализацию также как она сейчас у тебя сделана, но тут мы обсуждаем вариант который правильный не учитывая то что ты уже это сделал )))
Для того чтобы на будущие был использован именно правильный вариант.
Пацаны, вам надо разбежаться 😂
источник

JD

John D in phpGeeks
Victooor
Пацаны, вам надо разбежаться 😂
Я просто пытаюсь найти доводы почему первый вариант хорош и например не хорош второй либо почему оба варианта хороши.
источник

JD

John D in phpGeeks
Nik Gubin
Ребят, у вас нет технического руководителя, который может разрешить спор? К чему, и правда, споры? У вас проблема не в хардах, а в софтах, что не умеете приходить к решению. У меня есть примеры, когда прав оказался бы один, и есть не меньше примеров, когда прав оказался бы второй.
Интересно просто посмотреть что думает комюнети
источник

JD

John D in phpGeeks
John D
Интересно просто посмотреть что думает комюнети
То есть именно обсуждение структуры. Эти темы интересны.
источник

NG

Nik Gubin in phpGeeks
John D
Интересно просто посмотреть что думает комюнети
С этой позиции согласен и полностью поддерживаю.
источник

M

Michael in phpGeeks
John D
Привет Ребята,
У меня такой спор вышел со знакомым по проектированию активации акаунта и смены емайла.

Есть два варианта которых мы обсуждаем.

1. Хранить токен (код для активации) в таблице юзеров. И если активирует акаунт, ставим статус что активировали емайл.
   При смене емайла, опять же используем поле токен в юзер таблице а также ещё поле new_email где будет хранится новый емайл до тех пор пока не активируем его, потом нулим его.
   Но с другой стороны то что линк живёт вечно (пока не активируют), ничего не сломает по безопасности, он же не получает доступ к акаунту.
   
Минусы этого подхода к примеру то что линк на активацию будет всегда активным (пока не активируют емайл) иначе придётся создавать ещё одно поле уже под expires_at или что то в этом роде.

2. Хранить в отдельной таблице. Структура типа: id, user_id, type, value (тут будет например емайл на который сменим), token, created_at, expired_at
Такой вариант хорош что можно делать разные активации, как смена емайла, активация акаунта и.т.п.

Вариант 2 более гибкий, но первый в какой то мере быстрее.
Кто что думаем по этому поводу ? какой вариант правильней ?  Учитывая ещё момент что продукт надо выводить быстрее на продакшен.
делайте второй. там времени больше на полчаса, вы часть уже потратили в чате
источник

V

Victooor in phpGeeks
John D
Я просто пытаюсь найти доводы почему первый вариант хорош и например не хорош второй либо почему оба варианта хороши.
Первый хорош только более быстрой реализацией. Больше нет плюсов
источник

JD

John D in phpGeeks
Victooor
Первый хорош только более быстрой реализацией. Больше нет плюсов
Вот я тоже так согласен. Первый вариант чучуть быстрее, но плюсов больше нет. И потенциально много минусов.
источник

JD

John D in phpGeeks
Michael
делайте второй. там времени больше на полчаса, вы часть уже потратили в чате
Например для меня то что я потерял в чате, это не важно. Самое главное найти ответ.
Дела по проектированию структуры это что то что за 5 минут не выучешь. Только с опытом.
источник

V

Victooor in phpGeeks
Лично я, если сомневаюсь, то закладываю лишний потенциал в код. Часто окупается
источник

ДЩ

Дмитрий Щербаков... in phpGeeks
а например программисты ВК говорят "если можешь решить задачу раз раз и готово... делай так... потом отрефакторишь... мы так делаем" ))
источник

V

Victooor in phpGeeks
Дмитрий Щербаков
а например программисты ВК говорят "если можешь решить задачу раз раз и готово... делай так... потом отрефакторишь... мы так делаем" ))
А я то думаю, кто весь этот пиздец на проектах оставляет. Который потом переделывать приходится. А это оказывается вк-программисты...
источник