Вы что тут делаете? Телеграм заблокирован же!

все ок) https://xakep.ru/2016/01/28/tor-and-vpn-is-ok-yet/

Нет, сикрет вшивается в приложение, это как идентификатор клиента, например моб приложение имеет один сикрет, десктоп приложение другой

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

Вы что тут делаете? Телеграм заблокирован же!

У меня что то с прокси большие трудности с работой телеги, особенно на мобильной сети.

достанут как ? через рут и доступ к фс?

Я погуглил. И вроде это можно сделать используя "template". Но может есть вариант попроще?

Нет

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

Такс, а как тогда мне сделать моё апи приватным? Ну т.е что бы к нему могли достучаться только допустим написанные мною приложения?

расскажу как я сделал, точнее вот сейчас андроид переделываю на эту схему

Думал oauth как раз то что надо

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

не могу сказать что это проще сильно

но да, захотят достанут)

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

так ведь кто достанет то? владелец телефона или левый софт?

Думал oauth как раз то что надо

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

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

владельцу телефона ты итак дал доступ пусть достает че хочет

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

а в чем "приватность"?

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

все ок) https://xakep.ru/2016/01/28/tor-and-vpn-is-ok-yet/

Это временно :)

аксес действует 15 минут. потом надо обновлять

Это временно :)

наверное надо банить за разведение хайпа

Ок. Молчу.

а в чем "приватность"?

в противоположности публичности

аксес действует 15 минут. потом надо обновлять

он другую проблему решает - как сделать так что только ТВОИ клиенты могут пользоваться ТВОЕЙ API

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

то есть я возьму рефреш токен и буду с ним обновлять без телефона?

и все у кого он есть?)

все ок) https://xakep.ru/2016/01/28/tor-and-vpn-is-ok-yet/

ксакеп еще живой

то есть я возьму рефреш токен и буду с ним обновлять без телефона?

я ж говорю - юзер делает релогин заново - и получает новый рефреш. старый становится невалидным и по нему нельзя работать

он другую проблему решает - как сделать так что только ТВОИ клиенты могут пользоваться ТВОЕЙ API

Да, и только мои, что бы какой то условный Петя не писал свой клиент под моё апи с блэкджеком и т.д

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

я ж говорю - юзер делает релогин заново - и получает новый рефреш. старый становится невалидным и по нему нельзя работать

релогин каждые 15 минут?

бляяяяя

Да, и только мои, что бы какой то условный Петя не писал свой клиент под моё апи с блэкджеком и т.д

короч низя. Никак. МОжно просто сделать процесс "доступа к API" сложным но всегда можно будет все узнать и все посмотреть

релогин каждые 15 минут?

почитай как рефреш токены работают

ну увели у меня рефреш я не делал релогин

им пользуются, вверно?

могут ага

рефреш нужен чтобы каждый божий день не просить юзера логиниться

в то же время сам рефреш токен не является логином паролем

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

короч низя. Никак. МОжно просто сделать процесс "доступа к API" сложным но всегда можно будет все узнать и все посмотреть

Блин, ну это лажово я конечно усложнил своё приложение oauth сервером а профита получается 0

да захотят взломать - взломают ) вся "приватность" только в том что к тебе боты не смогут просто так пробиться (без получения какого нибудь токена) чтобы парсить инфу на изичах

Блин, ну это лажово я конечно усложнил своё приложение oauth сервером а профита получается 0

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

если у тебя нет "третьих лиц" - то оно тебе не надо

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

или "войти через" есть функционал

или там в купе с SSO каким

ну или там тебе надо из active directory или из ldap поддержку мутить и ты можешь сверзу oauth заюзать

как абстракцию

но я не шарю а потому может кто подскажет реальные юзкейсы где oauth золото)

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

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

и даешь доступ к своим ресурсам не храня ничьи конфиденциальные данные

Хорошо, допустим я этим не буду париться но хочу оставить аццесс токены - мне теперь в ручную это делать если за меня их оаутх сервер не делает? Т.е писать сервис который будет генерить, проверять и выдавать ацесс токены + рефреш токены?

есть бандл который делает это за тебя )))

даже два

jwt?)

для работы с аксес токенам - lexik jwt. для рефреша - jwt refresh bundle который как надстройка над lexik

можешь свой написать если не подходит решение

рефреш токены там вообще легкая надстройка - просто хранится отдельная табличка между user-id <-> refresh token, и следит по expire time

jwt для кодирования использует openssh ключи

которые ты на машине сгенеришь

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

хаха

с этого и надо было начинать! )

Короче, у меня около 40 контроллеров. Явно просится всё это выделение в бандлы. Но учитывая последние изменения в SF4, возникает вопрос - а надо ли оно? Пихать в микросервисы - на данным этапе лишнее. А оставлять всё как есть тоже не хочется

ERROR: S client not available

Короче, у меня около 40 контроллеров. Явно просится всё это выделение в бандлы. Но учитывая последние изменения в SF4, возникает вопрос - а надо ли оно? Пихать в микросервисы - на данным этапе лишнее. А оставлять всё как есть тоже не хочется

не в бандлы а просто в нэймспейсы

тебе не нужны бандлы, каждый со своей конфигурацией и прочими штуками. Тебе нужны просто папочки с файликами

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

нафиг тебе JWT)

openssl rand -hex 32

тебе не нужны бандлы, каждый со своей конфигурацией и прочими штуками. Тебе нужны просто папочки с файликами

ага. остается вопрос по структуре. будет такой же как и в бандлах

ага. остается вопрос по структуре. будет такой же как и в бандлах

я хз какая у тебя структура в бандле но у меня скорее всего будет по другому)

https://gist.github.com/fesor/76d39b19b18f7103a7c058301dc6a8fe

но конечно же тебе решать что у тебя и как

у jwt есть плюшки - при наличии нескольких провайдеров юзеров он сам находит какой конкретно из них стучится с ключом. т.е. в контроллере получаешь UserInterface $user уже корректный

нафиг тебе JWT)

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

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

а ты понимаешь последствия использования JWT?)

а ты понимаешь последствия использования JWT?)

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

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

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

https://coub.com/view/161kpq

когда отказался от jwt

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

*аутентификацией

*аутентификацией

да да

я хз какая у тебя структура в бандле но у меня скорее всего будет по другому)

Action... А не проще стандарно Controller назвать? Если часть названий была до этого - стоит этому и следовать

аутентификацией

Action... А не проще стандарно Controller назвать? Если часть названий была до этого - стоит этому и следовать

ай делай что хочешь)

так что там про jwt?

мне тоже интересно прост, что с ним не так

так что там про jwt?

JWT решает одну единственную проблему - стандартизация HAMC. ДАльше вопрос - а нужен ли тебе HMAC?)

как ты будешь решать вопрос инвалидации сессии?

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

На сколько времени? Как обновлять?

как ты будешь решать вопрос инвалидации сессии?

сессия != jwt

Что делать при авторизации с разных устройств?

аутентификации

а у токена есть много критериев

сессия != jwt

да но тут люди для сессий его хотят юзать)

в том числе и подпись с помощью последовательности буковок

да но тут люди для сессий его хотят юзать)

ооо....