День 1241. #Курсы
Давно не предлагал никаких видео. И вот в очередной раз неведомые алгоритмы ютуба подкинули годноты. Канал Coding Tutorials с большим количеством, на мой взгляд, прекрасного контента на тему C#, Angular и Blazor от Джаспера Кента, эксперта с более чем 30-летним стажем в разработке ПО и преподавании. У канала с таким контентом почему-то просто преступно мало подписчиков и просмотров.

Мне попалось видео про сборку мусора. Опять же, на мой взгляд, прекрасное наглядное объяснение. Из этой же серии есть про боксинг, передачу по ссылке и по значению, хеширование и криптографию, ковариантность и контравариантность и т.п. Видео небольшие и отлично подойдут как новичкам, чтобы в общих чертах понять, о чём речь, так и опытным разработчикам, чтобы, например, освежить свои знания перед собеседованием.

Кроме этого, целые плейлисты про
- SOLID
- Паттерны проектирования
- Внедрение зависимостей
- Entity Framework
- Angular
- Blazor
и про многое другое.

В общем, категорически советую.

День 1242. #ЧтоНовенького
Пошаговый Переход с ASP.NET на ASP.NET Core
В конце мая Microsoft представили превью инструментов для пошаговой миграции приложений ASP.NET Framework на ASP.NET Core. Инструментарий состоит из двух компонентов:
- расширения для Visual Studio, которое создаёт новое приложение ASP.NET Core наряду с существующим приложением, чтобы конечные точки можно было постепенно перемещать из одного приложения в другое,
- библиотеки System.Web с адаптерами, позволяющими коду ссылаться на общий API, ориентированный на .NET Standard 2.0 и пригодный для использования как в контексте ASP.NET, так и в контексте ASP.NET Core.

Недавно вышла вторая превью версия этого средства миграции. Обновленный инструментарий включает в себя улучшения кода, сгенерированного расширением Visual Studio, дополнения в адаптерах System.Web и возможность совместного использования аутентификации между приложениями ASP.NET и ASP.NET Core.

Установите (или обновите, если использовали раньше) расширение Microsoft Project Migrations для Visual Studio. Оно автоматически будет ссылаться на обновлённую версию адаптеров System.Web.

Пошаговая миграция
Многие крупные проекты используются постоянно в критически важных бизнес-приложениях. Они должны продолжать функционировать и не могут быть приостановлены из-за потенциально длительного перехода на ASP.NET Core. Это означает, что во время миграции приложение должно продолжать работать, а новые функции могут добавляться и развёртываться как обычно. Паттерн Душитель используется для замены существующей устаревшей системы по частям, пока вся система не будет обновлена, а старая система не будет выведена из эксплуатации.

Мы имеем приложение ASP.NET, размещённое в IIS и включающее набор процессов для развёртывания и обслуживания. Процесс миграции направлен на переход к ASP.NET Core без ущерба для текущего развёртывания.

Первый шаг — представить новое приложение на основе ASP.NET Core, которое станет точкой входа. Трафик будет поступать в приложение ASP.NET Core, и, если приложение не сможет сопоставить маршрут, оно передаст запрос в приложение ASP.NET через YARP. Большая часть кода по-прежнему будет находиться в приложении ASP.NET, но приложение ASP.NET Core теперь получает первоначальный трафик и управляет маршрутизацией.

Чтобы начать миграцию бизнес-логики, использующей HttpContext, должны быть созданы библиотеки на основе Microsoft.AspNetCore.SystemWebAdapters. Это позволяет библиотекам, использующим API System.Web, ориентироваться на .NET Framework, .NET Core или .NET Standard 2.0.

Теперь можно начать перемещать маршруты по одному в приложение ASP.NET Core. Это могут быть контроллеры MVC или веб-API (или даже один метод из контроллера), страницы веб-форм, обработчики HTTP или какие-либо другие реализации маршрута. Как только маршрут станет доступен в приложении ASP.NET Core, он будет сопоставляться и обслуживаться оттуда. Со временем основное приложение начнёт обрабатывать всё больше маршрутов.
По ходу миграции у вас может быть маршрут как в приложении ASP.NET Core, так и в приложении ASP.NET Framework. Здесь возможно выполнить A/B-тестирование, чтобы убедиться, что функциональность соответствует ожиданиям.

Когда приложение .NET Framework больше не нужно, его можно удалить. При этом приложение ASP.NET Core по-прежнему будет использовать адаптеры. Последним шагом будет отказаться от использования адаптеров, полностью переведя приложение на платформу ASP.NET Core, чтобы полноценно использовать производительность и новые функции ASP.NET Core, которые могут быть недоступны через адаптеры.

В этом видео показан пример миграции https://youtu.be/P96l0pDNVpM

Источники:
- https://devblogs.microsoft.com/dotnet/incremental-asp-net-to-asp-net-core-migration/
- https://devblogs.microsoft.com/dotnet/incremental-asp-net-migration-tooling-preview-2/

День 1243. #Юмор

День 1244. #Оффтоп
Закон Конвея, DDD и Микросервисы
Закон Конвея гласит, что «любая организация, проектирующая систему, создаст проект, структура которого является копией коммуникационной структуры организации». Это оказывает существенное влияние на то, как создаётся ПО, особенно если применяются микросервисы и/или предметно-ориентированное проектирование (DDD).

Мел Конвей заметил, что отдельным организационным единицам или командам в рамках крупной организации при совместной работе над крупной системой приходится разбивать эту систему на части, над которыми каждая из команд может работать настолько независимо, насколько это возможно. Затем они выясняли, как две системы будут взаимодействовать друг с другом через какой-либо канал коммуникации. Таким образом структура системы отражала структуру организации.

В небольших организациях это может быть меньше выражено. Когда людей немного, вам не нужны отдельные команды и каналы связи. Вы можете построить систему, используя любые методы декомпозиции, которые имеют смысл для системы и её архитектуры. Но по достижении определённого предела оказывается, что очень неэффективно, когда разные команды работают над одним модулем, и объём дополнительных затрат на коммуникации быстро растёт.

В DDD идея ограниченного контекста используется для обеспечения инкапсуляции в системе. В этом контексте применяется определённый набор предположений, единый язык и отдельная модель предметной области. Очевидно, рекомендуется наличие корреляции между командами и ограниченными контекстами, так как в противном случае очень легко нарушить инкапсуляцию и применить неправильные предположения, язык или модель в заданном контексте.

Микросервисы очень хорошо сопоставляются с ограниченными контекстами, и это одна из причин, по которой в них часто применяется DDD. Чтобы быть по-настоящему независимым от других частей системы, микросервис должен иметь собственный конвейер сборки, собственную инфраструктуру хранения данных и т. д. Во многих организациях за отдельный микросервис отвечает отдельная команда. Было бы странно и неэффективно иметь микросервис, за поддержку и развёртывание которого несёт ответственность несколько разных команд.

Всё это означает, что, если вы крупная организация, ваша организационная структура оказывает значительное влияние на архитектуру распределённых систем, которые вы создаёте и поставляете. Вы не можете ожидать, что ваш технический директор или ведущий архитектор сядут в комнате с вашими лучшими техническими специалистами, спроектируют систему на доске, а затем ваша существующая организация просто поделит работу и выполнит её. Скорее всего, дизайн системы будет (или должен) влиять на организацию самих команд, и в какой-то степени наоборот.

В ПО есть много проблем, которые не обязательно являются проблемами собственно ПО. Многие проблемы с поставкой больших и сложных систем связаны с проблемами коммуникаций, людей, менеджмента. Часто технари и управленцы идут разными дорогами в своей карьере, и это приводит к разрыву между тем, как система должна быть спроектирована с технической точки зрения, и тем, как организация структурирована с точки зрения команд и структуры отчетности. Исправление этого несоответствия может иметь большее значение для успеха системы, чем многие другие решения в области технической архитектуры или практик кодирования.

Классический комикс ниже иллюстрирует некоторые крупные компании и их (предполагаемые) проблемы с организационной структурой.

Итого
Понимание закона Конвея и его влияния на проектирование больших систем важно, если вы собираетесь распознавать проблемы, связанные с организацией команд. То, как вы разбиваете большую проблему и настраиваете коммуникации между модулями, должно влиять на то, как вы организуете команды, и, если эти команды не согласуются с программными модулями, которые вы создаёте, у вас возникнут проблемы. Чем раньше эти проблемы будут обнаружены и исправлены, тем больше шансов на общий успех системы и, в конечном счёте, организации.

Источник: https://ardalis.com/conways-law-ddd-and-microservices/

Некоторые крупные компании и их (предполагаемые) проблемы с организационной структурой.

День 1245. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало

5. Обход аутентификации
Под аутентификацией понимается подтверждение личности перед выполнением конфиденциальных действий или доступом к конфиденциальным данным. Если аутентификация реализована в приложении неправильно, злоумышленники могут использовать это для получения доступа к функциям, которые им не должны быть доступны.

6. Неправильный контроль доступа
Проблема возникает, когда контроль доступа в приложении реализован неправильно и может быть обойдён злоумышленником. Проблемы обхода аутентификации, по сути, подмножество проблем контроля доступа. Однако помимо аутентификации, которая просит пользователя подтвердить свою личность («Кто вы?»), авторизация отвечает за вопрос: «Что разрешено делать этому пользователю?». Надлежащие аутентификация и авторизация вместе гарантируют, что пользователи не смогут получить доступ к функциям за пределами их разрешений.
Существует несколько способов настройки авторизации для пользователей: управление доступом на основе ролей или утверждений, списки контроля доступа и многое другое.

7. Обход каталога
Ещё один тип ненадлежащего контроля доступа. При этом злоумышленники могут просматривать, изменять или исполнять файлы, к которым у них не должно быть доступа, манипулируя путями к файлам в полях пользовательского ввода, например, добавляя ../ или другие специальные символы к пути. Добавив ../ к пути, можно перейти к родительскому каталогу и получить доступ к системным файлам за пределами веб-каталога.

Злоумышленники часто могут использовать обход каталога для доступа к конфиденциальным файлам, таким как файлы конфигурации, файлы журналов и исходный код. Чтобы предотвратить обход каталога, вы должны проверять пользовательский ввод и избегать прямых ссылок на имена файлов, вместо этого используя косвенные идентификаторы.

8. Запись произвольного файла
Уязвимости записи произвольных файлов работают аналогично обходу каталогов. Если приложение записывает файлы на компьютер и определяет имя выходного файла с помощью пользовательского ввода, злоумышленники могут создавать произвольные файлы по любому пути, который они хотят, или перезаписывать существующие системные файлы. Злоумышленники могут изменить важные системные файлы, такие как файлы паролей или файлы журналов, или добавить свои собственные исполняемые файлы в каталоги сценариев.

Лучший способ снизить этот риск — не создавать имена файлов на основе каких-либо данных, вводимых пользователем, включая информацию о сеансе, данные HTTP или вообще чего-либо, что контролируется пользователем. Вы должны контролировать имя файла, путь и расширение для каждого создаваемого файла. Например, вы можете генерировать случайное буквенно-цифровое имя файла каждый раз, когда пользователю нужно создать уникальный файл. Вы также можете удалять введенные пользователем специальные символы перед созданием файла.

9. Уязвимости шифрования
Проблемы с шифрованием, вероятно, являются одной из самых серьёзных уязвимостей, которые могут возникнуть в приложении. Уязвимости шифрования относятся к случаям, когда шифрование и хеширование реализованы неправильно. Это может привести к массовым утечкам данных и обходу аутентификации из-за спуфинга сеанса, когда злоумышленник выдаёт себя за аутентифицированного пользователя, чтобы получить доступ к важным данным или информации.

Некоторые распространённые ошибки, которые допускают разработчики при реализации шифрования на сайте:
- Использование слабых алгоритмов,
- Использование неправильного алгоритма для заданной цели,
- Использование собственного алгоритма шифрования,
- Генерация слабых случайных чисел,
- Использование кодировки вместо шифрования.

Продолжение следует…

Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet

День 1246. #ЗаметкиНаПолях #AsyncTips
Асинхронные очереди

Задача
Требуется коммуникационный канал для передачи сообщений или данных из одной части кода в другую по принципу FIFO без блокирования потоков.
Например, один фрагмент кода может загружать данные, которые отправляются по каналу по мере загрузки; при этом UI-поток получает данные и выводит их.

Решение
Требуется очередь с асинхронным API. В базовом фреймворке .NET такого типа нет, но в NuGet есть пара возможных решений.

1. System.Threading.Channels
Библиотека для асинхронных коллекций «производитель/потребитель» с акцентом на быстродействие. Производители записывают элементы в канал вызовом WriteAsync, а когда завершают производство элементов, один из них вызывает Complete для уведомления канала о том, что в дальнейшем элементов больше не будет:

var queue = Channel.CreateUnbounded<int>();
// Код-производитель
var writer = queue.Writer;
await writer.WriteAsync(7);
await writer.WriteAsync(13);
writer.Complete();

// Код-потребитель
// Выводит "7", затем "13".
var reader = queue.Reader;
await foreach (int value in reader.ReadAllAsync())
  Console.WriteLine(value);

Код-потребитель использует асинхронные потоки.

2. System.Threading.Tasks.Dataflow
BufferBlock<T> из библиотеки TPL Dataflow имеет много общего с каналом:

var queue = new BufferBlock<int>();
// Код-производитель
await queue.SendAsync(7);
await queue.SendAsync(13);
queue.Complete();

// Код-потребитель.
// Выводит "7", затем "13".
while (await queue.OutputAvailableAsync())
  Console.WriteLine(await queue.ReceiveAsync());

Код-потребитель использует метод OutputAvailableAsync, который на самом деле полезен только с одним потребителем. Если потребителей несколько, может случиться, что OutputAvailableAsync вернет true для нескольких потребителей, хотя элемент только один. Если очередь завершена, то ReceiveAsync выдаст исключение InvalidOperationException. Таким образом, для нескольких потребителей код будет выглядеть так:

while (true)
{
  int item;
  try
  {
    item = await queue.ReceiveAsync();
  }
  catch (InvalidOperationException)
  {
    break;
  }
  Console.WriteLine(item);
}

Библиотека Channels больше подходит для асинхронных очередей «производитель/потребитель» там, где это возможно. Помимо регулировки для случаев, когда производители работают быстрее потребителей, поддерживаются несколько режимов выборки (об этом в следующих постах). Однако, если логика вашего приложения может быть выражена в виде «конвейера», через который проходят данные, TPL Dataflow может быть более логичным кандидатом.

См. также
- очереди «производитель/потребитель» с блокирующей семантикой вместо асинхронной.

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.

День 1247. #Карьера #ВопросыНаСобеседовании
Самые Распространённые Вопросы на Поведенческом Собеседовании. Начало
Вот топ вопросов на поведенческом собеседовании, на которые вы должны быть готовы ответить при приёме на работу.

Что это такое?
Поведенческие вопросы предназначены для того, чтобы определить, как вы будете справляться с конкретными ситуациями в рабочей среде. Часто вас просят использовать свой опыт в качестве примера и больше сосредоточиться на социальных навыках, а не на технических аспектах работы. Это позволяет потенциальному работодателю понять, как ваш прошлый опыт работы подготовил вас к будущим задачам и вызовам. Наверняка вас просили ответить на вопрос вроде: «Расскажите о случае, когда у вас был конфликт с кем-то из вашей команды».

Как подготовиться?
Самое важное, что все эти вопросы касаются вашего личного опыта. Будет полезно, если вы начнёте подготовку с размышлений о том, из каких историй вы можете извлечь ответы на эти вопросы. Если вам зададут вопрос, к которому вы не готовы, вы можете представить себя чересчур конфликтным или, что ещё хуже показать, что вы намеренно избегаете конфронтации — ни то, ни другое не поможет вам получить работу.

