Пользователи и роли в контексте - PullRequest
Новая
       10

Пользователи и роли в контексте

0 голосов
/ 04 июня 2009

Я пытаюсь понять, как реализовать отношения пользователь / роль для приложения, которое я пишу. Слой персистентности - это хранилище данных Google App Engine, которое накладывает некоторые интересные (но в целом полезные) ограничения на то, что можно сделать. Любые мысли приветствуются.

Может быть полезно держать вещи очень конкретными. Я хотел бы, чтобы там были организации, пользователи, тестовый контент и тестовые администрации (записи тестов, которые были приняты) Пользователь может иметь роль участника (тестируемого), участника тестового материала или обоих. Пользователь также может быть членом нуля или более организаций. В роли участника пользователь может видеть предыдущие администрации тестов, которые он или она прошли. Пользователь также может видеть тестовую администрацию другого участника, если этот участник дал авторизацию пользователя. Пользователь может видеть тестовый материал, который был обнародован, и он или она может видеть ограниченный контент как участника во время конкретного администрирования теста, для которого этот пользователь был авторизован организацией. Как член организации пользователь может видеть ограниченный контент в роли участника, и он или она может или не может редактировать контент. В каждой организации должен быть один или несколько администраторов, которые могут определять, может ли участник просматривать и редактировать контент, а также определять, кто имеет права администратора. Также должен быть один или несколько суперпользователей всего приложения, которые могут устранять неполадки и решать проблемы. Члены организаций могут видеть администрации тестов, которые заинтересованные участники разрешили им видеть, и они могут видеть анонимные данные, если не было дано никакого разрешения. Пользователь не может видеть результаты теста другого пользователя ни при каких других обстоятельствах.

Поскольку в хранилище данных App Engine нет объединений, может потребоваться нормализовать вещи, как обычно, для типичной базы данных SQL, чтобы обеспечить быстрые запросы, которые проверяют разрешения (например, те, которые определяют, является ли ссылка должен отображаться).

Мои вопросы:

  1. Как мне двигаться дальше в этом? Должен ли я потратить много времени заранее, чтобы получить правильную модель, или я могу повторить несколько раз и постепенно добавить дополнительную сложность?
  2. У кого-нибудь есть общие идеи о том, как разбить вещи в этом случае?
  3. Существуют ли библиотеки GAE, которые обрабатывают роли способом, совместимым с этим устройством?

1 Ответ

1 голос
/ 04 июня 2009

Я не совсем уверен, что правильно понимаю ваши вопросы, но постараюсь ответить:

  1. Я всегда нахожу, что итеративное программирование легче тестировать и писать, так что это моя рекомендация.
  2. Я думаю, что у вас есть необходимые сущности, уже правильно разделенные, но я думаю, что вам нужна дополнительная сущность: Permission, которая определяет, что может делать каждая роль, каждая роль имеет ноль или более Permission ссылок. Просто помните, что для каждого отношения «многие ко многим» в GAE необходимо либо определить список ключей, либо отдельную сущность, которая будет посредником.
  3. Не то, что я знаю, но вы можете исследовать ролевые системы на основе Django и попытаться адаптировать решение на основе Django (поскольку Django существует дольше). Вы можете довольно легко взломать Django на GAE с помощью App Engine Patch .
...