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

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

Итак, selfish - это частная платформа для ведения блогов в сети Интернет и в перспективе будет предоставлять своим пользователям следующие возможности:

• возможность быть заблокированным в случае неадекватного поведения;
• возможность читать блоги других пользователей сервиса;
• возможность создавать ленту и добавлять в неё наиболее интересных авторов блогов;
• возможность отправлять приватные сообщения другим пользователям сервиса;
• возможность оставлять публичные (доступные для чтения всем пользователям сервиса) комментарии в блогах других пользователей и в своём блоге;
• возможность вести собственный блог;
• возможность следить за порядком в сервисе и блокировать или удалять несоответствующие политике сервиса топики блогов и публичные комментарии, а так же изменять разрешения других пользователей;
• возможность администрировать сервис и неограниченно выполнять любые предусмотренные сервисом действия.

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

• Изгнанные;
• Читатели;
• Комментаторы;
• Блогеры;
• Модераторы;
• Администраторы.

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

Открываю терминал, вхожу в базовый каталог selfish, активирую виртуальное окружение и создаю новый файл в каталоге selfish/models.

touch selfish/models/auth_units.py

Открываю этот файл в редакторе PyCharm и создаю в нём три новых объекта.

from collections import namedtuple

Permit = namedtuple(
    'Permit', ['CANNOT_LOG_IN',
               'READ_JOURNAL',
               'FOLLOW_USERS',
               'SEND_PM',
               'COMMENT',
               'WRITE_JOURNAL',
               'POLICE',
               'ADMINISTER'])

permissions = Permit(
    CANNOT_LOG_IN='заблокирован',
    READ_JOURNAL='читать журнал',
    FOLLOW_USERS='создавать ленту',
    SEND_PM='писать в приват',
    COMMENT='комментировать журнал',
    WRITE_JOURNAL='вести журнал',
    POLICE='следить за порядком',
    ADMINISTER='без ограничений')

defaults = {permissions.READ_JOURNAL: True,
            permissions.FOLLOW_USERS: True,
            permissions.SEND_PM: True,
            permissions.COMMENT: True,
            permissions.WRITE_JOURNAL: True}

Два целевых объекта этого файла: permissions и defaults определяют формулировки разрешений и набор разрешений для вновь регистрируемых пользователей. Поскольку набором разрешений вновь регистрируемых пользователей мне хочется управлять посредством web-интерфейса в будущем, создаю соответствующий объект в базе данных, для этого открываю в редакторе файл selfish/models/auth.py, импортирую в нём целевые объекты из auth_units и определяю новый класс.

...
from .auth_units import defaults, permissions
...


class Permission(db.Model):
    __tablename__ = 'permissions'

    id = db.Column(db.Integer, primary_key=True)
    permission = db.Column(db.String(32), unique=True, nullable=False)
    initial = db.Column(db.Boolean, default=False, nullable=False)

В поле permission я буду хранить формулировку разрешения, а поле initial определяет, будут ли вновь регистрируемые пользователи иметь данное разрешение. Определяю порядок инициализации экземпляров этого класса.

    def __init__(self, **kwargs):
        db.Model.__init__(self, **kwargs)
        if 'permission' not in kwargs:
            raise MissingArgument('missing required argument: "permission"')
        if not kwargs['permission'] or \
                not isinstance(kwargs['permission'], str):
            raise BadArgument('bad required argument: "permission"')

Для инициализации экземпляров класса Permission определён один обязательный аргумент - permission. Определяю возвращаемое экземпляром класса значение.

    def __repr__(self):
        return '<Permission: {}>'.format(self.permission)

С помощью специального метода определяю порядок начального заполнения этой таблицы базы данных.

    @classmethod
    def insert_permissions(cls):
        for permission in cls.query:
            if permission.permission not in permissions:
                db.session.delete(permission)
        for permission in permissions:
            p = cls.query.filter_by(permission=permission).first()
            if p is None:
                p = cls(
                    permission=permission,
                    initial=defaults.get(permission, False))
                db.session.add(p)
        db.session.commit()

Метод insert_permissions использует целевые объекты из auth_units, проверяет наличие в таблице существующих записей, их соответствие объекту permissions и в случае необходимости добавляет в таблицу отсутствующие записи.

Каждый пользователь может иметь больше одного разрешения, это необходимо отразить в соответствующей модели - User. Делаю в файле ещё один импорт и дописываю в User свойство permissions.

