AS
Типа делаешь запрос на BFF с помощью токена X, чтобы получить токен X+1 на следующие пару часов?
Size: a a a
2020 November 23
PM
Странно тогда брать CSS Modules. Если хочется удобство, проще выключить изоляцию селекторов вообще и фигачить БЭМ разрешая расширять блоки
проблема с margin почти полностью выдуманная. решений полно, начиная от прокидывания аттрибута style с нужными margin, заказчивая условно-глобальными стилями, с помощью которых можно при большом желании вообще пропатчить что угодно в ребенке:
.parent > :global(.child) {} => .parent.svelte-xyz > .child {}AS
Или просто
.parent > :global(*) — с помощью global явно указываешь выход за пределы изоляцииPM
Типа делаешь запрос на BFF с помощью токена X, чтобы получить токен X+1 на следующие пару часов?
обычно в 3-х звенных схемах с BFF токены нужны для доступа к бекенду, который не BFF. собственно запросы к апи BFF фактически проксирует и может выступать в роле интесептора, если видит что токе протух, может незримо для клиента осуществить процедуру рефреша и повторить запрос
PM
у нас так вообще чаще всего 2-токена используются для авторизации на беке, а между клиентом и BFF идет обычная сессия
PM
в данных которой на BFF лежат токены
AS
обычно в 3-х звенных схемах с BFF токены нужны для доступа к бекенду, который не BFF. собственно запросы к апи BFF фактически проксирует и может выступать в роле интесептора, если видит что токе протух, может незримо для клиента осуществить процедуру рефреша и повторить запрос
А зачем такая сложность? От какой атаки она защищает?
От XSS видно что не помогает
От XSS видно что не помогает
AS
Просто крадёшь временный токен, а BFF всё равно его так же обновит
PM
А зачем такая сложность? От какой атаки она защищает?
От XSS видно что не помогает
От XSS видно что не помогает
сложность в 2-х авторизциях или вообще в наличии BFF?
AS
сложность в 2-х авторизциях или вообще в наличии BFF?
В наличии двух токенов
AS
И механизме протухания
PM
В наличии двух токенов
2 токена нужны чтобы лишний раз не авторизовываться на бекенде же
PM
просто бекенд напрямую юзают еще мобилки
AS
2 токена нужны чтобы лишний раз не авторизовываться на бекенде же
А зачем? Почему не хранить долгоживущий токен сразу на клиенте?
PM
но если мобильные приложения условно можно считать “доверенными”, но фронтенд нет. в данном случае BFF выстапает в качестве доверенного источника
PM
А зачем? Почему не хранить долгоживущий токен сразу на клиенте?
бекенд отдельно настраивает сколько времени живет токен. эти правила действуют для всех клиентов (веб, мобилки, смарт тв)
PM
на веб, с помощью BFF мы вообще скрываем от фронтенда эту сложность + можем регулировать время сессии отдельно.
PM
хранить долгоиграющий токен на фронте имхо не очень безопастно, еще менее безопасно хранить там рефреш, в любом виде
PM
А зачем такая сложность? От какой атаки она защищает?
От XSS видно что не помогает
От XSS видно что не помогает
от XSS и вообще всех клиентских атак на BFF идет отдельная защита. собственно это одна из главных его целей
PM
цели BFF: SSR, клиентские атаки, авторизация, форматирование/агрегация запросов под нужды фронтенда, кэширование данных.