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

[GromRom]

Здравтвуйте коллеги!

Написал X++ код (DAX 4.0), который обращается к прокси-сборке web-сервиса узла SharePoint.

Если данный код работает со свойством RunOn == 'Called from' - то всё ок!
Если данное свойство поменять на Server, то выдаются вот такие страшные ошибки:

Сбой запроса на разрешение типа "InteropPermission".
(S)\Classes\InteropPermission\demand
(S)\Classes\CLRObject\new
(S)\Classes\ImportContractApprovalInfo_NV\new - line 24
(S)\Classes\ImportContractApprovalInfo_NV\main - line 38

Объект "CLRObject" не может быть создан

Вот эти самые line 24:

 //внешняя прокси-сборка, позволяющая работать с web-сервисом
    ImortApprovalInfo.ApprovalDocuments_ListService.Lists _listService;
;
  _listService = new ImortApprovalInfo.ApprovalDocuments_ListService.Lists();

1) что не так ?
2) как исправить?

[Yprit]

http://msdn.microsoft.com/en-us/library/bb190039.aspx

[kashperuk]

Ошибки не странные. Почитайте про Code Access Security, к примеру здесь:
http://msdn.microsoft.com/en-us/library/bb190039.aspx

О. Точно такая же ссылка выше

[GromRom]

Цитата:

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

http://msdn.microsoft.com/en-us/library/bb190039.aspx

Спасибо за ссылку!

Вставил пермишны:

   //проверяем возможность доступа к сборке
    perm = new InteropPermission(InteropKind::ClrInterop);
    if (perm == null)
    {
        return;
    }
    perm.assert();

После чего cборка начала работать в режиме "Server"

Однако обнаружил следующее некорректное поведение компонента ClrInterOp