1. «Какая у вас самая большая слабость?»
Один из самых распространённых вопросов, и тот, на котором чаще всего спотыкаются. Лучший ответ — назвать слабость, которая применима только к конкретным ситуациям, например: «Не терплю, когда коллеги не выполняют обещания, особенно когда это относится к критически важным задачам». Ключ в том, чтобы закончить ответ тем, как вы планируете избавиться от этой слабости. Это яркий пример того, как использовать метод STAR (Situation, Task, Action, Result - Ситуация, Задача, Действие, Результат).

Ситуация: опишите ситуацию, в которой всё произошло.
Задача: опишите задачу, которую вы должны были выполнить, чтобы решить проблему.
Действие: объясните, какие действия вы предприняли для выполнения задачи.
Результат: расскажите о результатах своих действий и постарайтесь быть как можно более подробным. Как ваши действия помогли компании или организации работать лучше?

2. Вопросы о командной работе
Большинство профессий требуют, чтобы вы работали в команде, поэтому будьте готовы рассказать о своём опыте как члена команды. Вам понадобится история, показывающая вашу способность работать с другими в трудных обстоятельствах. Подумайте о разрешении конфликтов в команде, преодолении ограничений проекта или мотивации других.

«Расскажите о ситуации, когда вам пришлось сотрудничать с кем-то, чей характер сильно отличался от вашего.»
«Опишите ситуацию, когда вам пришлось проявить инициативу и продемонстрировать лидерские качества.»
«Расскажите о случае, когда вам нужно было получить информацию от человека, который не очень реагировал. Что вы сделали?»
«Расскажите о случае, когда вы неверно отреагировали на ситуацию с коллегой.»

Вопросы о командной работе — отличный шанс указать на вашу способность к сотрудничеству, и ваш ответ должен подчеркнуть ваши сильные стороны в этой области. Может быть трудно представить конфликт как положительный момент, особенно если вы чувствуете, что были не неправы. Важно помнить, что в ответе нужно сосредоточиться не на конфликте, а на процессе поиска решения.

Отвечая на вопросы о командной работе, убедитесь, что ваш ответ показывает, что:
- вы признаёте, что у всех команд могут быть проблемы;
- вы можете работать с другими даже в сложных обстоятельствах;
- вы хороший слушатель;
- вы реагируете и действуете с заботой и вниманием к своей команде.

Продолжение следует…

Источник: https://www.fastcompany.com/90756503/your-ultimate-guide-to-ace-the-most-common-interview-questions

День 1248. #Карьера #ВопросыНаСобеседовании
Самые Распространённые Вопросы на Поведенческом Собеседовании. Продолжение
Начало

3. Вопросы про клиентов
Если работа требует, чтобы вы работали с клиентами или партнёрами, подготовьтесь к некоторым из таких вопросов. Работодатели захотят понять, как вы положительно представили компанию и как вы преодолели трудности, чтобы лучше обслужить клиента.

«Опишите ситуацию взаимодействия с трудным клиентом и как вы с ней справились.»
«Как вы расставляете приоритеты, когда работаете с большим количеством запросов от клиентов.»
«Случалось ли, что вы не оправдали ожиданий клиента, и как вы пытались исправить ситуацию.»

Эти вопросы будут вашим шансом доказать, что вы можете обращаться с трудными клиентами. Обязательно объясните:
- контекст вашего взаимодействия;
- тип клиента, с которым вы имели дело;
- урок, который вы извлекли из этого опыта.

Не всем вашим историям нужен счастливый конец, но акцентируйте внимание на том, какой опыт вы получили, независимо от результата.

4. Вопросы о тайм-менеджменте
Тайм-менеджмент важен независимо от того, какую работу вы выполняете. Большинство работодателей захотят услышать, как вы решаете несколько вещей одновременно, расставляете приоритеты, сохраняете организованность и выполняете работу в срок.

«Расскажите о случае завала на работе. Что вы сделали?»
«Расскажите о случае, когда непредвиденная проблема сорвала ваши планы. Как вы отреагировали?»
«Как вы ставите цели и как добиваетесь их достижения?»

- Выделите любые инструменты, которые вы использовали, чтобы не сбиться с пути.
- Подчеркните, как вы общались в команде на протяжении всего процесса и делегировали задачи, когда это было необходимо.

5. Вопросы о ваших коммуникативных способностях
Вы должны уметь чётко и уважительно излагать свои мысли. Большинство людей смогут привести примеры коммуникации, но главное здесь — рассказать историю, в которой подчёркивается вдумчивая подготовка и логический мыслительный процесс.

«Расскажите об успешной презентации, которую вы провели, и почему вы считаете её успешной.»
«Расскажите о ситуации, когда вам приходилось полагаться на письменное общение, чтобы объяснить свои идеи вашей команде.»
«Приведите пример, когда вам удалось убедить коллегу в вашей правоте.»

Коммуникационные вопросы — это также возможность выделить различные методы общения, которые вы используете и в которых преуспеваете. Поэтому, если у вас проблемы с общением, не уклоняйтесь от вопроса. Подчеркните, что это не ваша сильная сторона, и расскажите историю, показывающую, что вы работаете над улучшением своей слабости.

Окончание следует…

Источник: https://www.fastcompany.com/90756503/your-ultimate-guide-to-ace-the-most-common-interview-questions

День 1249. #Карьера #ВопросыНаСобеседовании
Самые Распространённые Вопросы на Поведенческом Собеседовании. Окончание
Начало
Продолжение

