Extensible storage

[Антон Останин]

Добрый день!
Вот мой код:

Код - C# [Выбрать]

1.             SchemaBuilder builder = new SchemaBuilder(schemaGuid);
2.             FieldBuilder fieldBuilder = builder.AddSimpleField("myField", typeof(String));
3.             builder.SetReadAccessLevel(AccessLevel.Public);
4.             builder.SetWriteAccessLevel(AccessLevel.Vendor);
5.             builder.SetVendorId("BlaBla");
6.  

Объясните, пожалуйста, про VendorId.
Как я понял он защищает от записи мое поле.
schema.VendorId - read only.
Он берет его из файла *.addin в  " <VendorId>BlaBla</VendorId>".
Как сделать так, чтобы задавать и  проверять его перед записью в мое поле?
А так получается, что пароль на запись можно подсмотреть в файле...

[Виктор Чекалин]

Антон, вообще идея действительно состояла в том, чтобы посторонний пользователь не смог читать или изменять данные в Extensible Storage. Если я правильно понимаю, то Autodesk планировали регистрировать VendorId и, таким образом просто так поставить любой VendorId не получится.
Об этом говорит нам цитата в файле справки:

The vendor id is the registered developer symbol. The registration interface is available at http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=1075006 Since vendor ids are not case sensitive, the string will be converted to upper case before it is stored in the schema.

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

[Антон Останин]

Виктор , VendorId  я могу указывать любой, регистрировать его не нужно. Просто он берется из файла манифеста. Тогда каким образом  защитить доступ к данным?

[Виктор Чекалин]

VendorId  я могу указывать любой, регистрировать его не нужно

Собственно я об этом и написал. Хотели одно, а получилось другое.

Тогда каким образом  защитить доступ к данным?

Уточню, действительно ли они забросили ли эту идею или нет.
А с другой стороны, что вы там такое собрались хранить, что это нужно защищать? ИМХО, это из области паранои.

Даже если можно указать любой VendorId, вы действительно считаете, что кто то будет специально менять VendorId своей надстройки, для того, чтобы изменить данные в вашем ExtensibleStorage?

[Антон Останин]

Я хочу что-то типа отличительного знака для автора.

[Виктор Чекалин]

Антон, а с текущей реализацией защиты вы проверяли работоспособность? Если закрыть глаза на то, что VendorId можно поставить любой, то работает защита на чтение/запись?

[Антон Останин]

Если указать неправильный VendorID, то доступ к данным закрыт.

[Пашин Евгений]

А на этом месте можно поподробнее? Очень важно понимать: смогу ли я добавлять данные в Extensible Storage, если там есть какая-то защита?

[Антон Останин]

Евгений, добавлять вы сможете. Защита распространяется на конкретную запись.

[Пашин Евгений]

Правильно ли я понимаю?
То есть я, к примеру, создал что-то вроде авторской подписи в виде инициалов, используя Extensible Storage и у семейства появляется <Entity> с полями <ExtensibleStorageField>, в которых указаны Имя, Фамилия, Отчество - это я всё к примеру. И я могу поставить cвойства <Read Access Granted> = False для <Entity>! Но сам <Entity>  я же могу удалить? Я не могу лишь только изменить запись в <ExtensibleStorageField>?

Защита распространяется на конкретную запись.

То есть на <Entity>?

[Пашин Евгений]

Евгений, добавлять вы сможете. Защита распространяется на конкретную запись.

Да, только что попробовал, просто появляется новая запись <Entity>.
А в имеющийся <Entity> можно будет что-то добавить или прочесть?

[Антон Останин]

Евгений, можно добавлять если знаете VendorID.

[Пашин Евгений]

Евгений, можно добавлять если знаете VendorID.

А без него никак?

[Антон Останин]

Евгений, без него мне выдавало ошибку доступа.

[Пашин Евгений]

Антон, а как тогда объяснить то, что я спокойно перезаписываю запись в Extensible Storage? Наверное потому, что Read Access и Write Access = True?