[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

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

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