думай дальше)

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

p.s. подсказка - у тебя есть jsonb и прочие штуки

ну у меня мускуль )

mysql 5.7 умеет в json

или ты еще на 5.6 сидишь?

Ну да в 2-м кейсе, историю можно хранить в виде сериализированого массива

или ты еще на 5.6 сидишь?

Пока 5.6

Ну да в 2-м кейсе, историю можно хранить в виде сериализированого массива

по факту не важно как хранить, выборки по этим данным ты делать всеравно не будешь

в mysql 5.6 у тебя там будет просто TEXT

Угу. Но в 1 юскейсе так не получится )

Либо хардкодом в энтитю забить ))))

да, тут нужно либо имплементацию сущности подменять либо думать как можно вынести проверку пароля во вне

ну я просто тебе накидываю) что бы не так скучно было)

Да у меня тут и так накинуто, не могу придумать ) Как мне сделать так что б пароли хешировались, а токены нет, и что б в одной табличке )

ну вывод - разделить модель поведения и модель данных)

(но не сервисы менеджеры)

а еще - возможно в этом бандле не юзать ORM)

Я хотел скрестить ежа с ужом ) и окрамиуса и твою идею ) А оно не идет )

а еще - возможно в этом бандле не юзать ORM)

Тупо массив? )

хм ... вариант с password_needs_rehash в конструкторе решило бы проблему, но тогда энкодер будет зашит в сущность. И тогда теряется гибкость )

да, тут нужно либо имплементацию сущности подменять либо думать как можно вынести проверку пароля во вне

А есть законные методы для этого?

хм ... вариант с password_needs_rehash в конструкторе решило бы проблему, но тогда энкодер будет зашит в сущность. И тогда теряется гибкость )

в конструкторе?

эт как?

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

а что внутри - не столь важно уже

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

Ну типа public function __construct(string $identity,string $secret, $type, $isSecured=true) isSecured укажед нужно ли хешировать

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

Ну типа public function __construct(string $identity,string $secret, $type, $isSecured=true) isSecured укажед нужно ли хешировать

ммм.... непонятно

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

Ну я пока отдельно бандл не делаю, я делаю живой проджект. А потом наработки хочу вынести в бандл, если будет красиво

Ну я пока отдельно бандл не делаю, я делаю живой проджект. А потом наработки хочу вынести в бандл, если будет красиво

а, не, либо живой проект либо бандл

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

все будет просто прибито гвоздями

а, не, либо живой проект либо бандл

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

а что бы "гибко" - живому проекту это не надо)

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

не стоит... лучше пару раз попробовать заимплементить по разному

а потом уже сделать выводы и запилить с нуля но реюзабельно

а так ты только время потратишь и гибкости не получится

Ну я хоть основу сделаю, что б правильно было, а в след раз или перепишу или допилю )

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

Идею увидел у symfony-*-bridge

а зачем хранить токены?

это те которые ты выдаёшь в обмен на успешную oauth2?

Привет, сейчас делаю аутентификацию и регистрацию через апи на симфони 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 недели условно (в зависимости от настроен токена), как можно этого избежать? Выдавать токены на год? Пока на этом всё, буду благодарен за любые ответы

это те которые ты выдаёшь в обмен на успешную oauth2?

Нет, которые получаю

Привет, сейчас делаю аутентификацию и регистрацию через апи на симфони 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 недели условно (в зависимости от настроен токена), как можно этого избежать? Выдавать токены на год? Пока на этом всё, буду благодарен за любые ответы

Зачем тебе сессия в api?

Зачем тебе сессия в api?

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

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

Можно не выставлять время жизни токена вообще

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

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

Врямя жизни нужно, чтобы если токен спиздили

то им нельзя было долго пользоваться

Ну в этом случае токен надо выдавать максимум на пару минут, потому что иначе его можно спиздить и даже за час уже наломать дров

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

да

челик вводит логин пароль

даешь ему токен на полчаса

если ему приходит ошибка аутинфикации( токен устарел например)

он шлет его еще раз

он шлет его еще раз

Его? Или опять логин и пароль?

Его? Или опять логин и пароль?

логин и пароль

Вот я не хочу что бы юзер вводил логин и пароль каждые пол часа

интересный метод

Вот я не хочу что бы юзер вводил логин и пароль каждые пол часа

ну и все, убирай время жизни

интересный метод

Он работает только если stateless: false т.е на пхп сессиях

ну и все, убирай время жизни

Ну а как тогда юзера защитить?

Ну а как тогда юзера защитить?

Никак лол

ERROR: S client not available

Себя надо защищать

а не юзера

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

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

Зато на каждом новом устройстве вводишь

Зато на каждом новом устройстве вводишь

Хочу так же сделать для своих юзеров, что почитать?

Хочу так же сделать для своих юзеров, что почитать?

хз) я думаю там по мак адресу и айпишнику новое устройство опознавать можно

хз) я думаю там по мак адресу и айпишнику новое устройство опознавать можно

Всё сводится к либо юзай Oauth2 либо jwt, а как обойтись без этого и при этом защитить юзеров - хз :( ладно, спасибо, буду думать дальше

Да никак ты юзеров не защитишь

Почему то я тебе не верю)

Либо вводить refresh token как в oauth

https + если в локалсторадже хранишь то защищаться от xss, если в куках то от csrf/xsrf аттак, и кнопочка выйти на всех устройствах

Вот я не хочу что бы юзер вводил логин и пароль каждые пол часа

Refresh token же

Вообще перед тем, как всё делать, стоило почитать про oauth

oauth и jwt исполюзуются для разных задач

И посмотреть вот сюда https://github.com/thephpleague/oauth2-server

Refresh token же

http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.png

Да я про jwt вообще молчал)

а зачем oauth ему?

а зачем oauth ему?

вот я никогда не понимал людей которые рекомендую oauth там где нет "третьей стороны"

клево конечно когда ты можешь замутить отдельный auth сервер

но зачем... для простого проекта - oauth....

Видимо потому что хочет) вопрос-то не «что выбрать»

Видимо потому что хочет) вопрос-то не «что выбрать»

кто хочет?

Автор вопроса

автор вопроса хочет аутентификацию для апишки, где-то увидел про oauth, где-то про jwt

не первый день он с этим вопросом

В итоге пилит все вместе

а че сразу бандла готового нет? )))

а че сразу бандла готового нет? )))

для oauth - есть бандл)

вроде.... ни разу не приходилось юзать

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

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