...
from sqlalchemy.dialects import postgresql
...


class User(UserMixin, db.Model):
    __tablename__ = 'users'

    ...
    permissions = db.Column(postgresql.ARRAY(db.String(32)))

Кроме этого, мне необходим инструмент, который мог бы определять наличие у конкретного пользователя конкретного разрешения, дописываю в User ещё один метод.

    def can(self, permission):
        return permission in self.permissions

Так как этот метод текущего пользователя достаточно часто будет использоваться в логике приложения и в шаблонах, его следует уравновесить соответствующим методом в классе AnonymousUser.

class AnonymousUser(AnonymousUserMixin):
    def can(self, permission):
        if permission:
            return False
        return False

О новых объектах приложения нужно сообщить менеджеру проекта, открываю файл manage.py, импортирую в нём новые объекты и добавляю их в контекст служебной консоли.

Иду в терминал и делаю очередную миграцию базы данных.

python manage.py db migrate -m"Create Permission and Modify User"

Обновляю данные в базе данных.

python manage.py db upgrade

Подгружаю служебную консоль приложения и заполняю таблицу permissions.

>>> Permission.insert_permissions()
>>> 

В моей базе данных есть один зарегистрированный пользователь, фильтрую его.

>>> newbie = User.query.filter_by(username="newbie").first()
>>> newbie
<User: newbie>
>>> 

Когда я создавал этого пользователя, у приложения ещё не было пользовательских разрешений, поэтому у этого пользователя в свойстве permissions лежит голый None.

>>> newbie.permissions is None
True
>>> 

Даю пользователю начальные для вновь зарегистрированных разрешения.

>>> newbie.permissions = [permission.permission for permission in Permission.query if permission.initial is True]
>>> newbie.permissions
['читать журнал', 'создавать ленту', 'писать в приват', 'комментировать журнал', 'вести журнал']
>>> db.session.add(newbie)
>>> db.session.commit()
>>> 

Проверяю работу метода can на примере существующего пользователя и его наборе разрешений.

>>> newbie.can(permissions.ADMINISTER)
False
>>> newbie.can(permissions.CANNOT_LOG_IN)
False
>>> newbie.can(permissions.WRITE_JOURNAL)
True
>>> 

Таким образом для каждого пользователя в сервисе я имею возможность проверить наличие у него того или иного разрешения, что и будет использоваться при проектировании серверной логики приложения на следующих этапах разработки, для этого мне потребуется добавить в приложение ещё пару инструментов.

Общую для всех функций представления логику, осуществляющую проверку разрешений текущего пользователя, я выделю в декоратор. Создаю новый файл.

touch selfish/deco.py

Открываю этот файл в редакторе и пишу в него следующий код.

Функция permission_required является декоратором и добавляет декорируемой функции представления проверку наличия заданного разрешения у совершающего запрос текущего пользователя при помощи определённого в классах User и AnonymousUser метода can. В зависимости от результата проверки permission_required будет прерывать исполнение декорируемой функции представления вызовом abort в случае, если текущий пользователь не имеет заданного разрешения. В ином случае будет исполнен код декорируемой функции представления.

Поскольку в составе selfish появился вызов abort(403) для http-ошибки 403 следует добавить соответствующий обработчик. Открываю файл selfish/main/errors.py и дописываю в нём ещё одну функцию.

@main.app_errorhandler(403)
def deny_request(e):
    return render_template(
        'error.html', error=e.code, reason='Доступ запрещён'), e.code

Кроме этого, мне понадобится проверка разрешений пользователя в логике шаблонов, для этого включаю объект permissions из модуля auth_units в контекст шаблонизатора. Открываю файл selfish/main/__init__.py и дописываю в него новую функцию.

...
from ..models.auth_units import permissions
...


@main.app_context_processor
def inject_tools():
    return {'permissions': permissions}

C этого момента в каждом шаблоне selfish объект permissions будет доступен, что позволит мне определять элементарную логику шаблона опираясь на разрешения пользователя.

Текущий код selfish можно увидеть в моём профиле на gitlab.com. Разработанные только что инструменты пригодятся мне уже в ближайшее время, и в одном из ближайших выпусков блога я покажу, как с ними обращаться. Продолжение следует и в следующем выпуске я создам в базе данных записи для новых пользователей, разделю их на группы, и у приложения появится администратор. Как всегда, вопросы, замечания и предложения можно оставлять в комментариях ниже.., с удовольствием на них отвечу.