Метод ClrInterop::isNull в режиме "Server" выдаёт стабильно true! Хотя, как видно из кода ниже, строка strOuterXml ВСЕГДА имеет осмысленные данные (ID="{BB80822A-7849-416B-9BF4-ECD83999F867}).

В режиме "Client" метод ClrInterop::isNull работает нормально, и выдаёт true или false в зависимости от реального сотояния объекта.

    System.Xml.XmlAttributeCollection  xacAttributes;
    System.Xml.XmlAttribute            xaAttribute;
 
    str strOuterXml;
    anytype ant;
    ;
 
    xacAttributes = ndListDefinition.get_Attributes();
    xaAttribute  =  xacAttributes.get_ItemOf("ID");
    strOuterXml = ClrInterOp::getAnyTypeForObject(xaAttribute.get_OuterXml());
    ant = ClrInterop::isNull(xaAttribute);
 
    if(!ClrInterop::isNull(xaAttribute))
    {
         _listID = xaAttribute.get_Value();
    }
    else
    {
        _listID = "-1";
    }

[sukhanchik]

Вот у меня та же проблема возникла, только при использовании ADO. (там использовался класс InteropPermission с типом InteropKind::ComInterop). Т.е. хоть тресни - не выдается разрешение при работе на сервере. Я не знаю - баг это или фича или я просто "не умею готовить", однако - этого поведения достаточно - чтобы я для себя сказал - мне эти разрешения не нужны - и хорошо - что есть возможность их отключить на уровне АОСа... и вообще - эти разрешения - есть вредная и дурацкая приблуда (совершенно не вижу логики в их наличии - только дополнительный код писать приходится).

Может конечно я и резко высказался - но пока я как-то не осознал их полезность и не понял - какой плюс - хотя бы с маркетинговой т.з. они привносят

Для отключения этих разрешений на уровне АОСа в реестре (конфигурации) нужно указать у параметра caslevel значение disable

PS. В приведенной ссылке выше написано "Code Access Security (CAS) helps protect APIs that have potential security risks ", т.е. как бы разрешения позволяют какие-то риски снизить. Вопрос. Какие риски можно снизить - если все равно все вызовы обрамляются в разрешения???. Т.е. теперь типа если увидел разрешения - значит есть некий потенциально рисковый вызов?. Если не обрамить вызов в разрешение - то вызова не произойдет. Вот я не понимаю этого искусственно выдуманного кода. Код-то не машина пишет - а человек

[Yprit]

Цитата:

Microsoft Dynamics AX code access security allows developers to protect dangerous APIs from being invoked by untrusted code (code that does not originate from the Application Object Tree (AOT)). Code access security does this by performing the following actions:
1. It verifies that the code asserted the appropriate permission on the call stack to use the dangerous API.
2. It verifies that the assert (the request to use the dangerous API) was executed in trusted code and saved in the AOT.
3. It verifies that the assert was executed on the same tier as the dangerous API.
For Dynamics AX version 4.0, code access security covers the use of dangerous APIs on the server tier only. You do not need to modify or mitigate client-only invocations of dangerous APIs.

см. также http://msdn.microsoft.com/en-us/library/930b76w0.aspx - ноги растут оттуда

Цитата:

To help protect computer systems from malicious mobile code, to allow code from unknown origins to run with protection, and to help prevent trusted code from intentionally or accidentally compromising security, the .NET Framework provides a security mechanism called code access security. Code access security allows code to be trusted to varying degrees depending on where the code originates and on other aspects of the code's identity. Code access security also enforces the varying levels of trust on code, which minimizes the amount of code that must be fully trusted in order to run. Using code access security can reduce the likelihood that your code can be misused by malicious or error-filled code. It can reduce your liability because you can specify the set of operations your code should be allowed to perform as well as the operations your code should never be allowed to perform. Code access security can also help minimize the damage that can result from security vulnerabilities in your code.

[GromRom]

Цитата:

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

см. также http://msdn.microsoft.com/en-us/library/930b76w0.aspx - ноги растут оттуда

Так почему же такое разное поведение метода в режимах "Client" и "Server" ???

[gl00mie]

Цитата:

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

В приведенной ссылке выше написано "Code Access Security (CAS) helps protect APIs that have potential security risks ", т.е. как бы разрешения позволяют какие-то риски снизить. Вопрос. Какие риски можно снизить - если все равно все вызовы обрамляются в разрешения???. Т.е. теперь типа если увидел разрешения - значит есть некий потенциально рисковый вызов?. Если не обрамить вызов в разрешение - то вызова не произойдет. Вот я не понимаю этого искусственно выдуманного кода. Код-то не машина пишет - а человек

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

[gl00mie]

Цитата:

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

Так почему же такое разное поведение метода в режимах "Client" и "Server" ???

Ну вот же написано в документации:

Цитата:

For Dynamics AX version 4.0, code access security covers the use of dangerous APIs on the server tier only. You do not need to modify or mitigate client-only invocations of dangerous APIs.

[Yprit]

Цитата:

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

Так почему же такое разное поведение метода в режимах "Client" и "Server" ???

Вообще-то мой пост был ответом sukhanchik'у

По приведенному куску кода однозначно сказать сложно. А что возвращает

CLRInterop::isInitialized(xaAttribute)

?

[sukhanchik]

Цитата:

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

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

Когда тебя двадцать раз спрашивают - это конечно напрягает - но смысл понять можно. Но когда ты пишешь код - то компилятор тебя двадцать раз не спрашивает. Да и в общем-то (как мне кажется) - одно дело Виста, которой пользуются миллионы пользователей разного уровня компьютерной грамотности и другое дело код Х++, которым пользуются (с т.з. разработки) в общем-то те люди, которые по определению понимают что они делают.
А потом - что значит "лишний раз подумать"? Если мне надо вызвать какую-то WinAPI-функцию или функцию из dll - что я сделаю? Ctrl+C, Ctrl+V из того места, где она работает и исправлю имя функции. Ну еще проверю - что все вызывается. Ну и какая разница сколько строчек кода я скопирую не глядя?

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

[sukhanchik]

Цитата:

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

1. It verifies that the code asserted the appropriate permission on the call stack to use the dangerous API.
2. It verifies that the assert (the request to use the dangerous API) was executed in trusted code and saved in the AOT.
3. It verifies that the assert was executed on the same tier as the dangerous API.

Это все конечно замечательно - что осуществляется такая проверка...
Но получается (если я правильно понял по аглицки):
1. Проверка, что код имеет соответствующее разрешение по стеку вызовов (интересно - какой стек вызовов должен быть, чтобы он не прошел проверку - просто без этого кода?)
2. Проверка, что вызов опасного API был вызван из "доверенного" кода, сохраненного в АОТ. А какой код не доверенный? Не сохраненный в АОТ?. Интересно - во-первых - как такой код исполняется (в Аксапте) и даже не столько это, а сколько то, что в Аксапте так просто создать код, сохраненный в АОТ и вызвать "опасный" код оттуда - что при желании так сделать - это сделать все равно можно.
3. Проверка, что код, вызывающий опасное API - вызывается это на той же стороне (клиент/сервер), что и само API. Вот это совсем непонятно.. Во первых вызвать код там где надо не составляет труда, а во-вторых - да какая разница?

Т.е. как бы получается - что эта проверка в общем-то ничего не дает. Только если самому что-то писать (какие-то свои проверки) - тогда проверка нужна... Но тут и вопрос - если самому писать - то зачем тогда поддержка на уровне ядра?

Или я что-то не так понял?

Попутно присоединяюсь к вопросу автора ветки - почему запрещено-таки вызывать такие вещи, как сборка .NET, как ADO с сервера?

[gl00mie]

Цитата:

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

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

Насколько я понимаю, принцип примерно такой:

• по ходу выполнения кода клиентом API запрашиваются разрешения на выполнение тех или иных действий (создается экземпляр CodeAccessPermission и дергается assert()) - это приводит к тому, что в стеке вызовов создается некий security cookie (видел такой термин в отладочной информации ядра 4-ки), соответствующий запрошенным разрешениям
• выше по стеку вызовов клиента API вызывается код, который использует некий API, требующий разрешений - при этом владелец API создает соотв. экземпляр класса-наследника CodeAccessPermission и дергает на нем метод demand()
• ядро пробегается по стеку вызовов вниз и ищет соотв. security cookie; соответствие определяется тем, что созданному во владельце API экземпляру класса-наследника CodeAccessPermission в метод isSubsetOf() подсовываются экземпляры запрошенных разрешений (созданных в клиенте API классов-наследников CodeAccessPermission)
• если в какой-то момент созданный владельцем API экземпляр вернет из isSubsetOf() true, то считается, что разрешение найдено, и дальше выполняется код API, следующий за вызовом demand()
• если на протяжении всего стека вызовов клиента API подходящий security cookie не найден, ядро выбрасывает исключение
• если код клиента API выходит из метода, в котором было запрошено разрешение (вызван assert()), то на созданных разрешениях вызывается revertAssert(), и security cookie удаляются; revertAssert() можно, конечно, вызвать и раньше, не дожидаясь выхода из метода. Таким образом, код клиента API, в который вернется управление из метода, запросившего разрешение, уже не сможет воспользоваться этим разрешением, потому что оно будет отсутствовать в стеке вызовов

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

Цитата:

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

2. Проверка, что вызов опасного API был вызван из "доверенного" кода, сохраненного в АОТ. А какой код не доверенный? Не сохраненный в АОТ?. Интересно - во-первых - как такой код исполняется (в Аксапте) и даже не столько это, а сколько то, что в Аксапте так просто создать код, сохраненный в АОТ и вызвать "опасный" код оттуда - что при желании так сделать - это сделать все равно можно.

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

Цитата:

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

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

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

Цитата:

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

Но тут и вопрос - если самому писать - то зачем тогда поддержка на уровне ядра?

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

[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 - иногда и сами по себе .

[gl00mie]

Цитата:

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

пока не могу в голове смоделировать контрпример, в каких случаях этот механизм разрешений именно защитит пользователя от исполнения "опасного" кода. Т.е. представим себе - что все вызовы "опасных" функций обрамляются в разрешения. Чем такой "обрамленный" код отличается от "необрамленного"? Только кол-вом кода, генерацией security cookie и т.д. Т.е. все равно кол-во "опасных" вызовов при этом не уменьшится.

Здесь принципиально то, что контроль над использованием опасных API выносится с уровня приложения на уровень ядра и становится, таким образом, доступен пользователю (администратору). Так, к примеру, на уровень "ядра" вынесены различные настройки параметров безопасности MSIE, и можно вручную или групповыми политиками настроить, что делать можно, а чего нельзя, не ковыряясь в каждом отдельном сайте, страничке или Java-скрипте. Аналогично, может быть, в будущих версиях Аксапты можно будет настраивать на уровне конфигурационной утилиты, какие именно "опасные API" можно использовать, к каким ресурсам и какого рода доступ можно предоставлять с их помощью.

Цитата:

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

нет разницы (в техническом плане) между исполнением кода на клиенте и на сервере. В обоих случаях посылается запрос на БД (мы ж не сравниваем исполнение кода на сервере БД и на клиенте).

Я тут подумал, что все же разница есть - именно применительно к разрешениям Предположим, что код приложения должен обратиться к какому-то файлу - для этого он запрашивает FileIOPermission с указанием, к какому именно файлу и в каком режиме (чтение, запись, добавление) код хочет обратиться. Если бы можно было получить разрешение на клиенте, а использовать его на сервере, то получилось бы, что проверка прошла бы для одного объекта (файла по тому пути, как он видится с машины клиента), а реальный доступ был бы осуществлен в общем случае к совершенно другому объекту (файлу по тому пути, как он видится на сервере, даже если это в точности такой же путь, что и на клиенте). Очевидно, такой ситуации допускать нельзя: к какому объекту запросили (и получили) разрешение на доступ, к тому и применяйте это разрешение. Отсюда, видимо, и ограничение, касающееся использования разрешения на том же уровне (на клиенте либо на сервере), на каком оно было получено.

Цитата:

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

Ккаким образом предполагается (предполагалось) контролировать - в каких условиях используется "опасное" API?

В примере защиты своего "опасного API" с помощью Code Access Security из Writing Secure X++ Code при запросе разрешения в конструктор класса-наследника CodeAccessPermission передаются некие данные, используемые затем для проверки наличия разрешения в ходе использования "опасного API". Так вот, этот пример, конечно, абстрактный, но, скажем, применительно к тому же FileIOPermission он уже обретает конкретику. Клиент API помимо типа разрешения еще и указывает, доступ какого рода и к какому именно ресурсу он хочет получить с помощью API. При этом "владелец" API может, скажем, по неким настройкам проверить, стоит ли давать доступ к этому ресурсу, например, можно ли пользователю, связанному с текущей сессией, давать доступ к тому или иному файлу на сервере от имени пользователя, под учетной записью которого работает AOS.

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

Здесь принципиально то, что контроль над использованием опасных API выносится с уровня приложения на уровень ядра и становится, таким образом, доступен пользователю (администратору). Так, к примеру, на уровень "ядра" вынесены различные настройки параметров безопасности MSIE, и можно вручную или групповыми политиками настроить, что делать можно, а чего нельзя, не ковыряясь в каждом отдельном сайте, страничке или Java-скрипте. Аналогично, может быть, в будущих версиях Аксапты можно будет настраивать на уровне конфигурационной утилиты, какие именно "опасные API" можно использовать, к каким ресурсам и какого рода доступ можно предоставлять с их помощью.

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

Цитата:

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

Я тут подумал, что все же разница есть - именно применительно к разрешениям Предположим, что код приложения должен обратиться к какому-то файлу - для этого он запрашивает FileIOPermission с указанием, к какому именно файлу и в каком режиме (чтение, запись, добавление) код хочет обратиться. Если бы можно было получить разрешение на клиенте, а использовать его на сервере, то получилось бы, что проверка прошла бы для одного объекта (файла по тому пути, как он видится с машины клиента), а реальный доступ был бы осуществлен в общем случае к совершенно другому объекту (файлу по тому пути, как он видится на сервере, даже если это в точности такой же путь, что и на клиенте). Очевидно, такой ситуации допускать нельзя: к какому объекту запросили (и получили) разрешение на доступ, к тому и применяйте это разрешение. Отсюда, видимо, и ограничение, касающееся использования разрешения на том же уровне (на клиенте либо на сервере), на каком оно было получено.

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

Цитата:

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

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

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

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

[sukhanchik]

В любом случае - очередной раз спасибо, gl00mie за потраченное время на разъяснение этого монстрового механизма.

[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-шки. А у новой системы и другая тенденция развития (на портал).
Что ж - бум пересматривать взгляды и ломать стереотипы

[rkorchagin]

Вопрос: а perm.assert(); должен стоять перед каждым обращением к COM? Или хватает 1 раз в начале?