6. Вопросы о вашей способности адаптироваться
Большинству людей приходилось преодолевать какие-то невзгоды на рабочем месте, поэтому не бойтесь показаться уязвимыми и обязательно подчеркните, как вы успешно справились с проблемой. Даже если решение было далёким от идеального, расскажите об опыте, который вы извлекли из ситуации.

«Расскажите о случае, когда вы находились под сильным давлением и как вы это пережили.»
«Расскажите, как вы устроились на предыдущую работу и адаптировались там.»
«Расскажите о вашей неудаче. Как вы справились с ситуацией?»

Используйте вопросы об адаптации, чтобы рассказать о:
- том, как вы ставите цели и придерживаетесь их;
- методах борьбы со стрессом, которые используете.

Никто не хочет нанимать человека, который выгорает каждые полгода. Работодатели хотят знать, что у вас есть самосознание и вы можете контролировать свои эмоции. Расскажите, что вы чувствовали в моменты стресса и что вы делали с этими чувствами, что сработало, а что нет.

7. Вопросы и мотивации и ценностях
Иногда вопросы интервью могут показаться случайными или личными. Многие из них — это попытки узнать больше о том, что вас мотивирует. В идеале ваш ответ должен напрямую касаться ценностей и мотивации, даже если в вопросе о них прямо не говорится.

«Расскажите о своём самом большом профессиональном достижении.»
«Расскажите о случае, когда вы работали либо под очень пристальным надзором, либо под очень слабым надзором. Как вы с этим справились?»
«Приведите пример, когда вы смогли проявить творческий подход в работе. Что было интересным или трудным в этом?»
«Расскажите о случае, когда вы были недовольны своей ролью. Что можно было сделать?»

Вопросы о мотивации и ценностях — это прекрасная возможность:
- выделить любые особые навыки или увлечения, которые у вас есть, о которых вы ещё не говорили;
- поговорить о том, что вас вдохновляет в вашей работе;
- поделиться мыслями, где вы видите себя в будущем;
- описать, насколько вы целеустремленны и какие шаги вы предпримете, чтобы достичь этого.

Для начала расскажите о том, как недавно повысили свой профессиональный уровень. Это простой способ показать, что вы не только мотивированы на совершенствование, но и активно работаете над этим.

Итого
Существует бесконечное количество способов ответить на вопросы поведенческого интервью. Самое главное, что нужно помнить:
1) Будьте честным.
2) Заранее изучите возможные вопросы.
3) Запишите кратко истории, которые, по вашему мнению, будут хорошими ответами на вопросы.
4) Запишите опыт, который вы извлекли из каждой истории.

Наконец, помните, что работодатели проводят собеседования со многими кандидатами и, вероятно, услышат несколько похожих ответов, поэтому избегайте общих слов. Наполнение вашего резюме или профиля на LinkedIn общими словами может оттолкнуть потенциальных работодателей, но гораздо хуже, когда вы говорите их во время интервью. Вместо этого потренируйтесь описывать свои навыки своими словами, которые продемонстрируют вашу уникальность, квалификацию и ценность.

Источник: https://www.fastcompany.com/90756503/your-ultimate-guide-to-ace-the-most-common-interview-questions

День 1251. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало 1-4
Продолжение 5-9

10. Небезопасная конфигурация TLS и неправильная проверка сертификата
Помимо правильного шифрования информации в ваших хранилищах данных, вам также необходимо убедиться, что вы общаетесь с доверенным компьютером, а не со злоумышленником. TLS использует цифровые сертификаты в качестве основы для шифрования с открытым ключом, и вам необходимо проверить эти сертификаты, прежде чем устанавливать соединение с третьей стороной. Вы должны убедиться, что сервер, к которому вы пытаетесь подключиться, имеет сертификат, выданный доверенным центром сертификации (certificate authority - CA), и что ни один из сертификатов в цепочке не просрочен.

11. Массовое присвоение (оверпостинг)
Относится к практике присвоения значений нескольким переменным или свойствам объекта. Уязвимости массового присвоения возникают, когда приложение автоматически назначает пользовательский ввод нескольким переменным, объектам или свойствам. Это функция многих платформ приложений, предназначенная для упрощения разработки.

Однако эта функция иногда позволяет злоумышленникам перезаписывать, изменять или создавать новые переменные или свойства объекта по своему желанию. Это может привести к обходу аутентификации и манипулированию логикой программы. Чтобы предотвратить массовое присвоение, вы можете отключить эту функцию в используемой вами среде или использовать белый список, чтобы разрешить присвоение только для определённых свойств или переменных. Например, в ASP.NET можно использовать атрибут Bind на аргументе метода действия контроллера.

12. Отравление заголовка Host
Веб-серверы часто размещают несколько разных веб-сайтов на одном и том же IP-адресе. После того, как HTTP-запрос поступает на IP-адрес, сервер перенаправляет запрос на хост, указанный в заголовке Host. Хотя заголовки Host обычно устанавливаются браузером пользователя, они всё равно являются пользовательским вводом, и поэтому им нельзя доверять.

Если веб-приложение не проверяет заголовок Host перед его использованием для создания относительных адресов, злоумышленники могут запустить ряд атак, таких как XSS, подделка запросов на стороне сервера (SSRF) или атак с отравлением веб-кэша через заголовок Host. Например, если приложение использует заголовок Host для определения местоположения сценариев, злоумышленник может отправить вредоносный заголовок Host, чтобы приложение выполнило вредоносный сценарий:

