ошибка обращения к .NET сборке в режиме Server

[gl00mie]

Цитата:

Сообщение от sukhanchik

я тяжело себе представляю ограничение по использованию тех же WinAPI-функций - ибо среди них есть весьма мирные (типа вернуть текущее имя пользователя), а есть более опасные (типа завершения работы системы). Конечно я немного утрирую - но вряд ли будет в конфигурации всех API-функций. Максимум - сам факт их вызова. Ну если только на уровне самих функций будет определен уровень разрешения, который должен быть для возможности их запуска (аналогично свойству пункта меню NeedAccessLevel).

Логика разработчиков и вообще "политика партии" может быть такая: зачем вам использовать WinAPI, если есть .NET? А в .NET вполне даже можно повесить разного рода ограничения и на каждый отдельный класс, и на каждый отдельный конструктор класса, и на каждый отдельный метод класса и рулить этим всем, опять же, через какие-нить групповые политики, см., например, SecurityPermissionAttribute, а также SecurityPermissionFlag. А использование WinAPI может со временем стать не соответствующим "политике партии" подходом, расцениваемым как потенциально опасный и рекомендуемым к отключению в настройках безопасности (если потом можно будет рулить настройками, какие CodeAccessPermission разрешать, а какие - нет).

Цитата:

Сообщение от sukhanchik

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

К вопросам импорта/экспорта данных можно подходить по-разному. К примеру, в теме экспорт в шаблон Excel обсуждался один из подходов: запихнуть данные в какой-нить Map, запаковать в контейнер и передать на другой уровень (с клиента на сервер или наоборот), а там уже обрабатывать - в базу импортировать или, там, в тот же Excel выводить...

Цитата:

Сообщение от sukhanchik

Просто у меня отношение к защите и безопасности - такое: Защита некоего действия не должна это действие отменять или запрещать.

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

Цитата:

Сообщение от sukhanchik

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

Вспоминается 4-е письмо о стратегии Джоэла Спольски:

Цитата:

The developers who put a lot of effort into optimizing things and making them tight and fast will wake up to discover that effort was, more or less, wasted, or, at the very least, you could say that it “conferred no long term competitive advantage,” if you’re the kind of person who talks like an economist.
The developers who ignored performance and blasted ahead adding cool features to their applications will, in the long run, have better applications.

Это к тому, что если создать сложную бюрократическую систему в рамках поддержки клиентов, то ее всегда можно улучшить и ускорить - зато вы сможете на основе собранных данных получать значения KPI во всех возможных разрезах и показывать результаты руководству, выбивая новый бюджет. А если такую систему не создать, то можно биться как рыба об лед, но любое недовольство клиента, который обратится на уровень выше, может привести к резонному вопросу руководства: "чем вы тут вообще, собственно, занимаетесь?!" - а ответить-то будет нечего

Цитата:

Сообщение от sukhanchik

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

