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

калькулятор страховки епте

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

изменения ключа - это крайне редкое явление

изменение конфигурации - это лучше пусть с сервера

а ключ не часть конфигурации?

it depends. для некоторых вещей тебе просто придется отдать ключ на клиент

для специфичных фич facebook sdk например

(не уверен правда что они такие есть))

сеть это ж риск man in the middle и если есть секюрное хранилище че им пренебрегать

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

смотря какой ключ конечно

а ключ не часть конфигурации?

ну и опять же - есть SDK которые не интегрируются с сервером и ты сделать ничего не сможешь

и там тебе придется хранить ключ на клиенте

ну, те соцсети которые нужны все поддерживают неявную авторизацию

т.е. через сервер

ну, те соцсети которые нужны все поддерживают неявную авторизацию

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

так у меня и сейчас на клиенте они хранятся

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

прост хотел по человечески переделать

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

есть авторизация через вк, после нее выдается jwt токен, который мы на клиенте кладем в http only cookie или localstorage и ставим в заголовки запросов к апишке потом... выходит по скрину это плохой вариант, и че как жить?)

просто потому что в варианте с хранением ключа и работой с SDK на мобилке реализация какого-нибудь facebook login занимает пару часов с обеих сторон.

есть авторизация через вк, после нее выдается jwt токен, который мы на клиенте кладем в http only cookie или localstorage и ставим в заголовки запросов к апишке потом... выходит по скрину это плохой вариант, и че как жить?)

кто выдает jwt токен?

мое приложение, апишка моя

ну короч по jwt для сессий - смотри картинку внимательно)

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

действие, короткоживущий токен... сделал и все.

мельком глянул про жвт еще в пятницу

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

и ему не надо ни к кому ходить

low coupling

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

из минусов - длюннющий аксес токен

из минусов - длюннющий аксес токен

это вообще не минус

)))))))))

повторюсь - не надо просто его для сессий юзать

вот я описал кейс.... одноразовый токен. воспользовался один раз и хватит

выходит для сессий - пхп-сессии?)

выходит для сессий - пхп-сессии?)

почему бы и нет)

есть еще такая фигня - плавающая сессия

краем левого глаза заметил

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

там тоже участвуют два токена - access+refresh

там тоже участвуют два токена - access+refresh

посмотри на картинку, ты переизобрел сессии

да нет я не переизобрел

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

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

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

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

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

формат данных

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

ну в итоге если переизобрести сессии с jwt то там приходим к блоку что это мало протестированное решение, так ли это ?)

ну в итоге если переизобрести сессии с jwt то там приходим к блоку что это мало протестированное решение, так ли это ?)

ну у каждого ж свой велосипед)

в этом проблема)

главное что бы в качестве рефреша не юзалось sha1(uniqueid('', true))

много разного люди выдумывают

да още пздц

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

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

начни с того что пятница а это значит надо бухать

не я так то немного приврал, я вообще не пью. пиво лет 6 наверно, а хороший алкоголь уже месяца 4

начни с того что пятница а это значит надо бухать

или на концерт сходить - мозги разгружает знатно, вчера проверил

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

ERROR: S client not available

хотя да какой то тупой вопрос был, сорян )

ну в андроидах сессии на жвт это ж стандарт

заголовок в стиле бугаенко прост)

а ну там в андроидах походу и oauth2 как протокол и sdk к этому всему есть, а не jwt как формат токена и свои костыли

Caution: Neither JWT nor Paseto were designed for stateless session management. Paseto is suitable for tamper-proof cookies, but cannot prevent replay attacks by itself.

кайф)

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

Зачем ?) пусть себе работает ))))

ну я щя представил как я эти токены рефрешить буду и сессию изобретать

хотя у меня есть вероятность что будут сторонние приложеньки к апишке и им бы можно было выдавать токены, да и auth0 прям на слабо берут)) : This is exactly the same thing cookies will do, with the difference that you have the additional benefit that this is now a conscious decision, you have full control, and is part of your code.

ща читну тред и статью)

а то я не могу понять что вы тут изобретаете)

там спутник должен упасть на землю и не известно куда, так что всем удачи))

#Tiangong1

вроде наши широты не зацепит

Наши?)

назапускают этих спутников а потом не могут остановить)))

@fes0r @Enleur такая проблема и скорее даже вопрос про экспириенс с кубером: Я запускаю куб локально на docker-for mac (1 нода). Есть 2 неймспейса staging-n, prod-n. + default. На каждый неймспейс по ингрес обьекту. Ингрес контроллер в default пространстве. ---- Трафик не уходит дальше ингрес контроллера, потому что не работает сервис дискавери (по dns именам и ip). логинюсь в любой под в любом пространстве и пытаюсь пингануть сервис со своего пространства или с чужого по имени service-name.namespace-name или по айпи - Connection refused. Nslookup показывает что имя замапилось на айпи, но вот айпи недоступен. Под доступен напрямую через его айпи (kub describe pod name -> IP) ---- Работает ли это у вас ? я прогуглил ишьюсы, есть похожие, но там 50/50. у одних работает - у других нет. Говорят проблема в том что все на 1 ноде

то есть если я бы просто настраивал nginx то proxy_pass http:service-name.namespace-name не сработало бы

upd: сервисы пингуются в разрезе default пространства. под из default пингует сервис в default. все ок тут, а вот под в staging-n не может пингануть сервис в staging-n например ?

крч пошел закапываться в ишьюсы и дебаг

почему группу не переименовали в какой нить CackePhp или Codeigniter?

1 апреля типо

Изи

надо было небанальщину, синатру какую-нибудь)

Все чаты переименовываются в конкурентов прямых

Ооп в вязание, пых в хаскель

Симфони вот в рельсы

Чё там pjax из коробки?