Разрешения Django для разных клиентов

Question

Я работаю над проектом Django, который возьмет на себя фирмы как клиенты, и каждому клиенту будет разрешено создавать несколько пользователей. Затем этим пользователям могут быть назначены разные разрешения или роли.

Уловка заключается в том, что тип разрешений зависит от клиентов, то есть они не такие простые, как чтение, запись, удаление. Следовательно, у одного клиента может быть только 5-10 типов разрешений, а у другого может быть 100.

Встроенная база разрешения Django напрямую не поддерживает мою USECASE, так это то, что я придумал:

1. Создать главное приложение Джанго в котором находится модель пользователя
2. Для каждого нового клиента, создать новое приложение django с только models.py
3. В Model.py есть только одна модель (на данный момент), которая сама по себе содержит разрешения, специфичные для этого клиента, как объяснено here.
4. Теперь я могу назначить каждому пользователю разрешения в зависимости от того, с каким клиентом находится пользователь.

Пока я его не тестировал, это должно сработать. Решение выглядит масштабируемым, но есть много несоответствий, и это не похоже на правильный способ сделать это. Есть ли работа?

Обновление: django-guardian похоже, что это может помочь, а не как.

Обновление: Я думаю, что я объясню всю архитектуру, потому что текущее решение не работает непосредственно для нее.

1. Имеются потоки данных временных рядов с данными, поступающими через равные промежутки времени. Каждый клиент может иметь от 100 до более 1000 таких потоков. Однако эти потоки не сохраняются в БД веб-серверов, а сохраняются в каждом клиенте разные БД.
2. Теперь пользователь может иметь привилегии для просмотра всего, одного или некоторых из вышеперечисленных потоков. Клиент позволяет нам узнать о типе пользователя, которого они хотят создать, и мы создаем его соответствующим образом.
3. Для целей аутентификации лучше иметь всех пользователей в одной таблице. Но для авторизации имеет смысл иметь каждого клиента в отдельной таблице. Лучше всего, на мой взгляд, отделить клиентов.
4. Немного не по теме, но мы смотрели на предоставление каждому клиенту отдельного со-домена, такого как client1.mysite.com, client2.mysite.com и т. Д., И, следовательно, у нас есть свобода развертывания различных веб-серверов для каждого клиента и, следовательно, настроить его для каждого клиента. Кроме того, это помогает хранить данные каждого клиента по-разному.

Answer 1

Я действительно не нравится ваше решение - это похоже на старые конструкции базы данных, где схемы chnges были ожидаемых по дизайну !!! Пожалуйста, вне зависимости от стоимости НЕ ДЕЛАЙТЕ. Забыв о django, 40-летний дизайн базы данных укрепил нас в том, что схема базы данных никогда не должна меняться (если, конечно, требования не меняются или, ваш дизайн был неправильным). Я мог бы дать ответ, подобный этому: RegEx match open tags except XHTML self-contained tags, чтобы подчеркнуть, насколько важно не изменить схему базы данных.

Таким образом, вы будете иметь приложение Джанго в котором находится модель пользователя, как вы говорите, и CustomPermission модель, которая даст интерфейс к admininstrator так, что он будет добавить разрешения для ЭАГ клиента (администратор добавит разрешения для клиента, а не для разработчика). Каждый CustomPermission будет иметь только имя и ForeignKey клиенту, к которому он применим.

Теперь вы можете создать UserCustomPermission модель, которая будет иметь ForeignKey к User и другой ForeignKey к CustomPermission (на самом деле есть много-ко-многим между User и CustomPermission.

Теперь, что вам нужно для реализации - , как назначенные вами права будут назначены действительным разрешенным и запрещенным действиям. Вы ничего не говорите об этом в своем вопросе. Чтобы дать вам направление, мне очень нравится (и все время) django-rules-light application (https://github.com/yourlabs/django-rules-light), который может использоваться для определения вашего bu правила безопасности.

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

Ответ на обновление

Как вы понимаете, мне не нравится 1 и 3: Для каждого нового клиента, вам нужно будет создать новую базу данных с ? Почему бы не поместить все ваши клиентские потоки в одну и ту же таблицу и использовать внешний ключ к клиенту, к которому они принадлежат?

(ЗДЕСЬ БЫТЬ DRAGONS)

Я думал, хорошее решение - я бы не сделать это, но если так хочется, чтобы поместить пользователей и их разрешения в разных базах данных, то вы можете использовать отдельный суб -область в вашем продвижении: используйте маршрутизацию базы данных (https://docs.djangoproject.com/en/1.3/topics/db/multi-db/#database-routers), чтобы выбрать базу данных каждого клиента в зависимости от поддомена. Таким образом, вы будете определять все базы данных вашего клиента в вашем settings.py:

 
DATABASES = { 
    'default': { 
     'NAME': 'app_data', 
     'ENGINE': 'django.db.backends.postgresql_psycopg2', 
     'USER': 'postgres_user', 
     'PASSWORD': 's3krit' 
    }, 
    'client1': { 
     'NAME': 'client2', 
     'ENGINE': 'django.db.backends.mysql', 
     'USER': 'client2', 
     'PASSWORD': 'priv4te' 
    }, 
    'client2': { 
     'NAME': 'client1', 
     'ENGINE': 'django.db.backends.mysql', 
     'USER': 'client1', 
     'PASSWORD': 'priv4te' 
    } 
} 

И тогда вы будете создавать SubDomainDatabaseRouter класс, который будет использовать правильную базу данных, в зависимости от вашего субдомена. Поскольку параметры запроса недоступны в этом классе, их нужно разместить там, используя промежуточное ПО и локаторы потоков. Взгляните на следующий фрагмент кода

https://djangosnippets.org/snippets/2037/

Так что в вашем RouterMiddleware вы будете проверять, чтобы увидеть субдомен и в зависимости от того, что вы будете устанавливать client_cfg вариант с именем клиента. Ваш SubDomainDatabaseRouter будет использовать правильную базу данных в зависимости от client_cfg. Для того, чтобы использовать его только добавить

DATABASE_ROUTERS = ['my.package.SubDomainDatabaseRouter']

С помощью этого вы будете иметь совершенно другую базу данных для каждого клиента. Мне нужно еще раз подчеркнуть, что у вас будет ад, поддерживающий его - предположим, у вас есть 100 клиентов и нужно добавить поле в таблицу. И что ?Пожалуйста, не обессудьте :)

(КОНЕЦ DRAGONS)