Во-первых, это не совсем так: если есть определенные требования по безопасности, которые проверяются лишь на сервере, это вовсе не означает, что логику работы надо выносить на клиента - просто для того, чтобы не проходить дополнительные проверки. Во-вторых, с точки зрения безопасности подумайте вот о чем: тенденции развития той же Аксапты таковы, что значительная часть взаимодействия с конечными пользователями выносится на корпоративный портал. Это, с одной стороны, позволяет упростить доступ к системе (вспомним хотя бы тему Как дать доступ к Аксапте внешним пользователям?), с другой, сэкономить на лицензиях, поскольку лицензии на Business Connector на порядок дешевле "обычных" пользовательских лицензий. В то же время переход на Web-интерфейс означает значительное ослабление контроля за тем, что может и чего не может делать клиент: если я работаю через GUI-клиента, мне очень проблематично контролировать, что он там передает AOS'у, какие проверки вызывает и т.п., если же я работаю через Web-интерфейс, то я могу, к примеру, вручную набить и отправить http-запрос или даже могу поставить программку вроде Proxomitron и с ее помощью на лету кромсать, как мне вздумается, Java-скрипты в страничках, которые генерит движок корпоративного портала, формируя для меня тот самый Web-интерфейс, т.е. фактически могу произвольно относительно легко вмешиваться в работу клиентской части системы. Можно привести простой пример: есть такая служба размещения файлов в сети rapidshare, которая при скачивании файлов, если не купить premium-доступ, заставляет ждать энное количество секунд. Задержа прежде была реализована достаточно банально: в страничку, генерившуюся при запросе на скачивание файла, внедрялся Java-скрипт, который крутил пустой цикл указанное количество секунд и лишь затем показывал ссылку для скачивания. Обойти это было проще простого: с помощью того же Proxomitron'а делался фильтр, который по regexp'у искал этот скрипт и подменял начальное значение счетчика пустых циклов на ноль. В результате при доступе к rapidshare через Proxomitron в браузере сразу же показывалась ссылка для скачивания - без томительного ожидания. Т.е. фактически происходило вмешательство в логику работы клиентской части сервиса rapidshare (потом эту лазейку прикрыли, опять-таки, за счет дополнительной проверки на сервере). А теперь представьте, что таким же образом кто-то меняет логику работы клиентской части Аксапты, получая доступ к системе через корпоративный портал...

[sukhanchik]

Цитата:

Сообщение от gl00mie

Логика разработчиков и вообще "политика партии" может быть такая: зачем вам использовать WinAPI, если есть .NET? А в .NET вполне даже можно повесить разного рода ограничения и на каждый отдельный класс, и на каждый отдельный конструктор класса, и на каждый отдельный метод класса и рулить этим всем, опять же, через какие-нить групповые политики .... А использование WinAPI может со временем стать не соответствующим "политике партии" подходом, расцениваемым как потенциально опасный и рекомендуемым к отключению в настройках безопасности (если потом можно будет рулить настройками, какие CodeAccessPermission разрешать, а какие - нет).

Если смотреть на .NET в рамках отказа от WinAPI - то, безусловно, это позиция имеет право на жизнь. В конце концов .NET и создавали для создание машинно-независимых приложений.
В этом ключе вспоминается переход между DOS и Windows. Как было просто в DOSе и как сразу стали запрещены резидентные DOS-программы в Windows. В общем-то да - при эволюции всегда новое кажется ненужным, лишним и мешающим,однако - сейчас уже многие забыли или не знают как писать резидентные программы под DOS. И вроде как все без этого научились жить - в смысле приспособились к Windows. Значит и .NET приспособимся.

Цитата:

Сообщение от gl00mie

К вопросам импорта/экспорта данных можно подходить по-разному.

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

Цитата:

Сообщение от gl00mie

тенденции развития той же Аксапты таковы, что значительная часть взаимодействия с конечными пользователями выносится на корпоративный портал. Это, с одной стороны, позволяет упростить доступ к системе ..., с другой, сэкономить на лицензиях, поскольку лицензии на Business Connector на порядок дешевле "обычных" пользовательских лицензий. В то же время переход на Web-интерфейс означает значительное ослабление контроля за тем, что может и чего не может делать клиент

Ну если рассуждать с этой т.з. - то да, конечно - безопасность должна быть выше.
В принципе - понятно - что все развивается - и 4-ка - это некий полуфабрикат той же 5-ки (2009), которая в свою очередь будет бета-версией для 6-рки и только где-то к 7-й версии все боле менее устаканится.
Просто по сравнению с 4-ркой - 3-шка выглядела условно-законченным продуктом, в котором технологии были развиты до некоего потолка и закончены. И упор делался на функционал.
А 4-рка - это первые предпосылки к 7-й версии .

В общем-то понятно. Надо просто на 4-ку смотреть не столько как на развитие 3-шки, сколько на новую систему, смоделированную на базе 3-шки. А у новой системы и другая тенденция развития (на портал).
Что ж - бум пересматривать взгляды и ломать стереотипы