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

[Lankey]

AX2009
Помогите, пожалуйста, понять, как работают InteropPermission и fileIOPermission?

Есть Job. Мне нужно получить путь к временной папке, независимо от того, где исполняется код: на сервере или клиенте.
Для тестирования написала Job запускаю через menuItem c calledFrom = server для исполнения на сервере. И просто по F5 для исполнения на кленте

static server void My_test (Args _args)
{
    FilePath                      tmpPath;
    FileIOPermission        fileIOPermission;
    InteropPermission       perm;
;
   // perm = new InteropPermission(InteropKind::ClrInterop);
   // perm.assert();
    fileIOPermission = new FileIOPermission('','r');
    fileIOPermission.assert();
    if(isRunningOnServer())
    {
        info(strFmt('Server'));
        tmpPath = WinAPIServer::getTempPath();
    }
    else
    {
        info(strFmt('Client'));
        tmpPath = WinAPI::getTempPath(); 
    }
    //CodeAccessPermission::revertAssert();
    info(strFmt('tmpPath %1', tmpPath));

Вопросы
1 ) Почему, если я убираю

    fileIOPermission = new FileIOPermission('','r');
    fileIOPermission.assert();

перед if(isRunningOnServer()) , то
получаю ошибку
Request for the permission of type 'FileIOPermission' failed.
(S)\Classes\FileIOPermission\demand
(S)\Classes\WinAPIServer\getTempPath - line 13

То есть, если в моем коде есть FileIOPermission, то вторичный FileIOPermission, что внутри tmpPath = WinAPIServer::getTempPath(); отрабатывает. А как только свои две строки убираю, то выдается эта ошибка.

2) Почему я не могу раскомментировать строки

// perm = new InteropPermission(InteropKind::ClrInterop);
   // perm.assert();

Как только я это делаю, то получаю ошибку (причем, и когда на клиенте исполяняю, и когда на сервере)
Multiple calls to CodeAccessPermission.Assert
(S)\Classes\FileIOPermission\assert
(S)\Jobs\My_test - line 38
(S)\Classes\MenuFunction\runServer

Спасибо

[Lankey]

Для наглядности, вот код WinAPIServer::getTempPath()

#define.maxPath(260)
public server static str getTempPath()
{
    FileIOPermission fileIOPerm;
    InteropPermission interopPerm;
    str tempPath;
     // check file I/O permission
    fileIOPerm = new FileIOPermission('','r');
    fileIOPerm.demand();
    // get dll interop permission
    interopPerm = new InteropPermission(InteropKind::ClrInterop);
    interopPerm.assert();
    tempPath = System.IO.Path::GetTempPath();
    CodeAccessPermission::revertAssert();
    return tempPath;
}

[Lihgt]

#define.maxPath(260)
public server static str getTempPath(boolean _setPermission = true)
{
    FileIOPermission fileIOPerm;
    InteropPermission interopPerm;
    str tempPath;
    Set                 permissionSet;
    ;
    permissionSet = new Set(Types::Class);
    if(_setPermission)
    {
         // check file I/O permission
        permissionSet.add( new FileIOPermission('','r'));
        //fileIOPerm = new FileIOPermission('','r');
        //fileIOPerm.demand();
    }

    // get dll interop permission
     permissionSet.add(new InteropPermission(InteropKind::ClrInterop));
    //interopPerm = new InteropPermission(InteropKind::ClrInterop);
    //interopPerm.assert();

    CodeAccessPermission::assertMultiple(permissionSet);

    tempPath = System.IO.Path::GetTempPath();
    return tempPath;
}

[Lankey]

Спасибо за пример, но мой код , приведенный выше, тоже работает
Я хочу понять, как работают InteropPermission и fileIOPermission,
Тк не понимаю, откуда получаются вышеприведенные ошибки, когда меняю код указанным образом

В вашем примере, кстати, есть закомменченные demand и assert. Вы можете объяснить, когда использутее demand, а когда assert?

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

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 конечно скажут, что выданное разрешение надо обязательно отозвать.