Laravel Мультитенант API внутри мультитенанта - PullRequest
Новая
       308

Laravel Мультитенант API внутри мультитенанта

0 голосов
/ 07 августа 2020

Я тестирую laravel для замены имеющегося у меня приложения.

Я реализовал мультитенант (https://tenancy.dev/docs/hyn/5.6), разделяя каждого арендатора в базе данных и каждого доступ арендатора через поддомен.

Это частично решает мою проблему. Потому что я могу разделить каждую бизнес-группу в базе данных. Однако внутри одной бизнес-группы может быть несколько бизнес-единиц. Я приведу в качестве примера m c donalds, это будет бизнес-группа, а каждый из магазинов будет единицей. Чтобы решить эту проблему, я подумал о создании нового механизма клиента, на этот раз с разделением tenant_id в базе данных.

В этом случае я хотел бы узнать от самых опытных, будет ли это правильный подход ?

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

Надеюсь, я ясно объяснил проблему. Если вам нужна дополнительная информация, дайте мне знать.

Любая помощь приветствуется.

Заранее спасибо всем, кто дочитал до этого места.

1 Ответ

0 голосов
/ 15 августа 2020

Для этой проблемы вам нужно будет ввести концепцию иерархии клиентов, например 

McDonald (Main Tenant)
    McDonald Seattle
    McDonald Oregon
    McDonald Newyork

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

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

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

В В случае ACL нам, возможно, придется назначать роли и разрешения по арендатору (достаточно столбца tenantId), это помогает пользователю играть роль менеджера в одном дочернем арендаторе (McDonald Seattle) и роль продавца в (McDonald Newyork) арендаторе.

Например, у меня может быть следующая модель. Это будет установлено при выборе клиента, и с этого момента я смогу использовать разрешения / роли для проверки из этого контекста, так что больше не будет вызовов db et c. Это можно сделать как в пользовательском интерфейсе, так и на уровне REST API (на уровне REST API место, где мы аутентифицируем пользователя, может настроить это, и слои API, Services, BusinessRules будут использовать это как источник истины, чем нажатие база данных) 

class UserContext {
    String userName,
    Guid Id,
    Guid TenantId,
    Roles[] TenantRoles,
    String[] Permissions
}
...