2015-04-24 2 views
1

Для текущего проекта мы используем Olingo поверх спящего режима и picketlink для обеспечения безопасности и ролей.Как добавить пользовательские атрибуты в метамоду в Olingo?

Пользователи с разными ролями будут иметь разные разрешения, которые влияют на доступ к чтению и записи определенным свойствам. Рассмотрим следующий пример:

  • один субъект «Лицо» с «именем» свойства, «адрес» и «зарплаты»
  • две роли - «Сотрудник» и «менеджер»

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

Это не проблема на бэкэнд - мы можем использовать выборочную проверку компонентов там, чтобы обеспечить разрешение на запись.

Но я хочу, чтобы интерфейс мог отражать права пользователей - отключив текстовое поле «зарплата», например, или не отображая его в первую очередь.

Для этого я хотел бы представить пользовательские атрибуты на основе пользовательских разрешений в метаданных oData. Вместо

<Property Name="Address" Type="Edm.String" Nullable="false"/> 

Я хотел бы получить

<Property Name="Address" Type="Edm.String" Nullable="false" Mode="readwrite"/> 

Или что-то к тому же эффекту.

Итак, вопрос в том, как ввести пользовательские атрибуты в мою метаданные oData с Olingo?

Пожалуйста, не используйте приведенный выше пример слишком серьезно. Я понимаю, что просто говорит интерфейс любезно не показывать зарплату другим с помощью мета-модели небезопасен;)

Update:

Хорошо, это не так просто. Я понимаю это сейчас. Атрибуты, которые я упоминал ранее, называются «грани» в CDSL (на которых oData покоится (каламбур)), и, как оказалось, существует фиксированный набор типов фасетов. Следовательно, Olingo не сильно беспокоится об абстракции, вместо этого вы найдете много hardcoded. Я предполагаю, что было бы возможно добавить еще один тип фасета, но это потребует трогания Olingo во многих местах. И это исключило бы соответствие с CDSL/oData - что бы меня не волновало, но которое может объяснить отсутствие решений проблемы.

На данный момент похоже, что мне придется либо попытаться ввести другой аспект, либо перехватить и изменить исходящий xml.

Я не в восторге от любого варианта, поэтому ... Любой намек на лучшее решение по-прежнему будет более чем приветствуем!

ответ

-1

Оказывается, это фактически очень простой.

Olingo позволит вам расширить схему, реализовав JPAEdmExtension и ее метод expandJPAEdmSchema. Узнайте больше об этом here.

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