А не. Я еще нмного обдумал тему. Код в XSS мжет сделать то же самое, что делает сервис воркер при запросе refresh token. Получит новый рефреш токен, и по нему получит новый access token. Вывод: сервис воркер не нужен
Не совсем. Угнанный access token дает Бобу возможность отправлять запросы на некий сторонний сервис (который выдал рефреш токен). Но по нему нельзя получить новый access token от нашего собственного сервера, который хранит refresh token. Для доступа к нашему бэку используем обычную сессионную куку.
Другой вариант - refresh token в Http-Only cookie. В принципе, то же самое, только в профиль.
Не уверен, насколько часто необходимость защитить именно короткоживущий access token оправдывает возросшую сложность по поддержке сервис воркера. Но, наверное, иногда пригодится.
Что значит "вынесено за рамки клиента"? Мне казалось, вся статья (кроме пункта с прокси, который чит сам по себе :) ) про то, что клиент в явном виде получает и использует токен. Если не получает и не использует, то и проблемы нет никакой.
Нет ни малейшего резона как-то прятать токен на стороне клиента, если при этом клиентский код (а значит, и XSS) все так же способен запросить этот токен заново.
Если допустили XSS, то мы уже прилыли.
Если по какой-то причине мы хотим обезопаситься именно от использования этого токена злоумышлеником с другого компьютера, то можно привязать токен к айпи-адресу клиента или еще какому-то фингерпринту (это если мы этот токен сами контролируем/выдаем, конечно).
Поддержу @gandjustas, который не зря дописал "в основном не надо".
В вашем примере с упавшей базой, обработку исключения будет выполнять фреймворк. При ошибке вернет 500, залогирует, вызовет ваш кастомный обработчик, если надо что-то еще сделать.
В Союзе ряд товаров был недоступен. И человеек "на базе" мог достать то, что другими способами достать было невозможно или очень затратно. Достать для себя лично или для других - что делало его важным человеком.
Да, бывают ситуации, когда это нужно. Но приведенный в статье пример с конфигом, скорее, нужно решать другим способом, вне гита. Например, поддерживать слияние нескольких конфигов (один общий в репозитории, другой локальный у каждого разработчика в .gitignore содержит только измененные настройки). Или переопределять конфиг переменными окружения. Чтобы не приходилось выполнять все эти гит-команды в произвольные моменты работы над проектом.
Судя по документации, да даже и по примерам в этой статье, Akita как-то принциально не отличается от NgRx. Буду благодарен, если вы поделитесь опытом из первых рук :).
loadSuccess$ - это вы сильно упростили. Все равно же нужно состояние, а не событие (допустим, чтобы показывать/скрывать спиннер в шаблоне). Таким образом, это превратится во что-то типа
Что довольно-таки до фига кода, когда задача была "избавиться от бойлерплейта".
Кроме того, так компонент больше завязан на детали эффекта. Возможно, вам в этом случае вообще не нужен эффект? Фетчим данные прямо из компонента, затем диспатчим результат в стор.
Да, модифицировать вложенные структуры - боль. Я тоже старюсь придерживаться плоского стейта по возможности. Если это частый случай, то что-то вроде https://immerjs.github.io/immer/ должно помочь сделать это более читаемым.
Если речь про вложенные редьюсеры - то почему это плохо? Если же все делается одним редьюсером, то это в копилку предыдущего пункта про вложенные изменения.
Эта же логика справедлива для любых сайд эффектов. не только редиректа, разве нет? Отписываемся, где надо. Согласен, что в случае именно с редиректом эффект для пользоваля более заметен, чем когда мы, скажем, просто продолжаем загружать данные в фоне и запихивать в стор, хотя юзер уже ушел на другую страницу.
Набор рекомендий довольно странный и даже спорный. Аргументации не хватает, опять же.
Рекомендация не хранить состояние в системе, предназначенной для управления состоянием. Ну, такое. Кроме того - если у нас асинхронный код (загрузка данных) в эффекте, то каким еще образом компоненту узнать о состоянии это загрузки.
Ок
Изменение вложенных объектов - к каким проблемам с отслеживанием изменений это приводит? Мы же, конечно, не говорим про прямую мутацию объектов в стейте (`state.a = newValue`), что нарушает основное правило редьюсера?
Не очень понятно, о чем речь. С примером было бы лучше :)
А что за проблемы с редиректом в эффекте? И где тогда делать редирект?
id в fetch - звучит как очень специфический рецепт для специфической задачи. Например, в подавляющем большинстве наших задач switchMap в эффекте отлично справляется с отменой, никаких айди не надо.
Для SSR надо быть осторожней не только с интервалам, но и таймаутами. И не только в эффектах, а вообще во всем приложении. Ничего redux-специфичного тут нет. А помимо части про SSR, рекомендация звучит как "не использовать интервал, потому что он генерит длинную последовательность событий". Как бы его используют исключильно тогда, когда нам нужно сгенерить такую последовательность. Опять же, неважно эффект это или нет.
Совет использовать груви-код был в контексте использования плагинов, которые тоже на груви и тоже будут выполняться на мастер ноде. Разница здесь между чужим глючным груви кодом (плагин) и своим глючным груви кодом (в котором проще копаться и починить)
Ездил как-то зимой на лыжах с горы покататься. Наверху, на горе, можно арендовать шкафчики для личных вещей - оплата кредиткой через встроенный терминал. Интернет на гору, видимо, завозят только весной. В общем, эта транзакция у меня в выписке только через месяц нарисовалась.
А, точно. Я почему-то только про залогиненных думал. С незалогиненными - согласен.
Насколько я понимаю, применение SXG не только в рамках AMP. Это более общая технология, которая позволяет безопасно делать предзагрузку и показ сторонних ресурсов. Имхо если кто-то хотел делать на своем сайте AMP, он это делал и без SXG. И наоборот - непохоже, что SXG сделает именно сайты с AMP настолько лучше остальных, что надо будет всем внедрять у себя AMP.
Про Manifest v3. Тут речь не о манифесте как таковом (хотя у него достаточно и своих собственных проблем - особенно с service workers), а о том, что Chrome выпиливает важный набор api, который позволял расширениям фильтровать запросы. Firefox, при том, что он тоже переходит на MV3, заявил, что продолжит поддерживать эти api, "пока не появится более хорошее решение для этих задач". https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/
Про First Party Sets Речь про объединение группы сайтов, принадлежащих одному владельцу. В таких случаях у владельца уже и так есть технические возможности обмениваться пользовательскими данными между сайтами, делать сквозной логин / трекинг. С новой технологией можно будет сделать все это самое с меньшими костылями.
Про SXG Не очень понятно, как это навредит приватности и позволит Гуглу больше следить. Суть этой технологии в подписи (signature), которая гарантирует, что оригинальный контент сайта не изменен. Это значит, что никаких новых трекеров от Гугла в этом контенте не появится (если их там не было изначально).
Ну дык. На своем (same site) сервере, конечно не нужны токены. Авторизуемся по HttpOnly куке. Необязательно короткоживущей (даже и вредно, пожалуй).
А токены используем для работы со сторонними серверами.
Алиса его продляет, аутентифицируясь на нашем беке по собственной сессионной куке. Которую не угонишь.
А не. Я еще нмного обдумал тему. Код в XSS мжет сделать то же самое, что делает сервис воркер при запросе refresh token. Получит новый рефреш токен, и по нему получит новый access token. Вывод: сервис воркер не нужен
Не совсем. Угнанный access token дает Бобу возможность отправлять запросы на некий сторонний сервис (который выдал рефреш токен). Но по нему нельзя получить новый access token от нашего собственного сервера, который хранит refresh token. Для доступа к нашему бэку используем обычную сессионную куку.
Другой вариант - refresh token в Http-Only cookie. В принципе, то же самое, только в профиль.
Ага.
Да, вариант с сервис воркером остроумный.
Не уверен, насколько часто необходимость защитить именно короткоживущий access token оправдывает возросшую сложность по поддержке сервис воркера. Но, наверное, иногда пригодится.
Что значит "вынесено за рамки клиента"? Мне казалось, вся статья (кроме пункта с прокси, который чит сам по себе :) ) про то, что клиент в явном виде получает и использует токен. Если не получает и не использует, то и проблемы нет никакой.
Токены и куки используются в разных сценариях. Токен для запросов к 3rd party доменам. Куки же first party, same site.
Нет ни малейшего резона как-то прятать токен на стороне клиента, если при этом клиентский код (а значит, и XSS) все так же способен запросить этот токен заново.
Если допустили XSS, то мы уже прилыли.
Если по какой-то причине мы хотим обезопаситься именно от использования этого токена злоумышлеником с другого компьютера, то можно привязать токен к айпи-адресу клиента или еще какому-то фингерпринту (это если мы этот токен сами контролируем/выдаем, конечно).
Поддержу @gandjustas, который не зря дописал "в основном не надо".
В вашем примере с упавшей базой, обработку исключения будет выполнять фреймворк. При ошибке вернет 500, залогирует, вызовет ваш кастомный обработчик, если надо что-то еще сделать.
Код же приложения этим заниматься не должен.
Не (только) в воровстве дело.
В Союзе ряд товаров был недоступен. И человеек "на базе" мог достать то, что другими способами достать было невозможно или очень затратно. Достать для себя лично или для других - что делало его важным человеком.
Да, бывают ситуации, когда это нужно. Но приведенный в статье пример с конфигом, скорее, нужно решать другим способом, вне гита. Например, поддерживать слияние нескольких конфигов (один общий в репозитории, другой локальный у каждого разработчика в .gitignore содержит только измененные настройки). Или переопределять конфиг переменными окружения. Чтобы не приходилось выполнять все эти гит-команды в произвольные моменты работы над проектом.
Если флаг загрузки в state, то в комоненте async pipe. Вручную никто подписку не делает, когда у нас есть реактивный стейт
Судя по документации, да даже и по примерам в этой статье, Akita как-то принциально не отличается от NgRx. Буду благодарен, если вы поделитесь опытом из первых рук :).
loadSuccess$- это вы сильно упростили. Все равно же нужно состояние, а не событие (допустим, чтобы показывать/скрывать спиннер в шаблоне). Таким образом, это превратится во что-то типаЧто довольно-таки до фига кода, когда задача была "избавиться от бойлерплейта".
Кроме того, так компонент больше завязан на детали эффекта. Возможно, вам в этом случае вообще не нужен эффект? Фетчим данные прямо из компонента, затем диспатчим результат в стор.
Да, модифицировать вложенные структуры - боль. Я тоже старюсь придерживаться плоского стейта по возможности. Если это частый случай, то что-то вроде https://immerjs.github.io/immer/ должно помочь сделать это более читаемым.
Если речь про вложенные редьюсеры - то почему это плохо? Если же все делается одним редьюсером, то это в копилку предыдущего пункта про вложенные изменения.
Эта же логика справедлива для любых сайд эффектов. не только редиректа, разве нет? Отписываемся, где надо. Согласен, что в случае именно с редиректом эффект для пользоваля более заметен, чем когда мы, скажем, просто продолжаем загружать данные в фоне и запихивать в стор, хотя юзер уже ушел на другую страницу.
Набор рекомендий довольно странный и даже спорный. Аргументации не хватает, опять же.
Рекомендация не хранить состояние в системе, предназначенной для управления состоянием. Ну, такое. Кроме того - если у нас асинхронный код (загрузка данных) в эффекте, то каким еще образом компоненту узнать о состоянии это загрузки.
Ок
Изменение вложенных объектов - к каким проблемам с отслеживанием изменений это приводит? Мы же, конечно, не говорим про прямую мутацию объектов в стейте (`state.a = newValue`), что нарушает основное правило редьюсера?
Не очень понятно, о чем речь. С примером было бы лучше :)
А что за проблемы с редиректом в эффекте? И где тогда делать редирект?
idв fetch - звучит как очень специфический рецепт для специфической задачи. Например, в подавляющем большинстве наших задач switchMap в эффекте отлично справляется с отменой, никаких айди не надо.Для SSR надо быть осторожней не только с интервалам, но и таймаутами. И не только в эффектах, а вообще во всем приложении. Ничего redux-специфичного тут нет. А помимо части про SSR, рекомендация звучит как "не использовать интервал, потому что он генерит длинную последовательность событий". Как бы его используют исключильно тогда, когда нам нужно сгенерить такую последовательность. Опять же, неважно эффект это или нет.
Законами де Моргана можно ограничиться. Чтобы многоэтажные if-ы не лепили.
Совет использовать груви-код был в контексте использования плагинов, которые тоже на груви и тоже будут выполняться на мастер ноде. Разница здесь между чужим глючным груви кодом (плагин) и своим глючным груви кодом (в котором проще копаться и починить)
Вот да!
Ездил как-то зимой на лыжах с горы покататься. Наверху, на горе, можно арендовать шкафчики для личных вещей - оплата кредиткой через встроенный терминал. Интернет на гору, видимо, завозят только весной. В общем, эта транзакция у меня в выписке только через месяц нарисовалась.
А, точно. Я почему-то только про залогиненных думал. С незалогиненными - согласен.
Насколько я понимаю, применение SXG не только в рамках AMP. Это более общая технология, которая позволяет безопасно делать предзагрузку и показ сторонних ресурсов. Имхо если кто-то хотел делать на своем сайте AMP, он это делал и без SXG. И наоборот - непохоже, что SXG сделает именно сайты с AMP настолько лучше остальных, что надо будет всем внедрять у себя AMP.
Про Manifest v3.
Тут речь не о манифесте как таковом (хотя у него достаточно и своих собственных проблем - особенно с service workers), а о том, что Chrome выпиливает важный набор api, который позволял расширениям фильтровать запросы. Firefox, при том, что он тоже переходит на MV3, заявил, что продолжит поддерживать эти api, "пока не появится более хорошее решение для этих задач". https://blog.mozilla.org/addons/2021/05/27/manifest-v3-update/
Про First Party Sets
Речь про объединение группы сайтов, принадлежащих одному владельцу. В таких случаях у владельца уже и так есть технические возможности обмениваться пользовательскими данными между сайтами, делать сквозной логин / трекинг. С новой технологией можно будет сделать все это самое с меньшими костылями.
Про SXG
Не очень понятно, как это навредит приватности и позволит Гуглу больше следить. Суть этой технологии в подписи (signature), которая гарантирует, что оригинальный контент сайта не изменен. Это значит, что никаких новых трекеров от Гугла в этом контенте не появится (если их там не было изначально).