Пилю сам потому что проект для обучения, знаю что есть бандлы готовые, хочу без них и при этом что бы по безопасности не было проблем

могу еще своих проблем накинуть, можно? )))

Привет, сейчас делаю аутентификацию и регистрацию через апи на симфони 4, кому не жалко пары минут - посмотрите код пожалуйста, скажите что я сделал не так и что стоит переделать что бы я себе не выстрелил в колено. Сейчас у меня есть 2 аутентификатора: PasswordAuthenticator - его задача найти юзера по логину и паролю, выдать в ответ токен который клиент должен будет передавать через (/api/users?apiKey=...), этот аутентификатор работает только по пути /api/login. Второй же TokenAuthenticator - на его плечах найти юзера по токену и авторизировать его, если никого не нашли - ничего страшного, запрос идёт дальше, возможно для этого роута не требуется авторизации, этот аутентификатор работает по всех роутах с префиксом /api А теперь вопросы которые меня беспокоят - кто должен отвечать за генерацию токена? Нормально ли делать так: https://github.com/svbackend/my-art-lib/blob/master/src/Security/PasswordAuthenticator.php#L72 ? Интересует мнение не только по этой строке но и по всему методу Второй момент это инвалидация токенов, как лучше всего это организовать и где? Пока что пришёл к этому - надо вынести токены в отдельную таблицу куда добавить поле expires_at, TokenAuthenticator будет загружать токен только когда expires_at >= NOW() если же токен нашёлся но просрочился - требуем юзера авторизироваться заново, но не нравится момент что в этом случае в юзера "сессия" будет слетать каждые там 2 недели условно (в зависимости от настроен токена), как можно этого избежать? Выдавать токены на год? Пока на этом всё, буду благодарен за любые ответы

Вроде на основе phpleague и сделали бандл

Я тут выше чуть не целую статью написал с объяснением что мне не нравится в том что у меня получлось

может по каким товарам больше спрос например

Привет, сейчас делаю аутентификацию и регистрацию через апи на симфони 4, кому не жалко пары минут - посмотрите код пожалуйста, скажите что я сделал не так и что стоит переделать что бы я себе не выстрелил в колено. Сейчас у меня есть 2 аутентификатора: PasswordAuthenticator - его задача найти юзера по логину и паролю, выдать в ответ токен который клиент должен будет передавать через (/api/users?apiKey=...), этот аутентификатор работает только по пути /api/login. Второй же TokenAuthenticator - на его плечах найти юзера по токену и авторизировать его, если никого не нашли - ничего страшного, запрос идёт дальше, возможно для этого роута не требуется авторизации, этот аутентификатор работает по всех роутах с префиксом /api А теперь вопросы которые меня беспокоят - кто должен отвечать за генерацию токена? Нормально ли делать так: https://github.com/svbackend/my-art-lib/blob/master/src/Security/PasswordAuthenticator.php#L72 ? Интересует мнение не только по этой строке но и по всему методу Второй момент это инвалидация токенов, как лучше всего это организовать и где? Пока что пришёл к этому - надо вынести токены в отдельную таблицу куда добавить поле expires_at, TokenAuthenticator будет загружать токен только когда expires_at >= NOW() если же токен нашёлся но просрочился - требуем юзера авторизироваться заново, но не нравится момент что в этом случае в юзера "сессия" будет слетать каждые там 2 недели условно (в зависимости от настроен токена), как можно этого избежать? Выдавать токены на год? Пока на этом всё, буду благодарен за любые ответы

может по каким товарам больше спрос например

мобильное приложение )

мобильное приложение )

мне это кажется странной идеей чтобы тонкий клиент сам что то генерировал

тут еще такой камень о который можно споткнуться - может быть авторизация на нескольких устройствах и синхронизация данных

к анонимным никакой, они ползают по обычным гет запросам до тех пор пока не понадобится что то сохранить (заказ, избранное итп). в этот момент уже требуется авторизация, через соцсеть

хранить там ничего не нужно. кроме гугл мапс ключа )

когда я предложил этот вариант мне тоже сказали что это не айс. ключи не надо передавать по сети, только данные )

очень плохие тесты, куча решений "в лоб" вроде репозиториев и длинны токена, вызывают вопроса роли, слишком много делают контроллеры, сущности вообще без поведения, такое

все ломается так или иначе

все ломается так или иначе

и для этого пересобирать приложение и выкладывать... а можно просто на сервере ключ заменить

кто потерял аккаунт?

тот кто на нем заводит приложение

если клиент - зачем пересобирать аппку?

при каждом чихе

выпускаешь новую версию в аппке показываешь алерт с каминаутом

это плохо влияет на юзер экспириенс

стоит взглянуть шире

если ты перегенеришь ключ - разве у тебя не вылогенит всех пользователей7

через месяц когда апкой уже начали пользоваться надо было сменить процентные ставки

так может и приложение вынести в веб?))

и причем тут ключи?

при том чтобы хранить ключи доступа к апишкам на сервере )

стой, еще раз - что за процентные ставки и как они соотносятся с ключами?

гибкости больше если придется что то поменять