Цитата:
Сообщение от
gl00mie
Здесь принципиально то, что контроль над использованием опасных API выносится с уровня приложения на уровень ядра и становится, таким образом, доступен пользователю (администратору). Так, к примеру, на уровень "ядра" вынесены различные настройки параметров безопасности MSIE, и можно вручную или групповыми политиками настроить, что делать можно, а чего нельзя, не ковыряясь в каждом отдельном сайте, страничке или Java-скрипте. Аналогично, может быть, в будущих версиях Аксапты можно будет настраивать на уровне конфигурационной утилиты, какие именно "опасные API" можно использовать, к каким ресурсам и какого рода доступ можно предоставлять с их помощью.
Если так - то теория ясна. Осталось посмотреть как это будет реализовано на практике. Т.е. пока в 4-ке по сути положено начало, а развитие следует ожидать дальше.... Хотя если честно - я тяжело себе представляю ограничение по использованию тех же WinAPI-функций - ибо среди них есть весьма мирные (типа вернуть текущее имя пользователя), а есть более опасные (типа завершения работы системы). Конечно я немного утрирую - но вряд ли будет в конфигурации всех API-функций. Максимум - сам факт их вызова. Ну если только на уровне самих функций будет определен уровень разрешения, который должен быть для возможности их запуска (аналогично свойству пункта меню NeedAccessLevel). Но в целом - понятно - т.е. пока закладывается фундамент дома - а какие башенки будут построены - будет видно в следующих версиях.
Цитата:
Сообщение от
gl00mie
Я тут подумал, что все же разница есть - именно применительно к разрешениям 
Предположим, что код приложения должен обратиться к какому-то файлу - для этого он запрашивает FileIOPermission с указанием, к какому именно файлу и в каком режиме (чтение, запись, добавление) код хочет обратиться. Если бы можно было получить разрешение на клиенте, а использовать его на сервере, то получилось бы, что проверка прошла бы для одного объекта (файла по тому пути, как он видится с машины клиента), а реальный доступ был бы осуществлен в общем случае к совершенно другому объекту (файлу по тому пути, как он видится на сервере, даже если это в точности такой же путь, что и на клиенте). Очевидно, такой ситуации допускать нельзя: к какому объекту запросили (и получили) разрешение на доступ, к тому и применяйте это разрешение. Отсюда, видимо, и ограничение, касающееся использования разрешения на том же уровне (на клиенте либо на сервере), на каком оно было получено. Логика-то ясна... но "красивые и чистые" мысли разбиваются о "грязную" необходимость сокращения нагрузки на клиента (да и вообще на сетевой траффик). Т.е. в то время когда все учат выносить всю работу с БД на сервер (что логично) - мы с т.з. безопасности делаем это на клиенте, т.к. именно клиент выбирает файл для импорта. Было бы логично как раз сборки .NET, dll-ки как раз подключать к серверу, хотя бы с т.з. проверки прав доступа. Одно дело - дать права только пользователю, от имени которого запущен АОС и другое дело - дать права некому полноценному конкретному пользователю (да еще если их много). Хотя - с т.з. безопасности - может последнее и правильно - по крайней мере контролируемо.
Цитата:
Сообщение от
gl00mie
Вспомнился почему-то дурацкий вопрос из экзамена по разработке, мол, если клиент жалуется, что форма работает слишком медленно, что вы предпримете. Вроде бы правильным ответом было поменять свойство формы, чтобы она выполнялась на сервере 
Просто у меня отношение к защите и безопасности - такое: Защита некоего действия не должна это действие отменять или запрещать.
Т.е. бессмысленно в рамках охраны человека его убивать, дабы это не сделали другие.
Бессмысленно в рамках защиты сервера полностью отключать к нему доступ.
Бессмысленно в рамках поддержки делать такую бюрократическую проволочку - что от момента заявки пользователя (в случае, если это останавливает его работу) до момента устранения заявки проходит такое кол-во времени, что ставит под сомнение необходимость его работы в системе.
Применительно к Аксапте - могу сказать - что каковы бы не были благородные намерения защищающих - но если в результате защиты нарушается принцип работы "вся работа с БД осуществляется на сервере" и работа сервера переносится на клиента - то в этом случае либо не нужна такая система, либо не нужна такая защита (в определенном смысле это же увеличивает стоимость владения системой - нужен новый комп, возможно и требуется обновление сетевого оборудования).