Ну, есть способ делать это с помощью dependency container. Для каждого события создаётся свой интерфейс-слушатель (какой-нибудь ISomeEventHandler). Все, кто хочет слушать это событие, реализуют этот интерфейс и регистрируются в контейнере. Когда кому-то нужно сгенерировать данное событие, он выгребает из контейнера всё, что реализует данный интерфейс, и передаёт им данные события.
Вероятно, вы правы, и пример не из лучших. Но целью статьи было рассмотрение возможностей LiteDb. Кроме того, не хотелось бы подгонять структуру классов под структуру хранения. Имя свойства Password на мой взгляд более говорящее, чем общее Text. Поэтому такого выноса свойств в базовый класс я не люблю.
Я думаю, что отправка уведомлений с помощью MediatR будет для вас проще, чем с использованием Reactive. В случае Reactive вам необходимо будет и в местах отправки уведомлений, и в местах подписки на них иметь ссылки на объекты Reacitve (например, на ISubject). В случае MediatR нужно только иметь ссылку на IMediator и только в местах отправки уведомлений.
С другой стороны, основной проблемой с MediatR для вас, скорее всего, будет регистрация правильных обработчиков уведомлений в вашем контейнере зависимостей.
Сам код сервера ничего о клиентском сертификате ничего не знает. Чтобы проверка клиентского сертификата на стороне сервера прошла, необходимо сделать следующее. Либо вы добавляете сам клиентский сертификат в хранилище доверенных сертификатов (Trusted Root Certification Authorities) на сервере. Либо, если ваш клиентский сертификат не является самоподписанным, а подписан другим сертификатом, то в это хранилище на сервере можно поместить тот сертификат, которым вы подписывали клиентский сертификат (или вообще любой сертификат вверх по цепочке подписывания). В этом случае сам клиентский сертификат на сервере не нужен.
Вопрос 2. Собственно, ответ такой же. На стороне клиента должен присутствовать либо сам серверный сертификат, либо один из его цепочки подписывающих сертификатов.
Вопрос 3. Действительно, некоторая специфика есть.
Если вы устанавливаете серверный сертификат на клиента, то вам не нужно иметь в нём закрытый ключ. Поэтому можно выбрать любой формат, который содержит только публичный ключ. По крайней мере, я так полагаю. Но обычно распространяют не сами клиентские или серверные сертификаты, а подписывающие их сертификаты. Это намного удобнее.
Кроме того, когда вы разнесли клиент и сервер по разным машинам, вы уже не можете обращаться с клиента на сервер по имени localhost. Поэтому в генерируемых для этой задачи сертификатах поля subject и DNS Name должны содежать правильные значения (т. е. сетевое имя машины-сервера).
Ну и всё то, что написано выше про установку сертификатов в доверенное хранилище, тоже имеет место.
Вопрос 4. Насколько мне известно, самоподписанные сертификаты действительно используются только для тестирования. Но в принципе это нормальные сертификаты. Если вы решите проблему их установки на нужные машины и своевременного обновления, то можно их использовать. Хотя зачем это нужно, если есть более удобные и надёжные средства, не понятно.
Тут в голову пришло, что такая штука, как Fiddler, использует вроде бы самоподписанный сертификат для перехвата SSL-трафика (т. е. фактически для реализации атаки "человек посередине", описанной в статье). Но это, конечно, экзотический сценарий.
Вопрос 5. Честно говоря, сам я не сталкивался с системами, использующими клиентские сертификаты. Только познакомился с этим в том курсе Pluralsight, о котором говорится в статье. Скорее всего, это какие-то приложения, обладающие повышенными требованиями к безопасности. Ну вот, например, такой вариант. Вы хотите, чтобы ваш клиент работал исключительно на подконтрольных вам устройствах. Вы боитесь, что если клиент станут использовать все, кто хочет, с любой машины, безопасность вашей системы пострадает. Поэтому вы ставите клиентские сертификаты на все компьютеры ваших сотрудников и заставляете систему проверять их. В результате клиент не сможет соединиться с сервером ни с одной машины, на которой нет правильного клиентского сертификата.
Спасибо вам за предложения по расширению статьи. Могу сказать по ним следующее:
Да, с сертификатами можно работать на уровне Web-сервера (IIS, nginx), а не приложения. Обычно так и делают в промышленных системах. В результате проверкой сертификата занимается Web-сервер, а не ваше приложения. Это позволяет сделать код вашего приложения проще, а обработку запросов - быстрее. Кроме того, ответственность за правильную проверку сертификатов переносится на разработчиков Web-сервера, которые, хочется надеяться, обладают соответствующей квалификацией.
Возможным недостатком такого подхода может являться необходимость проверять в приложении некоторые поля сертификата, а затем использовать значения этих полей в коде приложения. Хотя, я уверен, вполне можно настроить Web-сервер так, чтобы он передавал сертификат вашему приложению, а не терминировал SSL на своём уровне. С другой стороны, если вашему приложению всё равно придётся проверять сертификат, зачем это делать на стороне Web-сервера...
Если у вашего сервера много экземпляров, то да, на всех них нужно установить серверный сертификат. Я думаю, что он должен быть один и тот же для всех экземпляров. Не знаю, как поведут себя клиенты, если в ответ на разные запросы к одному и тому же серверу будут приходить разные, хотя и валидные, сертификаты. С другой стороны, происходит же что-то подобное в момент, когда мы заменяем сертификат сервера из-за окончания его срока службы.
Вы правы, так и делают в рабочих системах. Но подобный подход не очень хорош для обучения. Он, фактически, говорит разработчикам: "Знаете, вам не нужно беспокоиться обо всех этих сертификатах. Хостинг-провайдеры сделают всё это за вас". Цель у статьи была несколько иная - дать базовую информацию, полезную для новичков. Как я и говорил, профессионалы вряд ли найдут в ней что-то полезное.
Да, на production мы тоже используем поддержку сертификатов от провайдера, насколько мне известно. Но на компьютерах разработчиков хостим ASP.NET Core через IIS.
Вы совершенно правы, использование await было бы более удобным. Я писал об этом в пункте 5 раздела "Направления дальнейшего развития". Лучше определить интерфейсы hook'ов через Task:
public interface IPreCommitHook
{
Task<bool> Process(IList<string> args);
}
Тогда в их реализации можно свободно использовать async/await.
Тем не менее, насколько мне известно, сами hook'и не подерживают асинхронные операции, поэтому где-то всё равно придётся дожидаться окончания работы задач.
Ничего не мешает, если вы хотите видеть в логах записи и от «хороших», и от «плохих» запросов. Если же вам нужны только записи из «плохих» запросов, то их нужно как-то пометить. Тогда эти «метки» можно будет использовать в фильтрах логов.
Если на production установить причину проблемы можно только по записям с уровнем Info и серьезнее, то никакой надобности в изменении конфигурации логгеров нет. Но если этого не достаточно, и мы считаем, что записи уровней Trace и Debug могут нам помочь, то здесь нужно что-то делать.
Да, вы правы, можно для этой цели использовать фильтрацию NLog, как предложили выше.
Да, согласен. Вместо изменения уровня логирования всего лога, можно прописывать специальные значения для некоторого свойства в асинхроном контексте, а в конфигурационном файле прописать несколько вариантов logger с разными фильтрами для разных значений этого свойства. Вы правы, это решит ряд проблем.
Сделал.
Если вам нужен
int, вы не подключаетеStringEnumConverterи пользуетесь числами.Да. Но у вас больше контроля за тем, как это всё работает. Но в конце концов решать вам, что использовать.
Ну, есть способ делать это с помощью dependency container. Для каждого события создаётся свой интерфейс-слушатель (какой-нибудь
ISomeEventHandler). Все, кто хочет слушать это событие, реализуют этот интерфейс и регистрируются в контейнере. Когда кому-то нужно сгенерировать данное событие, он выгребает из контейнера всё, что реализует данный интерфейс, и передаёт им данные события.Вы правы, я не сталкивался с этим инструментом.
Вероятно, вы правы, и пример не из лучших. Но целью статьи было рассмотрение возможностей LiteDb. Кроме того, не хотелось бы подгонять структуру классов под структуру хранения. Имя свойства
Passwordна мой взгляд более говорящее, чем общееText. Поэтому такого выноса свойств в базовый класс я не люблю.Нет никаких проблем с использованием SqLite. Просто хотелось чего-нибудь нового.
Похоже, нет.
Я думаю, что отправка уведомлений с помощью MediatR будет для вас проще, чем с использованием Reactive. В случае Reactive вам необходимо будет и в местах отправки уведомлений, и в местах подписки на них иметь ссылки на объекты Reacitve (например, на ISubject). В случае MediatR нужно только иметь ссылку на IMediator и только в местах отправки уведомлений.
С другой стороны, основной проблемой с MediatR для вас, скорее всего, будет регистрация правильных обработчиков уведомлений в вашем контейнере зависимостей.
Спасибо за отзыв!
Вот что я могу сказать по поводу ваших вопросов.
Вопрос 1. Вы правы, на стороне сервера важной является строчка
Сам код сервера ничего о клиентском сертификате ничего не знает. Чтобы проверка клиентского сертификата на стороне сервера прошла, необходимо сделать следующее. Либо вы добавляете сам клиентский сертификат в хранилище доверенных сертификатов (Trusted Root Certification Authorities) на сервере. Либо, если ваш клиентский сертификат не является самоподписанным, а подписан другим сертификатом, то в это хранилище на сервере можно поместить тот сертификат, которым вы подписывали клиентский сертификат (или вообще любой сертификат вверх по цепочке подписывания). В этом случае сам клиентский сертификат на сервере не нужен.
Вопрос 2. Собственно, ответ такой же. На стороне клиента должен присутствовать либо сам серверный сертификат, либо один из его цепочки подписывающих сертификатов.
Вопрос 3. Действительно, некоторая специфика есть.
Если вы устанавливаете серверный сертификат на клиента, то вам не нужно иметь в нём закрытый ключ. Поэтому можно выбрать любой формат, который содержит только публичный ключ. По крайней мере, я так полагаю. Но обычно распространяют не сами клиентские или серверные сертификаты, а подписывающие их сертификаты. Это намного удобнее.
Кроме того, когда вы разнесли клиент и сервер по разным машинам, вы уже не можете обращаться с клиента на сервер по имени localhost. Поэтому в генерируемых для этой задачи сертификатах поля subject и DNS Name должны содежать правильные значения (т. е. сетевое имя машины-сервера).
Ну и всё то, что написано выше про установку сертификатов в доверенное хранилище, тоже имеет место.
Вопрос 4. Насколько мне известно, самоподписанные сертификаты действительно используются только для тестирования. Но в принципе это нормальные сертификаты. Если вы решите проблему их установки на нужные машины и своевременного обновления, то можно их использовать. Хотя зачем это нужно, если есть более удобные и надёжные средства, не понятно.
Тут в голову пришло, что такая штука, как Fiddler, использует вроде бы самоподписанный сертификат для перехвата SSL-трафика (т. е. фактически для реализации атаки "человек посередине", описанной в статье). Но это, конечно, экзотический сценарий.
Вопрос 5. Честно говоря, сам я не сталкивался с системами, использующими клиентские сертификаты. Только познакомился с этим в том курсе Pluralsight, о котором говорится в статье. Скорее всего, это какие-то приложения, обладающие повышенными требованиями к безопасности. Ну вот, например, такой вариант. Вы хотите, чтобы ваш клиент работал исключительно на подконтрольных вам устройствах. Вы боитесь, что если клиент станут использовать все, кто хочет, с любой машины, безопасность вашей системы пострадает. Поэтому вы ставите клиентские сертификаты на все компьютеры ваших сотрудников и заставляете систему проверять их. В результате клиент не сможет соединиться с сервером ни с одной машины, на которой нет правильного клиентского сертификата.
Спасибо вам за предложения по расширению статьи. Могу сказать по ним следующее:
Да, с сертификатами можно работать на уровне Web-сервера (IIS, nginx), а не приложения. Обычно так и делают в промышленных системах. В результате проверкой сертификата занимается Web-сервер, а не ваше приложения. Это позволяет сделать код вашего приложения проще, а обработку запросов - быстрее. Кроме того, ответственность за правильную проверку сертификатов переносится на разработчиков Web-сервера, которые, хочется надеяться, обладают соответствующей квалификацией.
Возможным недостатком такого подхода может являться необходимость проверять в приложении некоторые поля сертификата, а затем использовать значения этих полей в коде приложения. Хотя, я уверен, вполне можно настроить Web-сервер так, чтобы он передавал сертификат вашему приложению, а не терминировал SSL на своём уровне. С другой стороны, если вашему приложению всё равно придётся проверять сертификат, зачем это делать на стороне Web-сервера...
Если у вашего сервера много экземпляров, то да, на всех них нужно установить серверный сертификат. Я думаю, что он должен быть один и тот же для всех экземпляров. Не знаю, как поведут себя клиенты, если в ответ на разные запросы к одному и тому же серверу будут приходить разные, хотя и валидные, сертификаты. С другой стороны, происходит же что-то подобное в момент, когда мы заменяем сертификат сервера из-за окончания его срока службы.
Благодарю за ваш отзыв.
Мы редко пользуемся HttpClient напрямую, обычно используем Refit. Но есть статья от Microsoft на интересующую вас тему.
Вы правы, так и делают в рабочих системах. Но подобный подход не очень хорош для обучения. Он, фактически, говорит разработчикам: "Знаете, вам не нужно беспокоиться обо всех этих сертификатах. Хостинг-провайдеры сделают всё это за вас". Цель у статьи была несколько иная - дать базовую информацию, полезную для новичков. Как я и говорил, профессионалы вряд ли найдут в ней что-то полезное.
Да, на production мы тоже используем поддержку сертификатов от провайдера, насколько мне известно. Но на компьютерах разработчиков хостим ASP.NET Core через IIS.
Вероятно, в реальных ситуациях так и делают. Но я не специалист по nginx, так что описывал те технологии, с которыми знаком.
Вы совершенно правы, использование await было бы более удобным. Я писал об этом в пункте 5 раздела "Направления дальнейшего развития". Лучше определить интерфейсы hook'ов через Task:
Тогда в их реализации можно свободно использовать async/await.
Тем не менее, насколько мне известно, сами hook'и не подерживают асинхронные операции, поэтому где-то всё равно придётся дожидаться окончания работы задач.
Да, вы правы, можно для этой цели использовать фильтрацию NLog, как предложили выше.