Мне кажется, вы с одной темы резко перескакиваете на другую. Ваша оценка деятельности и власти России субъективна, много людей во всём мире придерживаются иной точки зрения, диаметрально противоположной вашей. Да у вас есть право на собственное мнение и множество людей также придерживаются позиции, которую декларируете вы. Много, но не все, и даже не большинство.
Поэтому, это не истина в последней инстанции, и делать какие-то выводы из такой позиции абсолютно некорректно. Дискуссия в таком случае бессмысленна и приводит только к политическому срачу.
Мы говорим о фактах. А факты состоят в том, что не Россия уходит. Её выгоняют, исключают, отключают. Что это может значить для других стран? Очевидные риски. Не будем говорить кто виноват и почему. Важен сам факт.
Оба утверждения не верные. Mapster умеет генерировать код мапперов, работает оно точно также, как и написанный код вручную. Сокращает ли количество рутинного кода? Да. Тут больше ориентируются на принятые в проекте подходы, убеждения лида, и особенности маппинга. Если они по большей части сложные и кастомные, толку не будет. Если они в основном рутинные, перекладывание значений из полей, то профит есть и не малый, если DTO много.
Ну хорошо, кажется я понял о чём вы говорите. Предоставленный токен может иметь более широкую область действия, чем авторизация в одном конкретном бекенде.
Почему бы просто не зашифровать пару access/refresh и положить в HttpOnly? В таком виде токены нельзя будет использовать на других бекендах, а только в конкретном.
На всякий случай, принцип обсуждаемого механизма авторизации в том, что токен выдаётся клиенту. Он предназначен для клиента, как удостоверение, с которым клиент может посещать различные, доступные ему заведения. Вместо решения задачи защиты токена, получается, мы полностью меняем принцип. Поправьте меня, если я не прав.
И всё же. Как перенос хранения токенов в BFF защитят от отправки данных из вредоносного JS? Приложение ведь всё равно имеет авторизацию через куки, спокойно может извлекать доступные ему данные из бекенда.
Если речь про увод токена, так кто мешает обеспечить защиту с внедрением в Cookie так называемого anti-forgery токена? Т.е. дополнительно к выданному токену проверять секрет, который соответствующим образом зашифрован, согласован с токеном и нет необходимости хранить его на сервере.
Почему мы не можем просто изменить хранение access и refresh токенов в HttpOnly куках, если не доверяем фронтенду?
Я веду к тому, чтобы остаться в рамках stateless, и не деградировать систему до необходимости хранить состояние сессии на сервере.
Вредоносный JavaScript-код, который может быть внедрен в приложение различными способами, через атаки типа межсайтового скриптинга (XSS) или через компрометацию сторонних библиотек, получает такие же привилегии и уровень доступа к данным, как и легитимный код приложения. Это позволяет вредоносному коду красть данные из текущей страницы, взаимодействовать с интерфейсом приложения, отправлять запросы к backend, красть данные из локального хранилища (localStorage, IndexedDB), и даже самостоятельно инициировать сеансы аутентификации, получая с помощью того же потока Authorization Code и PKCE собственные токены доступа.
Допустим, в приложение внедрён вредоносный JS-код.
Каким образом авторизация в куки может помешать вредоносному коду делать запросы к бекенду? Запрос точно также будет авторизован, не по токену в заголовке, но по куки. Ему совершенно не нужно "красть" для этого токен. Более того, куки упрощают вредоносному коду жизнь, так как теперь не надо заботиться о правильной передаче авторизации в бекенд, пытаться извлекать токен из каких-то внутренних хранилищ, т.е. теперь просто можно делать запросы в бек и всё.
Каким образом вредоносный код может украсть данные, если он не может их никуда отправить, кроме того же бека, если конечно правильно настроены CORS?
Как обычно, ретраи, балансировка, репликация... Компенсирующие действия выполняются в ответ на невозможность корректно завершить транзакцию: денег не хватает, товар закончился, курьер заболел. Компенсация это обычная транзакция, которая стремится вернуть систему к исходному состоянию в конечном счёте. Здесь не так много общего с Rollback в СУБД.
Например, вы дали 10 тыс. рублей человеку за работу, а он заболел, и хочет вернуть вам средства. 5 тыщ. вернул на карту, 2 тыс. наличкой, а остальное на телефон. Т.е. вам вернулись 10 тыс. но не обязательно в том же виде. Но исходное состояние достигнуто, по бизнесу. Это и есть компенсирующие действия.
Я не так много кода на Go прям изучал, но то что из прикладухи видел похоже на 30-40% "мусора" в виде проверок err после чуть ли не каждой функции. Да ещё и обработка такая, как пыль протёр для видимости, чтоб мама не ругалась :)
По мне так огромная. Во-первых, производительность, так как любой лишний маршаллинг это затраты. Во-вторых, все разработчики могут в равной степени участвовать в развитии всей платформы, смотреть и понимать как она устроена, прикладной код это естественное бесшовное продолжение стека.
Ну и рамки применимости, есть определённые узкие задачи, под которую PHP заточен, и выходить за эти рамки тяжело, а без доп. инструментов попросту невозможно
Очевидно так! Это была ирония, ибо создавать миллионы Task для выполнения cpu-bound операций, даже писать такой код мучительно больно :) А в .NET таки есть экспериментально грин-треды, но производительность у них похуже async/await.
Да основной наверное профит в строгой типизации это рефакторинг. Зарефачить с массовыми изменениями в сотнях и тысячах файлах в строго типизированном ЯП как за здрасьте :) Разделение, объединение типов, вывод интерфейсов, разнесение по модулям, смена списка аргументов, типа возврата, вообще без страха и сомнений.
А в динамике страшно до усрачки что-то трогать лишний раз, по крайней мере мне было страшно :)
Фишка в том, что в пространстве программного кода на строго типизированном ЯП просто не обитает чисел в строках, массивов непонятной размерности или непонятного толка, не бывает массивов-словарей, потому что все намерения выражены явно, они читаются и понимаются явным образом. И дело уже не только в защите компилятора, типизация позволяет проводить перспективный анализ кода, выявляя ошибки даже при соблюдении типов, например, недостижимый код, сравнения которые никогда не будут работать, бесконечное зацикливание, работа с переменными, которые по алгоритму не изменяются, попытка работать с объектами, которых не существует (null). И всё это не означает, что надо писать больше лишнего кода, благодаря той же типизации, современные IDE позволяют предсказывать и предугадывать намерения разработчика, генерируя стандартные проверки на лету.
Все эти бонусы просто меркнут на фоне его величества Рефакторинга. Проводить рефакторинг в типизированных языках, это удовольствие. Любые косяки исправляешь в одном месте, они исправляются в тысячи мест сразу, и ты знаешь что ничего не сломается, так как везде всё явно и строго.
Никакой чёрнокнижной магии, не нужно в голове работать компилятором и думать, как оно там скастит, и что будет если? Всё супер-очевидно и не надо играть в игру: угадай как это сработает в рантайме?
Как человек, изрядно посидевший на проектах с динамикой и статической типизацией, скажу, строгая типизация действительно величайшее благо. И в PHP её затаскивают именно по этой причине, а не потому что "модно", как кому-то по наивности может показаться.
Насколько они не кроссплатформенные? Когда разрабатывал на C++, это было очень-очень давно, на Visual Studio, нормально всё было со стектрейсами. Неужели всё сломали?
Тут речь не про детали реализации, а скорее парадигма разработки. Очень хорошо, когда у исключения есть строгий базовый тип (как в C#, почти). Тут про такое понятие как отказ + возможность что с этим нормально сделать. Или восстановиться до изначального состояния, а не просто молча выплюнуть в консоль "что-то пошло не опять, а снова не так" + стектрейс. Много этим пользовался и на большие портянки кода на Go мне порой больно смотреть. Почти 30-40% это проверки err. Да ещё и часто просто в лог плюют ошибку и.. всё. И делать ещё это надо по месту. А пробрасывать err так вообще на грани преступления.
CPU-bound операции надо параллелить на физическое количество процессоров. Только тогда будет толк. Выше приводил пример, толк есть, более чем в 10 раз быстрее извращений с горутинами.
С позиции enterprise разработки, когда бизнес-объектная модель состоит из десятков тысяч типов и множества слоёв логики, отсутствие максимально строгой типизации превращается просто в ад. Вплоть до того, что даже для таких значений как ИНН, ОГРН и т.п. создаётся отдельный доменный тип, на которым уже навешаны: валидация, парсинг, сериализация, куча расширений и нельзя вот так какую-то рандомную строку сунуть как параметр функции, т.е. перепутать ИНН и ОГРН физически компилятор не даст. Если честно, за всю практику работы в типизированной среде мне крайне редко доводилось кастовать строку к числу, чтобы с чем-нибудь сложить. Зачем? Число в виде строки просто тупо не появится в границах приложения. И такие случаи возникают чаще именно в интеграции с динамическими ЯП, которые без всяких Б могут прислать число строкой, вообще не запариваясь ни разу. Разработчики, получая такие "подарки" очень радуются, ну наконец-то! Расчехляем адаптивную десериализацию, обмазываем аспектами.
Для небольших микро-сервисов, и тем более прослоек, тупо гоняющих данные между БД и фронтом, особо типизация и не нужна наверное. Или я очень уж пристрастился к типизации )
Тут просто нет никаких причин что-то на стороне BFF в принципе хранить.
Осталось начать прыгать под кричалки. Действуйте!
Мне кажется, вы с одной темы резко перескакиваете на другую. Ваша оценка деятельности и власти России субъективна, много людей во всём мире придерживаются иной точки зрения, диаметрально противоположной вашей. Да у вас есть право на собственное мнение и множество людей также придерживаются позиции, которую декларируете вы. Много, но не все, и даже не большинство.
Поэтому, это не истина в последней инстанции, и делать какие-то выводы из такой позиции абсолютно некорректно. Дискуссия в таком случае бессмысленна и приводит только к политическому срачу.
Мы говорим о фактах. А факты состоят в том, что не Россия уходит. Её выгоняют, исключают, отключают. Что это может значить для других стран? Очевидные риски. Не будем говорить кто виноват и почему. Важен сам факт.
Оба утверждения не верные. Mapster умеет генерировать код мапперов, работает оно точно также, как и написанный код вручную. Сокращает ли количество рутинного кода? Да. Тут больше ориентируются на принятые в проекте подходы, убеждения лида, и особенности маппинга. Если они по большей части сложные и кастомные, толку не будет. Если они в основном рутинные, перекладывание значений из полей, то профит есть и не малый, если DTO много.
Вы ещё спросите, а что там с Windows, который тоже как бы ушёл :)
Ну хорошо, кажется я понял о чём вы говорите. Предоставленный токен может иметь более широкую область действия, чем авторизация в одном конкретном бекенде.
Почему бы просто не зашифровать пару access/refresh и положить в HttpOnly? В таком виде токены нельзя будет использовать на других бекендах, а только в конкретном.
На всякий случай, принцип обсуждаемого механизма авторизации в том, что токен выдаётся клиенту. Он предназначен для клиента, как удостоверение, с которым клиент может посещать различные, доступные ему заведения. Вместо решения задачи защиты токена, получается, мы полностью меняем принцип. Поправьте меня, если я не прав.
Вы как-то не ответили на вопрос, в куках будет хранится не токен, а другой идентификатор, что это меняет?
И всё же. Как перенос хранения токенов в BFF защитят от отправки данных из вредоносного JS? Приложение ведь всё равно имеет авторизацию через куки, спокойно может извлекать доступные ему данные из бекенда.
Если речь про увод токена, так кто мешает обеспечить защиту с внедрением в Cookie так называемого anti-forgery токена? Т.е. дополнительно к выданному токену проверять секрет, который соответствующим образом зашифрован, согласован с токеном и нет необходимости хранить его на сервере.
Почему мы не можем просто изменить хранение access и refresh токенов в HttpOnly куках, если не доверяем фронтенду?
Я веду к тому, чтобы остаться в рамках stateless, и не деградировать систему до необходимости хранить состояние сессии на сервере.
Допустим, в приложение внедрён вредоносный JS-код.
Каким образом авторизация в куки может помешать вредоносному коду делать запросы к бекенду? Запрос точно также будет авторизован, не по токену в заголовке, но по куки. Ему совершенно не нужно "красть" для этого токен. Более того, куки упрощают вредоносному коду жизнь, так как теперь не надо заботиться о правильной передаче авторизации в бекенд, пытаться извлекать токен из каких-то внутренних хранилищ, т.е. теперь просто можно делать запросы в бек и всё.
Каким образом вредоносный код может украсть данные, если он не может их никуда отправить, кроме того же бека, если конечно правильно настроены CORS?
И вот мы подошли к краю, где DDD и Clean Architecture перестают быть средством, и становятся самоцелью...
Как обычно, ретраи, балансировка, репликация... Компенсирующие действия выполняются в ответ на невозможность корректно завершить транзакцию: денег не хватает, товар закончился, курьер заболел. Компенсация это обычная транзакция, которая стремится вернуть систему к исходному состоянию в конечном счёте. Здесь не так много общего с Rollback в СУБД.
Например, вы дали 10 тыс. рублей человеку за работу, а он заболел, и хочет вернуть вам средства. 5 тыщ. вернул на карту, 2 тыс. наличкой, а остальное на телефон. Т.е. вам вернулись 10 тыс. но не обязательно в том же виде. Но исходное состояние достигнуто, по бизнесу. Это и есть компенсирующие действия.
Как ни прискорбно, но о базовых фичах .NET знают не многие. И городят огород.
Я не так много кода на Go прям изучал, но то что из прикладухи видел похоже на 30-40% "мусора" в виде проверок err после чуть ли не каждой функции. Да ещё и обработка такая, как пыль протёр для видимости, чтоб мама не ругалась :)
По мне так огромная. Во-первых, производительность, так как любой лишний маршаллинг это затраты. Во-вторых, все разработчики могут в равной степени участвовать в развитии всей платформы, смотреть и понимать как она устроена, прикладной код это естественное бесшовное продолжение стека.
Ну и рамки применимости, есть определённые узкие задачи, под которую PHP заточен, и выходить за эти рамки тяжело, а без доп. инструментов попросту невозможно
Очевидно так! Это была ирония, ибо создавать миллионы Task для выполнения cpu-bound операций, даже писать такой код мучительно больно :) А в .NET таки есть экспериментально грин-треды, но производительность у них похуже async/await.
Да основной наверное профит в строгой типизации это рефакторинг. Зарефачить с массовыми изменениями в сотнях и тысячах файлах в строго типизированном ЯП как за здрасьте :) Разделение, объединение типов, вывод интерфейсов, разнесение по модулям, смена списка аргументов, типа возврата, вообще без страха и сомнений.
А в динамике страшно до усрачки что-то трогать лишний раз, по крайней мере мне было страшно :)
Фишка в том, что в пространстве программного кода на строго типизированном ЯП просто не обитает чисел в строках, массивов непонятной размерности или непонятного толка, не бывает массивов-словарей, потому что все намерения выражены явно, они читаются и понимаются явным образом. И дело уже не только в защите компилятора, типизация позволяет проводить перспективный анализ кода, выявляя ошибки даже при соблюдении типов, например, недостижимый код, сравнения которые никогда не будут работать, бесконечное зацикливание, работа с переменными, которые по алгоритму не изменяются, попытка работать с объектами, которых не существует (null). И всё это не означает, что надо писать больше лишнего кода, благодаря той же типизации, современные IDE позволяют предсказывать и предугадывать намерения разработчика, генерируя стандартные проверки на лету.
Все эти бонусы просто меркнут на фоне его величества Рефакторинга. Проводить рефакторинг в типизированных языках, это удовольствие. Любые косяки исправляешь в одном месте, они исправляются в тысячи мест сразу, и ты знаешь что ничего не сломается, так как везде всё явно и строго.
Никакой чёрнокнижной магии, не нужно в голове работать компилятором и думать, как оно там скастит, и что будет если? Всё супер-очевидно и не надо играть в игру: угадай как это сработает в рантайме?
Как человек, изрядно посидевший на проектах с динамикой и статической типизацией, скажу, строгая типизация действительно величайшее благо. И в PHP её затаскивают именно по этой причине, а не потому что "модно", как кому-то по наивности может показаться.
Насколько они не кроссплатформенные? Когда разрабатывал на C++, это было очень-очень давно, на Visual Studio, нормально всё было со стектрейсами. Неужели всё сломали?
Тут речь не про детали реализации, а скорее парадигма разработки. Очень хорошо, когда у исключения есть строгий базовый тип (как в C#, почти). Тут про такое понятие как отказ + возможность что с этим нормально сделать. Или восстановиться до изначального состояния, а не просто молча выплюнуть в консоль "что-то пошло не опять, а снова не так" + стектрейс. Много этим пользовался и на большие портянки кода на Go мне порой больно смотреть. Почти 30-40% это проверки err. Да ещё и часто просто в лог плюют ошибку и.. всё. И делать ещё это надо по месту. А пробрасывать err так вообще на грани преступления.
CPU-bound операции надо параллелить на физическое количество процессоров. Только тогда будет толк. Выше приводил пример, толк есть, более чем в 10 раз быстрее извращений с горутинами.
С позиции enterprise разработки, когда бизнес-объектная модель состоит из десятков тысяч типов и множества слоёв логики, отсутствие максимально строгой типизации превращается просто в ад. Вплоть до того, что даже для таких значений как ИНН, ОГРН и т.п. создаётся отдельный доменный тип, на которым уже навешаны: валидация, парсинг, сериализация, куча расширений и нельзя вот так какую-то рандомную строку сунуть как параметр функции, т.е. перепутать ИНН и ОГРН физически компилятор не даст. Если честно, за всю практику работы в типизированной среде мне крайне редко доводилось кастовать строку к числу, чтобы с чем-нибудь сложить. Зачем? Число в виде строки просто тупо не появится в границах приложения. И такие случаи возникают чаще именно в интеграции с динамическими ЯП, которые без всяких Б могут прислать число строкой, вообще не запариваясь ни разу. Разработчики, получая такие "подарки" очень радуются, ну наконец-то! Расчехляем адаптивную десериализацию, обмазываем аспектами.
Для небольших микро-сервисов, и тем более прослоек, тупо гоняющих данные между БД и фронтом, особо типизация и не нужна наверное. Или я очень уж пристрастился к типизации )