И всё же. Как перенос хранения токенов в 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 разработки, когда бизнес-объектная модель состоит из десятков тысяч типов и множества слоёв логики, отсутствие максимально строгой типизации превращается просто в ад. Вплоть до того, что даже для таких значений как ИНН, ОГРН и т.п. создаётся отдельный доменный тип, на которым уже навешаны: валидация, парсинг, сериализация, куча расширений и нельзя вот так какую-то рандомную строку сунуть как параметр функции, т.е. перепутать ИНН и ОГРН физически компилятор не даст. Если честно, за всю практику работы в типизированной среде мне крайне редко доводилось кастовать строку к числу, чтобы с чем-нибудь сложить. Зачем? Число в виде строки просто тупо не появится в границах приложения. И такие случаи возникают чаще именно в интеграции с динамическими ЯП, которые без всяких Б могут прислать число строкой, вообще не запариваясь ни разу. Разработчики, получая такие "подарки" очень радуются, ну наконец-то! Расчехляем адаптивную десериализацию, обмазываем аспектами.
Для небольших микро-сервисов, и тем более прослоек, тупо гоняющих данные между БД и фронтом, особо типизация и не нужна наверное. Или я очень уж пристрастился к типизации )
Если динамика это фича языка, может стоит усиливать эту фичу, и обходиться вообще без типов, пусть оно как-то само волшебным образом к чему надо приводится? Но в пыху тащат типизацию.
Недавно у нас при интеграции с PHP приложением возник казус. Получали в ответе JSON со словарём вида { "meta": { "prop1": "value1", "prop2": "value2" } } и всё было хорошо, пока всё внезапно не сломалось. По бизнесу словарь может быть пустой, в таких случаях ожидается вот такое { "meta": { } }, но пыха прислала { "meta": [ ] }. Стандартная сериализация при отсутствии явной типизации. Бизнес-процесс пострадали и был простой. Кто виноват? Глупые типизированные платформы, которые должны были догадаться, что [ ] это { }? :)
Когда я спросил у наших разработчиков PHP, почему вы не используете встроенный в PHP веб-сервер, они посмотрели на меня так, как будто я спросил почему вы не едите суп ботинком и на всякий случай отошли по-дальше :)
Намерения замечательные, заставим программиста проверять каждую ошибку. В итоге, паник на панике, и тупая копипаста с пробрасыванием ошибки. Или ещё тупее, бойлерплейт код if(err) printf(ой что-то сломалось). Это всё хуже исключений.
Если уж хотелось очень заставить программиста чекать ошибки там, где это требуется, можно было сделать как в Java и заявлять о выбрасываемых исключениях в контракте метода, чтоб программист либо пробросил это исключение в свой контракт, или try/catch-ил.
А чего тогда все возятся с php-fpm? Какой-то swoole или rr прикручивают, оказывается у пыхи есть свой встроенный продакшен-реди сервер? Или я что-то не понимаю? :)
Что-то тут не чисто. Я решил из любопытства исполнить приведённый код на Go на своей локальной машине (i7-13700, 64gb ram, win11). Так как автор не удосужился представить полных исходников и пример JSON файла, я руками сделал самый простейший.
package main
import (
"encoding/json"
"fmt"
"log"
"os"
"sync"
"time"
)
type Test struct {
Value1 int `json:"Value1"`
Value2 string `json:"Value2"`
}
func main() {
// var data []byte
// var err error
data, err := os.ReadFile("test.json")
if err != nil {
log.Fatalln("Error reading file ", err)
return
}
start := time.Now().UnixMicro()
wg := &sync.WaitGroup{}
for i := 0; i < 1000000000; i++ {
wg.Add(1)
go func() {
defer wg.Done()
var test *Test
err = json.Unmarshal(data, &test)
if err != nil {
fmt.Println("Error reading file ", err)
return
}
}()
}
wg.Wait()
end := time.Now().UnixMicro()
fmt.Printf("result = %d microseconds \n", (end-start))
}
test.json
{
"Value1": 123,
"Value2": "test2"
}
И у меня получилось вот так
result = 271338709 microseconds
~271 секунда, Карл!
В результате выполнения этих команд получил: Golang скомпилированный под локальную машину выполнял команду - 452.430ms
Откуда тут пол секунды получилось?
И для сравнения, сделал подобный тест на dotnet 8.0
using System.Diagnostics;
using System.Text.Json;
var file = File.ReadAllText("D:\\Sources\\TestVsPhp\\test.json");
var sw = Stopwatch.StartNew();
var last = Enumerable.Range(0, 1000000000)
.AsParallel()
.Select<int, Test>(_ => JsonSerializer.Deserialize<Test>(file))
.LastOrDefault();
Console.WriteLine($"result: {sw.ElapsedMilliseconds} milliseconds");
public record Test(int Value1, string Value2);
с результатом
result: 25600 milliseconds
25.6 сек, быстрее в 10 раз. Если брать байты, а не строку, то ~22 сек.
Мутная история какая-то с этим тестом, с его адекватностью, и представленными результатами.
Вот пример базовый образ bitnami/php-fpm весит ~340Mb, а с далеко не самым сложным приложением легко доходит до 1Гб и выше. Базовый образ для приложения на Go, например alpine, весит... ~7Мб. Чувствуете разницу? И это не считая, что пыхе также нужен nginx, или ещё какой веб-сервер. На одном единственном экземпляре приложения может не так чувствуется, но когда идёт активная разработка CI/CD, а экземпляров много, уже ощущается неприличное давление и требовательность к ресурсам. И по времени развёртывания, и по хранению и прочее прочее.
Ну вы ещё с low-code хостингом сравните. Или с хостингом уже готового интернет-магазина, сайта, блога, который вообще на чём угодно может быть написан, просто покупайте и пользуйтесь. В два клика, без знаний какого-либо ЯП в принципе.
Сегодня уже интернет-магазины, которыми так любят хвастаться "за 3 минуты на коленке на Wordpress" уже давно уступили маркет-плейсам и готовым SaaS-решениям. Блоги тем более атавизм. Сайты-визитки? Я вас умоляю.
Весь этот дешёвый хостинг с ISP, почтовиком с каждым днём становится всё менее востребован. Даже забесплатно.
Разработку сложного ПО, если на внешнем хостинге, ведут в облаках (контейнеры), и там Go побеждает, безапелляционно. Ибо весит копейки, ресурсов ест минимально, не требует ничего, а с учётом тарифов на память и вычислительные ресурсы, это имеет серьёзный вес.
И всё же. Как перенос хранения токенов в BFF защитят от отправки данных из вредоносного JS? Приложение ведь всё равно имеет авторизацию через куки, спокойно может извлекать доступные ему данные из бекенда.
Если речь про увод токена, так кто мешает обеспечить защиту с внедрением в Cookie так называемого anti-forgery токена? Т.е. дополнительно к выданному токену проверять секрет, который соответствующим образом зашифрован, согласован с токеном и нет необходимости хранить его на сервере.
Почему мы не можем просто изменить хранение access и refresh токенов в HttpOnly куках, если не доверяем фронтенду?
Я веду к тому, чтобы остаться в рамках stateless, и не деградировать систему до необходимости хранить состояние сессии на сервере.
Допустим, в приложение внедрён вредоносный JS-код.
Каким образом авторизация в куки может помешать вредоносному коду делать запросы к бекенду? Запрос точно также будет авторизован, не по токену в заголовке, но по куки. Ему совершенно не нужно "красть" для этого токен. Более того, куки упрощают вредоносному коду жизнь, так как теперь не надо заботиться о правильной передаче авторизации в бекенд, пытаться извлекать токен из каких-то внутренних хранилищ, т.е. теперь просто можно делать запросы в бек и всё.
Каким образом вредоносный код может украсть данные, если он не может их никуда отправить, кроме того же бека, если конечно правильно настроены CORS?
Как обычно, ретраи, балансировка, репликация... Компенсирующие действия выполняются в ответ на невозможность корректно завершить транзакцию: денег не хватает, товар закончился, курьер заболел. Компенсация это обычная транзакция, которая стремится вернуть систему к исходному состоянию в конечном счёте. Здесь не так много общего с 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 разработки, когда бизнес-объектная модель состоит из десятков тысяч типов и множества слоёв логики, отсутствие максимально строгой типизации превращается просто в ад. Вплоть до того, что даже для таких значений как ИНН, ОГРН и т.п. создаётся отдельный доменный тип, на которым уже навешаны: валидация, парсинг, сериализация, куча расширений и нельзя вот так какую-то рандомную строку сунуть как параметр функции, т.е. перепутать ИНН и ОГРН физически компилятор не даст. Если честно, за всю практику работы в типизированной среде мне крайне редко доводилось кастовать строку к числу, чтобы с чем-нибудь сложить. Зачем? Число в виде строки просто тупо не появится в границах приложения. И такие случаи возникают чаще именно в интеграции с динамическими ЯП, которые без всяких Б могут прислать число строкой, вообще не запариваясь ни разу. Разработчики, получая такие "подарки" очень радуются, ну наконец-то! Расчехляем адаптивную десериализацию, обмазываем аспектами.
Для небольших микро-сервисов, и тем более прослоек, тупо гоняющих данные между БД и фронтом, особо типизация и не нужна наверное. Или я очень уж пристрастился к типизации )
Если динамика это фича языка, может стоит усиливать эту фичу, и обходиться вообще без типов, пусть оно как-то само волшебным образом к чему надо приводится? Но в пыху тащат типизацию.
Недавно у нас при интеграции с PHP приложением возник казус. Получали в ответе JSON со словарём вида
{ "meta": { "prop1": "value1", "prop2": "value2" } }и всё было хорошо, пока всё внезапно не сломалось. По бизнесу словарь может быть пустой, в таких случаях ожидается вот такое{ "meta": { } }, но пыха прислала{ "meta": [ ] }. Стандартная сериализация при отсутствии явной типизации. Бизнес-процесс пострадали и был простой. Кто виноват? Глупые типизированные платформы, которые должны были догадаться, что[ ]это{ }? :)Когда я спросил у наших разработчиков PHP, почему вы не используете встроенный в PHP веб-сервер, они посмотрели на меня так, как будто я спросил почему вы не едите суп ботинком и на всякий случай отошли по-дальше :)
Намерения замечательные, заставим программиста проверять каждую ошибку. В итоге, паник на панике, и тупая копипаста с пробрасыванием ошибки. Или ещё тупее, бойлерплейт код if(err) printf(ой что-то сломалось). Это всё хуже исключений.
Если уж хотелось очень заставить программиста чекать ошибки там, где это требуется, можно было сделать как в Java и заявлять о выбрасываемых исключениях в контракте метода, чтоб программист либо пробросил это исключение в свой контракт, или try/catch-ил.
В C++ есть исключения и всё там хорошо.
А чего тогда все возятся с php-fpm? Какой-то swoole или rr прикручивают, оказывается у пыхи есть свой встроенный продакшен-реди сервер? Или я что-то не понимаю? :)
Вот-вот. На лицо непонимание зачем нужны горутины, тут даже задача не асинхронная, а чисто cpu bound.
Что-то тут не чисто. Я решил из любопытства исполнить приведённый код на Go на своей локальной машине (i7-13700, 64gb ram, win11). Так как автор не удосужился представить полных исходников и пример JSON файла, я руками сделал самый простейший.
test.json
И у меня получилось вот так
~271 секунда, Карл!
Откуда тут пол секунды получилось?
И для сравнения, сделал подобный тест на dotnet 8.0
с результатом
25.6 сек, быстрее в 10 раз. Если брать байты, а не строку, то ~22 сек.
Мутная история какая-то с этим тестом, с его адекватностью, и представленными результатами.
Вот пример базовый образ
bitnami/php-fpmвесит ~340Mb, а с далеко не самым сложным приложением легко доходит до 1Гб и выше. Базовый образ для приложения на Go, напримерalpine, весит... ~7Мб. Чувствуете разницу? И это не считая, что пыхе также нужен nginx, или ещё какой веб-сервер. На одном единственном экземпляре приложения может не так чувствуется, но когда идёт активная разработка CI/CD, а экземпляров много, уже ощущается неприличное давление и требовательность к ресурсам. И по времени развёртывания, и по хранению и прочее прочее.Ну вы ещё с low-code хостингом сравните. Или с хостингом уже готового интернет-магазина, сайта, блога, который вообще на чём угодно может быть написан, просто покупайте и пользуйтесь. В два клика, без знаний какого-либо ЯП в принципе.
Сегодня уже интернет-магазины, которыми так любят хвастаться "за 3 минуты на коленке на Wordpress" уже давно уступили маркет-плейсам и готовым SaaS-решениям. Блоги тем более атавизм. Сайты-визитки? Я вас умоляю.
Весь этот дешёвый хостинг с ISP, почтовиком с каждым днём становится всё менее востребован. Даже забесплатно.
Разработку сложного ПО, если на внешнем хостинге, ведут в облаках (контейнеры), и там Go побеждает, безапелляционно. Ибо весит копейки, ресурсов ест минимально, не требует ничего, а с учётом тарифов на память и вычислительные ресурсы, это имеет серьёзный вес.