Предлагаемые новые функции:

Добавить метод проверки прав на основе ролей

Описание сценариев использования:

В документе: https://sa-token.cc/doc.html#/use/route-check, приведены следующие коды:

// По маршруту разделяются модули, разные модули имеют разные права доступа
SaRouter.match("/user/**", r -> StpUtil.checkPermission("user"));
SaRouter.match("/admin/**", r -> StpUtil.checkPermission("admin"));
SaRouter.match("/goods/**", r -> StpUtil.checkPermission("goods"));
SaRouter.match("/orders/**", r -> StpUtil.checkPermission("orders"));
SaRouter.match("/notice/**", r -> StpUtil.checkPermission("notice"));
SaRouter.match("/comment/**", r -> StpUtil.checkPermission("comment"));

Похоже, что это проверка соответствия URL-шаблонов, и если соответствует, то проверка наличия соответствующей роли.
В нашей архитектуре, такой подход называется "шаблон-ориентированный".
Этот подход имеет один недостаток:
В больших системах, шаблонов много, или если шаблон для проверки находится в конце списка, то происходит множество ненужных проверок.
Поэтому, в нашей архитектуре, существует также "роль-ориентированный" подход.
Логика следующая:

1. Запрос приходит в систему, система получает роли пользователя.
2. По имеющимся у пользователя ролям, получаем список URL-шаблонов, доступных для каждой роли.
3. Используем URL запроса для сравнения с URL-шаблонами, доступными для каждой роли, чтобы определить, может ли пользователь получить доступ.
   Преимущества:Каждая проверка происходит в пределах ролей пользователя, что позволяет уменьшить количество ненужных проверок. В корпоративных системах часто происходят изменения, поэтому рекомендуется добавить роль-ориентированный подход, чтобы пользователи могли самостоятельно настроить его, чтобы подстроиться под различные ситуации.

Другое:

Роль-ориентированный подход также имеет свои недостатки, например, если пользователь неправильно настроит права доступа, то в каждой роли будет много повторяющихся шаблонов, что приведет к множественным повторяющимся проверкам. Поэтому, после получения URL-шаблонов для каждой роли, следует выполнить "агрегацию и удаление дубликатов". Однако удаление дубликатов во время выполнения системы имеет больше недостатков, чем преимуществ. Для решения этой проблемы, я предлагаю следующий подход: вместо решения проблемы с технической стороны, лучше научить пользователей правильно настраивать URL-шаблоны для каждой роли.

Один из возможных подходов:
Система имеет четыре типа интерфейсов: QUERY, ADD, UPDATE, DELETE. Можно создать две роли: READ и WRITE. При предоставлении пользователю только прав на чтение, можно предоставить ему роль READ. При предоставлении пользователю прав на чтение и запись, можно предоставить ему роли READ и WRITE. Вместо создания трех ролей: READ, WRITE, READ_WRITE, что позволяет уменьшить количество дубликатов в ролях.В нашей архитектуре используется подход на основе ролей, и URL-шаблоны ролей разделены на две категории:

1. Шаблоны, содержащие символы-шаблоны, такие как ? и *, после оптимизации алгоритмом (например, для шаблонов /*, /a, /b оставляется только /*, так как он покрывает все остальные), добавляются в список;
2. Шаблоны без символов-шаблонов добавляются в хэшсет.
   При выполнении соответствия сначала проверяется наличие URL-шаблона в хэшсет, а затем используется шаблонное соответствие. Это значительно улучшает производительность при детальном контроле доступа.
   Возможность улучшения производительности заключается в использовании подхода, который позволяет создать структуру, например, для двух URL-шаблонов /user/add и /user/update. Вместо использования традиционного подхода, требующего соответствия четырем строкам (user, add, user, update), можно создать дерево:

    user
   /    \
 add   update

В этом случае необходимо будет соответствовать только трем строкам (user, add, update), что может привести к улучшению производительности. Однако это ещё не было протестировано.