var scriptURL = $"https://{Request.Host}/script.js";

13. Открытые перенаправления
Веб-сайты часто должны автоматически перенаправлять своих пользователей на другие страницы. Например, такой сценарий возникает, когда не прошедшие авторизацию пользователи пытаются получить доступ к странице, требующей входа в систему. Веб-сайт обычно перенаправляет их на страницу входа, а затем возвращает в исходное местоположение после авторизации.

Во время атаки с открытым перенаправлением злоумышленник обманом заставляет пользователя посетить внешний сайт, предоставляя ему URL-адрес законного сайта, который перенаправляет куда-то еще. Это может заставить пользователей поверить, что они все ещё находятся на исходном сайте, и помочь мошенникам создать более правдоподобную фишинговую страницу (см. подробнее).

Чтобы предотвратить открытые перенаправления, вам необходимо убедиться, что приложение не перенаправляет пользователей на вредоносные места. Например, вы можете полностью запретить перенаправления за пределы сайта, проверяя URL-адреса перенаправления. Есть много других способов предотвращения открытых перенаправлений, таких как проверка реферера запросов или использование индексов страниц для перенаправлений. Однако из-за сложности проверки URL-адресов открытые перенаправления остаются распространенной проблемой в современных веб-приложениях.

Продолжение следует…

Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet

День 1252. #Курсы
Сегодня порекомендую вам ещё один молодой и сильно недооценённый (судя по небольшому количеству подписчиков) образовательный канал на ютубе. Канал Dev Jungles от Андрея Подколзина (да, в этот раз контент на русском).

Андрей начинал с длинных стримов по постройке веб сервера на .NET 5 с нуля, оптимизации C# кода с помощью BenchMarkDotNet или профилировки памяти с помощью dotMemory.

Однако в последнее время на канале стали появляться и более короткие обучающие видео, вроде:
- Истории криптографии
- Топ вопросов на собеседовании по C#
- Топ вопросов про многопоточность
- Модель CPU и Assembler к нему на чистом C#

Смотрим, наслаждаемся, обучаемся.

День 1253. #ЗаметкиНаПолях #AsyncTips
Регулировка очередей

Задача
Имеется очередь «производитель/потребитель», но производители могут работать быстрее потребителей, что может привести к неэффективному использованию памяти. Также вам хотелось бы сохранить все элементы в очереди, а следовательно, требуется механизм регулировки производителей.

Решение
Если элементы производятся быстрее, чем потребители могут потреблять их, очередь придётся отрегулировать. Для этого можно задать максимальное количество элементов. Когда очередь будет «заполнена», она блокирует производителей, пока в очереди не появится свободное место.

Регулировка может выполняться посредством создания ограниченного канала (вместо неограниченного). Так как каналы асинхронны, производители будут регулироваться асинхронно:

var queue = Channel.CreateBounded<int>(1);
var writer = queue.Writer;
// Эта запись завершается немедленно.
await writer.WriteAsync(7);

// Эта запись (асинхронно) ожидает удаления 7
// перед тем как вставить в очередь 13.
await writer.WriteAsync(13);
writer.Complete();

Тип BufferBlock<T> также имеет встроенную поддержку регулировки, следует задать параметр BoundedCapacity:

var queue = new BufferBlock<int>(
  new DataflowBlockOptions 
  { 
    BoundedCapacity = 1 
  });

// Эта отправка завершается немедленно.
await queue.SendAsync(7);

// Эта отправка (асинхронно) ожидает удаления 7
// перед тем как ставить в очередь 13.
await queue.SendAsync(13);
queue.Complete();

Производитель в этом фрагменте кода использует асинхронный метод SendAsync.

Блокирующие очереди «производитель/потребитель» также поддерживают регулировку. Вы можете использовать тип BlockingCollection<T> для регулировки количества элементов, для чего при создании передается соответствующее значение:

var queue = new BlockingCollection<int>(boundedCapacity: 1);
// Это добавление завершается немедленно.
queue.Add(7);
// Это добавление ожидает удаления 7
// перед тем, как добавлять 13.
queue.Add(13);
queue.CompleteAdding();

Итого
Регулировка необходима в том случае, если производители работают быстрее потребителей. Один из сценариев, которые необходимо рассмотреть: могут ли производители работать быстрее потребителей, если ваше приложение будет работать на другом оборудовании? Обычно некоторая регулировка потребуется для того, чтобы гарантировать нормальную работу на будущем оборудовании и/или облачных платформах, которые нередко более ограничены в ресурсах, чем машины разработчиков.

Регулировка замедляет работу производителей, блокируя их, чтобы потребители гарантированно могли обработать все элементы без излишних затрат памяти. Если обрабатывать каждый элемент не обязательно, можно использовать выборку вместо регулировки (об этом в будущих постах).

См. также
- Асинхронные очереди
- Блокирующие очереди

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 9.

День 1254. #DDD
Обязанности Агрегатов в DDD
Агрегат происходит из DDD и предоставляет способ инкапсулировать бизнес-логику в нескольких связанных объектах.

Основные правила агрегатов:
1. Каждый агрегат имеет один корневой объект. Агрегаты называются по их корневому объекту.

