Комментарии 10
С подобными решениями на самом деле две проблемы:
- из-за того что мы работает с экземплярами объектов на сервере, протокол автоматически становится stateful, из-за чего потом лезет куча головной боли, возникающие при обрыве соединения (а он происходит и часто)
- Возможность дёргать произвольные свойства/методы произвольных типов вообще говоря является немаленькой такой дырой в безопасности, позволяющей проводить remote code execution атаки. Запуск под "ограниченным пользователем" тут не особо поможет, т. к.у вашего процесса уже есть права на работу с сетью, а если это не хелловорлд, то ещё и доступ к БД.
Ну для локал сервера разрыва соединения не замечал. Кроме всего есть режим с подключением отключением.
Есть System.IO.Pipes.dll в \.nuget\packages\System.IO.Pipes\4.3.0\ref\netstandard1.3\, но напрямую подключить не удалось.
Ну во первых это нужно для AppDomain, а для безопасности можно код выполнять в терминальной сессии, под определенными правами пользователя.
Есть System.IO.Pipes.dll в \.nuget\packages\System.IO.Pipes\4.3.0\ref\netstandard1.3\, но напрямую подключить не удалось.
Ну во первых это нужно для AppDomain, а для безопасности можно код выполнять в терминальной сессии, под определенными правами пользователя.
Кстати при работе в Web Api ты так же хранишь состояние сессии.
Если мы говорим об песочнице аналоге AppDomain, то на данный момент я не нашел, но с выходом NetStandard 2 и .net Core 2 то там уже вроде будут NamedPipes. Кроме того, можно отрыть только определенные порты.
Зачем песочнице доступ к БД? Суть AppDomain это возможность выгружать сборки, работа с нестабильным оборудованием с использованием натива. Если это не чужой код, то какие могут быть атаки. А проблема плагинов она будет и в моем решении и в обычном решении. Просто в моем решении можно прикрыть кучу дыр, за счет прав пользователя.
Если мы говорим об песочнице аналоге AppDomain, то на данный момент я не нашел, но с выходом NetStandard 2 и .net Core 2 то там уже вроде будут NamedPipes. Кроме того, можно отрыть только определенные порты.
Зачем песочнице доступ к БД? Суть AppDomain это возможность выгружать сборки, работа с нестабильным оборудованием с использованием натива. Если это не чужой код, то какие могут быть атаки. А проблема плагинов она будет и в моем решении и в обычном решении. Просто в моем решении можно прикрыть кучу дыр, за счет прав пользователя.
Кстати, что касается WFF, то можно ограничить число экспортируемых типов, необходимых для функционирования удаленного приложения. Все передаваемые типы легко контролируются.
Есть еще момент. Клиент на начальном этапе получает ссылку на тип со статическими методами. В данном случае GetType, GetAssembly. Никто не мешает поместить туда другой тип с другим набором методов. При этом несложно сделать универсальную сериализацию параметров на основе CopyTo добавив в перечисление EnumVar новое значение и при мериализации указвать это значение, затем строковое представление типа и сериализованное в Json строку значение. А эвены можно передавать на клиента отдельно.
То есть из существуещей разработки можно сделать различные варианты. Было бы желание.
То есть из существуещей разработки можно сделать различные варианты. Было бы желание.
Как то все сложновато)
Подумайте над API со стороны разработчика, только начинающего изучать ваш код — что бы можно было собрать рабочий пример буквально в 2 строчки на клиенте и сервере.
Подумайте над API со стороны разработчика, только начинающего изучать ваш код — что бы можно было собрать рабочий пример буквально в 2 строчки на клиенте и сервере.
Помоему все просто. Получаете тип создаете объекты. Единственно, что нет автоматической сериализации для не строк чисел, GUID и byte[]. По сравнению с WCF и Remoting все значительно проще.
Что в начальном примере непонятно?
Что в начальном примере непонятно?
Здесь еще один момент, по уму это все должна сделать MS. Ибо я никто и звать меня никак. А вещь нужная, при этом нет встроенной технологии типа Remoting. По сути введение псевдоинтерфейсов (аналог анотации типов в TypeScript) решают проблему типизации. Внутри то так или иначе тоже самое.
Плюс работа с Reflection. Если в большом .Net есть метод типа InvokeMember, то для .Net Core я сам реализовать поиск нужного метода, плюс поиск дженерик метода с выводом типа, поиск методов расширений итд. Это тоже было бы неплохо иметь в стандартных библиотеках как методы расширений по аналогии с GetTypeInfo.
У меня это все реализовано.
Плюс работа с Reflection. Если в большом .Net есть метод типа InvokeMember, то для .Net Core я сам реализовать поиск нужного метода, плюс поиск дженерик метода с выводом типа, поиск методов расширений итд. Это тоже было бы неплохо иметь в стандартных библиотеках как методы расширений по аналогии с GetTypeInfo.
У меня это все реализовано.
Использовать рефлексию на стороне сервера? Это же удар по производительности, вдовесок к тем минусам, которые описаны выше. Что-то подсказывает мне, что вы не с той стороны какую-то проблему решаете.
Угу. На самом деле удар по производительности это маршалинг. Для примера Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux
Скорость вызова из натива метода принимающего int и возвращающего int составляет порядка 500 000 вызовов в секунду. Для JavaScript- Native-Managed CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF
Составляет порядка 60 000 вызовов ( но например итератор поряка 170 000).
То для Tcp/Ip это порядка 14 000. Так, что затраты на Reflection минимальны, по сравнению с маршалингом.
Скорость вызова из натива метода принимающего int и возвращающего int составляет порядка 500 000 вызовов в секунду. Для JavaScript- Native-Managed CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF
Составляет порядка 60 000 вызовов ( но например итератор поряка 170 000).
То для Tcp/Ip это порядка 14 000. Так, что затраты на Reflection минимальны, по сравнению с маршалингом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
.Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед