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

[sukhanchik]

Для начала спасибо за столь развернутый ответ. Повторно репутацию увы поднять не могу, поэтому говорю просто спасибо .

Цитата:

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

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

Ну, логично - что разрешение должно быть получено раньше, чем использован соотв. API. Понятно - что это является "синхронизацией" с .NET. Просто пока не могу в голове смоделировать контрпример, в каких случаях этот механизм разрешений именно защитит пользователя от исполнения "опасного" кода. Т.е. представим себе - что все вызовы "опасных" функций обрамляются в разрешения. Чем такой "обрамленный" код отличается от "необрамленного"? Только кол-вом кода, генерацией security cookie и т.д. Т.е. все равно кол-во "опасных" вызовов при этом не уменьшится. Не вижу предпосылок уменьшения использования "опасного" кода при этом программисту. Ну если нет аналога функции WinAPI::findWindow (к примеру) - а вызвать надо то хоть тресни - программисту придется ее вызвать - хоть с "обрамлением", хоть с бантиками, хоть завернутую в подарочную упаковку.

Цитата:

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

Насколько я понимаю, "ноги" этих разрешений растут из .NET с его managed code. Не забывайте, что как код Х++ может вызывать .NET-сборки, так и внешний код может вызывать код Х++ через Business Connector, может, дело в этом...

Об этом не подумал, спасибо. С этим согласен. В свое время в Access-е столкнулся с вызовом SQL-VBA-SQL и VBA-SQL-VBA - в этой конструкции Access просто вылетал с предложением послать все в MS.

Цитата:

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

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

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

Цитата:

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

Ради взаимодействия с CLR

.NET - рулит и все такое... Понятно...

В общем - резюмируя могу сказать - что пока по крайней мере можно предположить защиту от повторных вызовов X++ - .NET - X++. Хотя фантазии пока хватает на пределе. Т.е. конкретно для этого случая - можно заложить разрешения. Во всем остальном, особенно с ограничениями на серверный/клиентский вызов - не очень понятно. Не всегда ж "опасные" функции вызываются через .NET - иногда и сами по себе .