Как работают InteropPermission и fileIOPermission?

[Владимир Максимов]

1. Отдельные команды assert() - взаимоисключающие. Т.е. последующий assert() вызывает конфликт с ранее настроенным assert(). Непонятно, а какие же права надо настраивать? Будет ошибка "Multiple calls to CodeAccessPermission.Assert"

Если надо дать несколько разных типов прав, то используют специальную конструкцию CodeAccessPermission::assertMultiple() с переданным списком типов

2.
assert - это дать права
demand - это запросить права (проверить наличие), настроенные ранее.

Т.е. demand сам по себе никаких прав не дает. Это своеобразная "напоминалка" о том, что такие права надо бы дать ранее в коде.

Если в коде встречается fileIOPerm.demand(), то это означает, что где-то ранее должна была быть команда fileIOPerm.assert()

// check file I/O permission - обратите внимание на слово "check".

[Lankey]

Цитата:

Сообщение от Владимир Максимов

2.
assert - это дать права
demand - это запросить права (проверить наличие), настроенные ранее.

Т.е. demand сам по себе никаких прав не дает. Это своеобразная "напоминалка" о том, что такие права надо бы дать ранее в коде.

Если в коде встречается fileIOPerm.demand(), то это означает, что где-то ранее должна была быть команда fileIOPerm.assert()
.

Спасибо большое!

Не могли бы Вы пояснить немного:
1) Зачем существует demand, если уже и так запросили, что нужно, через assert ? Это как-то зависит от того, где запросили (на сервере или клиенте?) или у assert есть scope? Я же не "напоминаю" коду о том. что объявила перееменные или там вызывала функции ранее

Цитата:

Сообщение от Владимир Максимов

// check file I/O permission - обратите внимание на слово "check".

Я бы поняла, если бы была проверкка типа "If demand() = false" then asset() .... но так этот метод не используется.

2) Почему мы запрашиваем разными классами (InteropPermission и fileIOPermission), что логично, а вот убираем одной CodeAccessPermission::revertAssert(), а не отдельно fileIOPermission::revertAssert и InteropPermission ::revertAssert .

3) revertAssert , как я понимаю, отменит все запросы, даже те, что были наложены в вызывающей функции , а не текущей?

4) revertAssert зачастую в конце кода, где выше по тексту запросили уже права, не делается. Это ошибка или есть в этом логика?

[axm2017]

Цитата:

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

1) Зачем существует demand, если уже и так запросили, что нужно, через assert ?

Подозреваю что
Принудительно создает SecurityException во время выполнения, если все вызывающие методы, расположенные выше в стеке вызовов, не получили разрешения, указанного текущим экземпляром.
https://learn.microsoft.com/ru-ru/do...t-plat-ext-8.0

[sukhanchik]

Сразу оговорюсь - правильный ответ могут дать только архитекторы MS, которые задумывали эту логику. Нам лишь остается строить гипотезы. Тем не менее:

Цитата:

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

Не могли бы Вы пояснить немного:
1) Зачем существует demand, если уже и так запросили, что нужно, через assert ? Это как-то зависит от того, где запросили (на сервере или клиенте?) или у assert есть scope? Я же не "напоминаю" коду о том. что объявила перееменные или там вызывала функции ранее
Я бы поняла, если бы была проверкка типа "If demand() = false" then asset() .... но так этот метод не используется.

Полагаю, что это связано с тем, что разные разработчики пишут код. Одни пишут требования (demand), другие реализуют выдачу разрешений (assert).
Аналогию можно провести с абстрактными методами. Один разработчик пишет метод и добавляет ему модификатор abstract, а другой (создавая наследник класса) вынужден перекрывать абстрактный метод, т.к. это требование первоначального разработчика

Цитата:

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

2) Почему мы запрашиваем разными классами (InteropPermission и fileIOPermission), что логично, а вот убираем одной CodeAccessPermission::revertAssert(), а не отдельно fileIOPermission::revertAssert и InteropPermission ::revertAssert .

Классы InteropPermission и fileIOPermission являются наследниками CodeAccessPermission. Полагаю, что выдача разрешений специфична и зависит от типа разрешения, а отзыв разрешения мог быть реализован единым методом вне зависимости от типа разрешения. Точно также, как метод finalize() может быть реализован на базовом классе, а метод new мы выполняем индивидуально на каждом наследнике.

Цитата:

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

3) revertAssert , как я понимаю, отменит все запросы, даже те, что были наложены в вызывающей функции , а не текущей?
4) revertAssert зачастую в конце кода, где выше по тексту запросили уже права, не делается. Это ошибка или есть в этом логика?

Отменится последнее выданное разрешение в текущем методе. Тут есть некоторый момент... Разрешение отзывается по завершению метода. Аналог - переменные типа Class. В конце области видимости переменной - она сама уничтожается и нет необходимости вызывать метод finalize().
Т.е. "для красоты кода" - нужно выдавать разрешения и их отзывать. Но... если разрешения не отозвать - то код "не сломается", хотя всякие Best Practice конечно скажут, что выданное разрешение надо обязательно отозвать.