2. Дочерние элементы агрегатов не сохраняются отдельно, а только как часть агрегата. Более того, доступ к ним также должен осуществляться только через агрегат.
Например, навигационные свойства должны существовать только от корней агрегатов к дочерним элементам (но не наоборот и не между агрегатами). Т.е. корень должен иметь возможность обращаться к любому из своих дочерних элементов, а дочерние элементы обычно имеют только свойство ID своего родителя.

3. Корень отвечает за валидность всего агрегата
Это не означает, что весь код должен находиться в корневом объекте. Корень может делегировать полномочия своим дочерним элементам при выполнении задач, за которые он отвечает.

Рассмотрим простой пример сущности Order, которая имеет коллекцию сущностей OrderItem. Order — корень:

public class Order
{
  // прочие свойства и методы опущены
  public IEnumerable<OrderItem> OrderItems { get; private set;}
}

public class OrderItem
{
  // прочие свойства и методы опущены
  public int ProductId { get; set; }
  public int Quantity { get; set; }
}

Некоторые типичные операции агрегата:
- создание нового заказа,
- добавление OrderItem в заказ,
- изменение количества в OrderItem.

Некоторые бизнес-правила:
- валидный заказ имеет хотя бы один OrderItem,
- валидная коллекция OrderItems не содержит повторяющихся ProductId,
- валидный OrderItem имеет положительное количество.

Очевидно, что Order здесь отвечает за первые 2 бизнес-правила, а вот за валидацию количества (и, возможно, других своих свойств) может (и должен) отвечать OrderItem. Можно, конечно, пойти дальше и использовать для свойства Quantity тип, не допускающий отрицательных значений, но сегодня не об этом.

Order, отвечающий за валидность всего агрегата, может при этом использовать поведение OrderItem. Ему не нужно проверять OrderItem извне, если он может быть уверен, что дочерний объект валиден. Вам же не нужно проверять, что свойство Month типа DateTime меньше 13. Тип делает эту проверку за вас, поэтому вы можете быть уверены, что месяц будет в допустимом диапазоне, если у вас есть экземпляр типа.

Многие разработчики также считают, что правило агрегата, гарантирующее, что весь агрегат является «действительным», требует метода для проверки достоверности. Иногда это полезно, но лучший дизайн — это тот, который изначально не допускает существования недопустимых значений. Снова рассмотрим тип DateTime. У него нет метода IsValid(), который вы вызываете после создания экземпляра, указав год, месяц и день как 2022, 50 и 50. Тип просто не позволит вам установить свои месяц или день в значение 50. Если вам удастся создать экземпляр DateTime, вы можете быть уверены, что он валиден, а также вы не сможете использовать ни один из его методов, чтобы поместить его в недопустимое состояние. Этот же подход нужно использовать со своими агрегатами и сущностями.

Итого
Корень агрегата отвечает за то, чтобы агрегат находился в допустимом состоянии. Но это не означает, что каждая операция, выполняемая над любым элементом агрегата, должна находиться в корне агрегата. Это также не означает, что агрегат должен иметь метод, выполняющий проверку. Использование надлежащего объектно-ориентированного дизайна и обеспечение того, чтобы ваши объекты инкапсулировали и управляли своим собственным состоянием, обеспечивает более чистый дизайн.

См. также Сущности и Объекты-Значения

Источник: https://ardalis.com/aggregate-responsibility-design/

День 1255. #Подкаст #Карьера
Сегодня попробую кое-что новое. Решил скачать и выложить здесь эпизод подкаста DotNetRocks, чтобы можно было послушать прямо в телеграме.

В этом эпизоде в гостях у ведущих была Хетер Даунинг. Она рассказала, как она «пришла в айти» и с какими трудностями сталкивалась:
- Как работать в устаревшем стеке и не терять мотивации?
- Как проходить собеседования?
Хороший совет – ходите, даже если не ищете работу. Чтобы поддерживать навык, быть в курсе требований, создавать новые связи. Будет проще, если ваше благополучие не зависит от того, как вы пройдёте это собеседование.
- Как реагировать, когда просят писать код на листочке?
- Как переходить из разработчика в тимлиды и управлять людьми вместо написания кода?
- Как изучать новую технологию, когда в наличии только плохая документация?
- Когда задумываться о пенсии?

Мне разговор понравился (извините, только на английском). Послушайте и скажите, как вам опыт подкастов здесь.

День 1256. #Книги
10 Книг Для Разработчика-Сеньора. Начало
Разработчики - прирождённые читатели, которые получают удовольствие, узнавая о новых вещах. А книги — идеальное средство для глубокого раскрытия сложных идей. Этот список содержит как классические, так и современные публикации, предназначенных для старших разработчиков.

1. Кент Бек «Экстремальное Программирование»
90-е были определяющей эпохой для разработки ПО. Бум доткомов создал огромное давление, заставляющее выпускать продукты раньше и чаще. Никогда прежде производительность не была столь важна для успеха в ИТ-индустрии.
Книга Кента Бека представила и усовершенствовала все agile-практики, которые сегодня считаются само собой разумеющимися: парное программирование, автоматизированное тестирование, разработка через тестирование и непрерывная интеграция.
Второе издание (насколько я знаю, его нет в переводе) уточняет первоначальную идею: быть в курсе, адаптироваться и меняться. Меняться не стыдно. Наоборот, быть готовым к изменениям — хорошая привычка для инженера.
Кент не углубляется в технические детали. Он обсуждает социальные аспекты разработки: взаимодействие с коллегами и руководством, трудовую этику, которой должны следовать программисты, и то, как плоская иерархия помогает всем работать над достижением общей цели.
Зачем читать: эта книга изменит ваше представление о разработке ПО всего на 200 страницах.

