У меня нет "каких-то обработчиков ошибок бизнес-логики". У меня, допустим, есть один конкретный обработчик описанной Вами ситуации со страницей в одном единственном месте, в одном единственном сервисе, предоставляющем страницы книги.
Во всех остальных 99 местах у меня даже обработчика нет, я пользуюсь доступным из коробки, из системы, от HTTP.
Вы мне предлагаете этот единственный конкретный обработчик бизнес-логики сервиса страницы сделать общим для всех моих 9 сервисов и впихнуть его, например, в сервис аккаунта пользователя. Верно я Вас понял? Зачем сервису аккаунта пользователя знать что-то про ошибку бизнес-логики сервиса страниц? И вообще детали того, как обрабатываются конкретные ошибки бизнес-логики в соседнем сервисе? А если коды ошибок бизнес-логики совпадут в разных сервисах?
А еще мы не рассмотрели варианты, когда транспортные коды приводят к перезапросам, переавторизациям, обновлениям токенов, маршрутизации или покупке подписок. Не надо мух с котлетами – в одну сковородку...
Повторю ответ на Ваш вопрос. Меня заставляет разделять ошибки транспорта и логики – экономия и эффективность. Имхо, этот путь дешевле.
Вот тут об этом же. Но если есть цифры, какой из путей дешевле и проще, буду рад с ними ознакомиться.
HTTP-коды? Они ж уже реализованы и доступны из коробки на любой платформе. Остается только научиться ими пользоваться. И тогда, да, реализовывать дубль обработки кодов на соседнем уровне не придется.
Только в конкретных узких случаях, что сильно дешевле, чем продублировать всю систему, связать её независимые сервисы в один клубок, и обязать все связанное теперь обрабатывать ошибки настолько детально, насколько это необходимо одному единственному сервису. А Вы предлагает вот так действовать и считаете, что это будет дешевле и проще?
Это 2 разных уровня обработки с разной детализацией. Они не взаимоисключающие. Наоборот...
Реализация на основе HTTP-кодов может быть одна универсальная на все приложение. Да, будут проблемы с точностью описания ошибки. Зато дешево и сердито.
Если нужно дорого и детально прорабатывать, то пожалуйста - можно подниматься на уровень выше (или спускаться на уровень ниже, смотря как располагать уровни) и детализировать.
В этом смысл уровней. Есть один универсальный обработчик, если он не устраивает, дописываете конкретные обработчики на более высоких (низких уровнях) уровнях. За доп.деньги. При этом универсальный код все так же продолжает работать, если вдруг Вы забыли написать более конкретные вещи…
Поэтому заменять обработку HTTP-кодов джейсоном всегда – в корне неверно. Вы заранее обрекаете себя всегда на излишние затраты. Наоборот, правильно делать общие обработчики и потом их дополнять деталями, если это кому-то будет нужно и кто-то это оплатит...
А вот если использовать свою систему ошибок, не полагаясь на протокол, то единый интерфейс вполне себе возможен. Просто в WebSocket будет небольшой оверхед на id запроса и глагол (действие). А вся остальная часть будет той же самой.
Как-будто и используя систему ошибок HTTP тоже можно...
Вы ж просто расширите WebSocket транспортными ошибками, нет? Их можно придумать свои, а можно взять готовые из HTTP – в чем разница-то?
Как-будто это и есть рабочая, правильная и рекомендованная схема. Ошибки получаются разделенными на 2 уровня - транспортные и логические. При этом они могут быть использованы с любым транспортом (при расширении транспорта, не поддерживающего эти ошибки). Сами ошибки в такой схеме тоже генерируются и обрабатываются на двух разных уровнях и друг с другом не смешиваются, что хорошо.
Как-будто Вы с автором статьи говорите ровно об одном и том же, но разными словами.
Позволю себе добавить в миф про кеширование. На мобилах очень популярны библиотеки кеширования – огромное множество библиотек, которые слоем выше HTTP на клиенте полностью дублируют функционал, который уже имеется в HTTP из коробки. Например, SDWebImage для кеширования картинок на iOS. Для меня, например, такие библиотеки – сигнал, что команда (серверные и клиентские разработчики и аналитик) совершенно не проработала свой функционал. Соответственно, библиотеки эти из мобил надо выпиливать нещадно, а команду обучать лучшим практикам кеширования, встроенным в любую систему и сам протокол HTTP.
Ну, я и не говорил, что все ВПНы одинаково полезны. Это как раз мне пытались, видимо, доказать.
Не смотря на минусы, попробую Вас все же скорректировать. Ругаться будут только те приложения, которые поменяли стандартный алгоритм проверки сертификатов, вшитый вероятным противником в свой софт. Как было отмечено в дискуссии выше их дефолтные алгоритмы не ругаются на описанный там случай. Браузеры тоже, по-видимому, ругаться не станут (но тут я не уверен).
В любом случае, спасибо за конструктив, а не слепые минусы в карму или рейтинг :) Хотел Вас за конструктив плюсануть, но Вам без публикаций низзя, извиняйте.
Мобильное приложение, да. Ошибку вываливает оно, конечно же. Сервер мало че может в отношении MITM, тут Вы правы. Поэтому защиты делают на стороне клиента. И мы не исключение.
Надо, но зачем? (с) Если серт подменен, то нам какое дело, зачем клиент так изголяется? Мы его просто не пустим и вежливо объясним, в чем он не прав. Об этом я уже упоминал выше в дискуссии. Нам это не интересно. А клиенты быстро соображают и что-то делают, что блокировку на вход для них снимает (возможно, выключают ВПН, а может и нет). Ну, молодцы.
Спасибо, что отметили один из случаев, когда серт может не подходить. Я тоже о чем-то подобном подозреваю (т.к.лично наблюдаю в публичных сетях), но писать об этом не стал, ибо тут и так не разобравшись минусов лепят за каждую запятую :)
----
Это я уже понял, да, спасибо, что еще раз на это указали :)
Но факта несоответствия сертов это не отменяет. Как и того, что ВПН "способствует" проведению MITM-атаки. Один из способов (как раз при "стандартной проверке сертов") описан в ветке выше. Без оценок с моей стороны правильности или неправильности описанного способа. Со своей стороны отмечу, что это лишь 1 из способов подмены серта и MITM-атаки, которому "способствует" VPN.
А я где-то продолжаю спорить, что ошибся? Или Вы просто не могли пройти мимо и не пнуть лежачего?
Подмена сертификата тут к тому, что это уязвимость, с которой в систему пускать нельзя, сколько бы сам клиент ей не доверял. Это тоже чушь по-Вашему? И если Вы говорите, что клиенты сами себе эту подмену сознательно производят вместе с ВПН, то почему тогда все в комментах ниже удивляются, что их с ВПН не пускают? В этом мысль. Тоже чушь?
Этот пример разве означает, что подмен сертификатов никогда не происходит? Еще раз отмечу, что на сегодняшний день, проверки подмены сертификатов стреляют у клиентов. Кто и зачем им это делает, не разбираемся — просто не авторизуем таких товарищей, предлагая им самим устранить подмену серта — клиенты обычно справляются.
А как ВПН тогда мой запрос представляет своим? Он же должен установить соединение с моим собеседником вместо меня, а со мной — вместо него. В итоге я общаюсь с собеседником через посредника, который имеет все те свойства (белый ip, геолокацию и прочее), которых нет у меня. Прокси работает аналогично, кажется. У них вообще главная задача — это авторизовать меня где-то в отдельной системе. Прям по определению.
У нас именно проверки на серты стреляют, когда пользователи с ВПН стучатся, насколько я помню. А уж какие там малвари у клиентов — одним им известно. Настолько разрекламировали эти ВПН, что все их вообще не думая и не понимая, используют…
Согласен с Вами, детекты в приложениях работают на подмену сертификата, которую в обязательном порядке осуществит VPN-сервис. Собственно от этой MITM-атаки и защищаются. Тут все логично.
С другой стороны вспоминаю, что в Турции под одним неназванным российским ВПН прекрасно работал сайт гос-услуг. Или даже их приложение. Проблема возникла только в получении подтверждения через СМС. Но если б я на тот момент не был так консервативен и поставил себе Макс, то и код подтверждения я б получил, кажется.
Похоже, что проверочки-то подмены сертификатов на православные прекрасно допускают…
Вообще говоря, нет. На одной копии отбор тоже работает. Просто с сильно меньшей вариативностью и сильно медленнее.
Пример: можно реализовать приложение на 10 архитектурах и выбрать потом лучшую по каким-то критериям. А можно реализовать одну архитектуру, понять, что она доставляет боль — убить её и поменять на другую. Снова понять, что и это был ошибочный выбор… и так далее. Отбор тоже произойдет, просто на него потребуется больше времени. Хотя вот трудозатрат может понадобиться и меньше.
Про прочитать… так книга ж в Вашей же цитате и указана 🤷♂️
Потому что львиная доля функционала может быть проверена на этом уровне.
Выше проверяются только те условия, которые невозможно проверить на более низких уровнях. Вообще вся концепция пирамиды тестирования сводится к одному простому правилу: тестирование должно проводиться на минимально возможном уровне.
Пример: что должно быть на уровне интеграционных тестов? очевидно -- проверки интеграций. Их никак невозможно проверить на уровне модульных тестов потому, что модульные тесты изолированы от всего, от чего только можно их изолировать, в том числе и от интеграций. Поэтому единственный возможный способ провести тест какой-то интеграции -- в интеграционных тестах. Более конкретно: валидация вводимых значений -- модульный тест, ему никакие интеграции не нужны. Проверка, что введенное в поле значение пробросилось туда, куда должно было проброситься – уже интеграционный тест, тут нужно проверять интеграцию разных частей и пробрасывали значения между ними. Заметьте, что модульный тест ни в коем случае не проверяет ввод значения и проброс – только валидацию в изоляции. Это позволяет осуществлять проверки быстро, дешево, стабильно, надежно.
У Вас задача поймать меня на противоречиях, или Вы плохо понимаете, что где находится?
Код валидатора лежит в модели, но создает объект этого кода вьюмодель. Пользуется валидатором (моделью) вьюмодель, но сам код валидатора (модели) отделен от вьюмодели и от последней не зависит. Выше же я Вам уже писал, что код группируется не по месту использования, а по максимизации переиспользуемости и минимизации дублирования.
Может, Вы плохо понимаете концепцию коннасценсции и/или Low coupling/High cohesion?
Давайте закончим, пожалуйста. Думаю, дальше Вы сможете во всем разобраться сами. Наша дискуссия с самого начала не очень относилась к теме статьи (а она, напомню, – способы реализации абстракции).
Очень просто же. Вьюмодель для того и нужна, чтобы соединить отображение с бизнес логикой (помните байндер или абстракцию?) и настроить преобразования данных (помните мэпперы?). Следите за руками.
вьюмодель1 для формы1 создает валидатор и настраивает его на диапазон 0..100. байндер1 связывает форму1 с только что созданным и настроенным на диапазон 0..100 валидатором.
вьюмодель2 для формы2 создает тот же самый валидатор (тот же класс, но другой объект), но настраивает его уже на диапазон 10..50. байндер2 связывает этот второй валидатор с формой2.
Вы великолепны!
Заметьте, никаких дополнительных признаков, кроме имеющейся у валидатора параметризации диапазоном не понадобилось. Ну, а диапазон – часть Вашего домена, как видно из логики Вашего приложения.
Случай с базой. База – тоже вполне себе доменная модель. База – это не только хранение данных, там вполне себе прописываются очень многие ограничения и тяжелая логика. Если Вы ковыряли любую реляционную БД, то знаете, что там ооооочень сложную логику можно прописывать... и, кстати, параметризировать тоже, как в примере выше.
У меня нет "каких-то обработчиков ошибок бизнес-логики". У меня, допустим, есть один конкретный обработчик описанной Вами ситуации со страницей в одном единственном месте, в одном единственном сервисе, предоставляющем страницы книги.
Во всех остальных 99 местах у меня даже обработчика нет, я пользуюсь доступным из коробки, из системы, от HTTP.
Вы мне предлагаете этот единственный конкретный обработчик бизнес-логики сервиса страницы сделать общим для всех моих 9 сервисов и впихнуть его, например, в сервис аккаунта пользователя. Верно я Вас понял? Зачем сервису аккаунта пользователя знать что-то про ошибку бизнес-логики сервиса страниц? И вообще детали того, как обрабатываются конкретные ошибки бизнес-логики в соседнем сервисе? А если коды ошибок бизнес-логики совпадут в разных сервисах?
А еще мы не рассмотрели варианты, когда транспортные коды приводят к перезапросам, переавторизациям, обновлениям токенов, маршрутизации или покупке подписок. Не надо мух с котлетами – в одну сковородку...
Повторю ответ на Ваш вопрос. Меня заставляет разделять ошибки транспорта и логики – экономия и эффективность. Имхо, этот путь дешевле.
Вот тут об этом же. Но если есть цифры, какой из путей дешевле и проще, буду рад с ними ознакомиться.
HTTP-коды? Они ж уже реализованы и доступны из коробки на любой платформе. Остается только научиться ими пользоваться. И тогда, да, реализовывать дубль обработки кодов на соседнем уровне не придется.
Только в конкретных узких случаях, что сильно дешевле, чем продублировать всю систему, связать её независимые сервисы в один клубок, и обязать все связанное теперь обрабатывать ошибки настолько детально, насколько это необходимо одному единственному сервису. А Вы предлагает вот так действовать и считаете, что это будет дешевле и проще?
Вот тут ответ на этот вопрос. От общего к частному всегда дешевле, чем сразу все утыкивать частностями без необходимости...
Это 2 разных уровня обработки с разной детализацией. Они не взаимоисключающие. Наоборот...
Реализация на основе HTTP-кодов может быть одна универсальная на все приложение. Да, будут проблемы с точностью описания ошибки. Зато дешево и сердито.
Если нужно дорого и детально прорабатывать, то пожалуйста - можно подниматься на уровень выше (или спускаться на уровень ниже, смотря как располагать уровни) и детализировать.
В этом смысл уровней. Есть один универсальный обработчик, если он не устраивает, дописываете конкретные обработчики на более высоких (низких уровнях) уровнях. За доп.деньги. При этом универсальный код все так же продолжает работать, если вдруг Вы забыли написать более конкретные вещи…
Поэтому заменять обработку HTTP-кодов джейсоном всегда – в корне неверно. Вы заранее обрекаете себя всегда на излишние затраты. Наоборот, правильно делать общие обработчики и потом их дополнять деталями, если это кому-то будет нужно и кто-то это оплатит...
Как-будто и используя систему ошибок HTTP тоже можно...
Вы ж просто расширите WebSocket транспортными ошибками, нет? Их можно придумать свои, а можно взять готовые из HTTP – в чем разница-то?
Как-будто это и есть рабочая, правильная и рекомендованная схема. Ошибки получаются разделенными на 2 уровня - транспортные и логические. При этом они могут быть использованы с любым транспортом (при расширении транспорта, не поддерживающего эти ошибки). Сами ошибки в такой схеме тоже генерируются и обрабатываются на двух разных уровнях и друг с другом не смешиваются, что хорошо.
Как-будто Вы с автором статьи говорите ровно об одном и том же, но разными словами.
Нет страницы? Даже если нет книги, то страницы-то тоже нет. В чем противоречие?
Спасибо за статью.
Позволю себе добавить в миф про кеширование. На мобилах очень популярны библиотеки кеширования – огромное множество библиотек, которые слоем выше HTTP на клиенте полностью дублируют функционал, который уже имеется в HTTP из коробки. Например, SDWebImage для кеширования картинок на iOS. Для меня, например, такие библиотеки – сигнал, что команда (серверные и клиентские разработчики и аналитик) совершенно не проработала свой функционал. Соответственно, библиотеки эти из мобил надо выпиливать нещадно, а команду обучать лучшим практикам кеширования, встроенным в любую систему и сам протокол HTTP.
Ну, я и не говорил, что все ВПНы одинаково полезны. Это как раз мне пытались, видимо, доказать.
Не смотря на минусы, попробую Вас все же скорректировать. Ругаться будут только те приложения, которые поменяли стандартный алгоритм проверки сертификатов, вшитый вероятным противником в свой софт. Как было отмечено в дискуссии выше их дефолтные алгоритмы не ругаются на описанный там случай. Браузеры тоже, по-видимому, ругаться не станут (но тут я не уверен).
В любом случае, спасибо за конструктив, а не слепые минусы в карму или рейтинг :) Хотел Вас за конструктив плюсануть, но Вам без публикаций низзя, извиняйте.
Мобильное приложение, да. Ошибку вываливает оно, конечно же. Сервер мало че может в отношении MITM, тут Вы правы. Поэтому защиты делают на стороне клиента. И мы не исключение.
Надо, но зачем? (с) Если серт подменен, то нам какое дело, зачем клиент так изголяется? Мы его просто не пустим и вежливо объясним, в чем он не прав. Об этом я уже упоминал выше в дискуссии. Нам это не интересно. А клиенты быстро соображают и что-то делают, что блокировку на вход для них снимает (возможно, выключают ВПН, а может и нет). Ну, молодцы.
Спасибо, что отметили один из случаев, когда серт может не подходить. Я тоже о чем-то подобном подозреваю (т.к.лично наблюдаю в публичных сетях), но писать об этом не стал, ибо тут и так не разобравшись минусов лепят за каждую запятую :)
----
Это я уже понял, да, спасибо, что еще раз на это указали :)
Но факта несоответствия сертов это не отменяет. Как и того, что ВПН "способствует" проведению MITM-атаки. Один из способов (как раз при "стандартной проверке сертов") описан в ветке выше. Без оценок с моей стороны правильности или неправильности описанного способа. Со своей стороны отмечу, что это лишь 1 из способов подмены серта и MITM-атаки, которому "способствует" VPN.
А я где-то продолжаю спорить, что ошибся? Или Вы просто не могли пройти мимо и не пнуть лежачего?
Подмена сертификата тут к тому, что это уязвимость, с которой в систему пускать нельзя, сколько бы сам клиент ей не доверял. Это тоже чушь по-Вашему? И если Вы говорите, что клиенты сами себе эту подмену сознательно производят вместе с ВПН, то почему тогда все в комментах ниже удивляются, что их с ВПН не пускают? В этом мысль. Тоже чушь?
А Вы всегда индукцией так пользуетесь?
Этот пример разве означает, что подмен сертификатов никогда не происходит? Еще раз отмечу, что на сегодняшний день, проверки подмены сертификатов стреляют у клиентов. Кто и зачем им это делает, не разбираемся — просто не авторизуем таких товарищей, предлагая им самим устранить подмену серта — клиенты обычно справляются.
Отлично. Фиксируем.
С правильным ВПН не будет проблем со входом в наши системы из-за рубежа, что у меня и получилось на конкретном примере.
Мальварный ВПН не будет проходить проверки и с ним клиента не пустят, ибо нефиг, даже если он всецело доверяет своему мальварю.
Соответственно, если кого-то под ВПН куда-то не пускает, похоже, что есть смысл проверить его на мальварность.
Спасибо, что помогли разобраться. Собственно, в этом и была моя мысль 🤝
А как ВПН тогда мой запрос представляет своим? Он же должен установить соединение с моим собеседником вместо меня, а со мной — вместо него. В итоге я общаюсь с собеседником через посредника, который имеет все те свойства (белый ip, геолокацию и прочее), которых нет у меня. Прокси работает аналогично, кажется. У них вообще главная задача — это авторизовать меня где-то в отдельной системе. Прям по определению.
У нас именно проверки на серты стреляют, когда пользователи с ВПН стучатся, насколько я помню. А уж какие там малвари у клиентов — одним им известно. Настолько разрекламировали эти ВПН, что все их вообще не думая и не понимая, используют…
Согласен с Вами, детекты в приложениях работают на подмену сертификата, которую в обязательном порядке осуществит VPN-сервис. Собственно от этой MITM-атаки и защищаются. Тут все логично.
С другой стороны вспоминаю, что в Турции под одним неназванным российским ВПН прекрасно работал сайт гос-услуг. Или даже их приложение. Проблема возникла только в получении подтверждения через СМС. Но если б я на тот момент не был так консервативен и поставил себе Макс, то и код подтверждения я б получил, кажется.
Похоже, что проверочки-то подмены сертификатов на православные прекрасно допускают…
Не ручаюсь, что нигде не ошибся.
Вообще говоря, нет. На одной копии отбор тоже работает. Просто с сильно меньшей вариативностью и сильно медленнее.
Пример: можно реализовать приложение на 10 архитектурах и выбрать потом лучшую по каким-то критериям. А можно реализовать одну архитектуру, понять, что она доставляет боль — убить её и поменять на другую. Снова понять, что и это был ошибочный выбор… и так далее. Отбор тоже произойдет, просто на него потребуется больше времени. Хотя вот трудозатрат может понадобиться и меньше.
Про прочитать… так книга ж в Вашей же цитате и указана 🤷♂️
Что им помешало воспользоваться российским ВПН?
Если это еще актуально, то...
Потому что львиная доля функционала может быть проверена на этом уровне.
Выше проверяются только те условия, которые невозможно проверить на более низких уровнях. Вообще вся концепция пирамиды тестирования сводится к одному простому правилу: тестирование должно проводиться на минимально возможном уровне.
Пример: что должно быть на уровне интеграционных тестов? очевидно -- проверки интеграций. Их никак невозможно проверить на уровне модульных тестов потому, что модульные тесты изолированы от всего, от чего только можно их изолировать, в том числе и от интеграций. Поэтому единственный возможный способ провести тест какой-то интеграции -- в интеграционных тестах. Более конкретно: валидация вводимых значений -- модульный тест, ему никакие интеграции не нужны. Проверка, что введенное в поле значение пробросилось туда, куда должно было проброситься – уже интеграционный тест, тут нужно проверять интеграцию разных частей и пробрасывали значения между ними. Заметьте, что модульный тест ни в коем случае не проверяет ввод значения и проброс – только валидацию в изоляции. Это позволяет осуществлять проверки быстро, дешево, стабильно, надежно.
А как же Рунет времен нулевых? Ровно такая схема и была. Все остальное было за бешеные бабки. Вроде доступно, но только самым богатым.
У Вас задача поймать меня на противоречиях, или Вы плохо понимаете, что где находится?
Код валидатора лежит в модели, но создает объект этого кода вьюмодель. Пользуется валидатором (моделью) вьюмодель, но сам код валидатора (модели) отделен от вьюмодели и от последней не зависит. Выше же я Вам уже писал, что код группируется не по месту использования, а по максимизации переиспользуемости и минимизации дублирования.
Может, Вы плохо понимаете концепцию коннасценсции и/или Low coupling/High cohesion?
Давайте закончим, пожалуйста. Думаю, дальше Вы сможете во всем разобраться сами. Наша дискуссия с самого начала не очень относилась к теме статьи (а она, напомню, – способы реализации абстракции).
Очень просто же. Вьюмодель для того и нужна, чтобы соединить отображение с бизнес логикой (помните байндер или абстракцию?) и настроить преобразования данных (помните мэпперы?). Следите за руками.
вьюмодель1 для формы1 создает валидатор и настраивает его на диапазон 0..100. байндер1 связывает форму1 с только что созданным и настроенным на диапазон 0..100 валидатором.
вьюмодель2 для формы2 создает тот же самый валидатор (тот же класс, но другой объект), но настраивает его уже на диапазон 10..50. байндер2 связывает этот второй валидатор с формой2.
Вы великолепны!
Заметьте, никаких дополнительных признаков, кроме имеющейся у валидатора параметризации диапазоном не понадобилось. Ну, а диапазон – часть Вашего домена, как видно из логики Вашего приложения.
Случай с базой. База – тоже вполне себе доменная модель. База – это не только хранение данных, там вполне себе прописываются очень многие ограничения и тяжелая логика. Если Вы ковыряли любую реляционную БД, то знаете, что там ооооочень сложную логику можно прописывать... и, кстати, параметризировать тоже, как в примере выше.