2. Джез Хамбл, Дэвид Фарли «Непрерывная Разработка ПО»
В этой книге Фарли и Хамбл выводят принципы непрерывной интеграции, представленные в книге «Экстремальное программирование», на новый уровень. Непрерывная доставка научит вас, как сделать выпуск и развёртывание простыми, как нажатие кнопки.
Посыл Джеза и Дэвида на первый взгляд может показаться нелогичным: «если это больно, делай это чаще и акцентируйся на боли». Заманчиво откладывать сложные части цикла разработки, но это не сделает их проще. Если интеграция болезненна, делайте её при каждом коммите. Если тестирование болезненно, делайте его постоянно, а не только в конце. Акцентируйтесь на боли: сначала делайте сложные вещи, и вам придётся столкнуться с трудностями и найти решения.
В книге очень подробно рассказывается о построении, структурировании и обслуживании конвейера доставки, в том числе о том, какие виды тестов использовать, как обрабатывать данные и как их развивать по мере роста проекта. Хотя некоторые инструменты, использованные в книге, немного устарели, её идеи и принципы вне времени. Это исчерпывающее руководство по DevOps, которое поможет вам перестать беспокоиться о развёртывании.
Зачем читать: любая команда, которая не читала эту книгу, ещё не достигла своего максимального потенциала.

3. Джейсон Фрайд, Дэвид Хайнемайер Хенссон «Remote. Офис не обязателен»
Если пандемия что и продемонстрировала, так это то, что удалённая работа — это не будущее, а настоящее. Мы были вынуждены работать из дома, и у нас было мало времени на адаптацию. Авторы показывают, как Basecamp стала полностью удалённой компанией.
Книга призвана побороть распространённые оправдания против удалённой работы: личное общение не незаменимо, а людям можно (и нужно) доверять, чтобы они продуктивно работали из дома.
Зачем читать: книга покажет руководителю, как выглядит успешная удалённая команда, а работнику - методы, которые помогают работать удалённо, избегая при этом ловушек, которые могут возникнуть в домашних офисах.

Продолжение следует…

Источник: https://semaphoreci.com/blog/books-every-senior-engineer-should-read

День 1257. #Книги
10 Книг Для Разработчика-Сеньора. Продолжение
Начало 1-3

4. Фредерик Брукс «Мифический человеко-месяц»
Можно прочитать о десятках историй успеха, а как насчёт историй неудач? Книга Брукса показывает опасности, с которыми приходится сталкиваться всем сложным проектам. Понятие «человеко-месяц» представляет собой ошибочную идею о том, что вы можете ускорить проект, добавляя людей в команду. Будучи менеджером проекта IBM OS/360, автор заметил, что вместо этого дополнительные люди привели к дальнейшей задержке проекта. Закон Брукса гласит, что «добавление рабочей силы к опаздывающему программному проекту задерживает его ещё больше».
Хотя вы можете быстрее вырыть канаву, добавив больше рабочих рук, некоторые задачи не выигрывают от добавления большего количества людей. По сути, чем сложнее задача, тем труднее разделить её на отдельные, распараллеливаемые задачи. Наблюдения автора и его понимание человеческой природы предлагают бесценные уроки по управлению жизненным циклом сложного проекта, управлению общением в команде, планированию и оценке рабочих графиков.
Зачем читать: прошло почти 50 лет с момента публикации этой книги, а мы всё ещё совершаем те же ошибки при управлении программными проектами. Эту поучительную историю должен прочитать хотя бы один раз каждый инженер.

5. Getting Real
Getting Real — бесплатная электронная книга о том, как сделать проекты простыми. Она побуждает пропускать многие этапы проектирования и приступать к созиданию как можно скорее, несмотря на призывы «создавать меньше, создавать проще», «быть минималистом» и «создавать инструмент, который соответствует вашим потребностям».
Книга делает упор на создание единых команд, разрушение разрозненности, доверие к самостоятельной работе людей и избегание собраний. Это набор правил, который сработал для Basecamp и может сработать для вас. Но даже если это не так, основные ценности, лежащие в основе этих принципов, стоит изучить.
Зачем читать: это серьёзная, но краткая книга о создании продуктов с помощью удалённой команды. Ещё и бесплатная!

6. Мартин Клеппман «Высоконагруженные приложения. Программирование, масштабирование, поддержка»
Знаменитая книга с кабанчиком. Данные — это кровь каждого приложения. Знание того, как проектировать большие наборы данных и управлять ими, является жизненно важным навыком для любого старшего инженера, которому рано или поздно придётся масштабировать систему. Книга Клепманна — это подробное руководство, охватывающее всё, начиная от моделей данных и баз данных SQL и NoSQL до очередей сообщений, распределённых систем и больших данных.
Основа книги – теория. Вы не найдёте ни кода, ни примеров. В то же время это практический текст, в котором рассматриваются компромиссы между несколькими типами технологий обработки данных.
Зачем читать: если вы разрабатываете приложения, потребляющие или обрабатывающие данные любого типа, эта книга поможет вам сбалансировать плюсы и минусы доступных технологий.

Окончание следует…

Источник: https://semaphoreci.com/blog/books-every-senior-engineer-should-read