В ответ на ваш первый вопрос самая большая проблема с проверкой наличия у пользователя роли, а не определенного разрешения, заключается в том, что разрешения могут поддерживаться несколькими ролями. В качестве примера этому разработчик может иметь доступ к порталу для разработчиков во внутренней сети компании, что, вероятно, также является разрешением, предоставляемым их менеджером. Если пользователь затем пытается получить доступ к порталу разработчика, у вас будет проверка, подобная следующей:
if(SecurityUtils.hasRole(developer)) {
// Grant them access to a feature
} else if(SecurityUtils.hasRole(manager)) {
// Grant them access to a feature
} else if...
( switchВыражение на выбранном вами языке было бы лучше, но все же не особо аккуратно)
Чем более распространено или широко распространено разрешение, тем больше ролей пользователей вам нужно будет проверить, чтобы убедиться, что кто-то может получить доступ к данной системе. Это также может привести к проблеме, заключающейся в том, что каждый раз, когда вы изменяете разрешения для роли, вам нужно будет изменить проверку, чтобы отразить это. В большой системе это стало бы очень громоздким очень быстро.
Если вы просто проверяете, что у пользователя есть разрешение, которое позволяет ему получить доступ, например, к порталу разработчика, то не имеет значения, какую роль он играет, ему будет предоставлен доступ.
Чтобы ответить на ваш второй вопрос, причина в том, что у вас есть роли, заключается в том, что они легко изменяются и распространяют «пакеты» разрешений. Если у вас есть система с сотнями ролей и тысячами разрешений, добавление нового пользователя (например, нового менеджера по персоналу) потребует от вас пройти и дать им каждое разрешение, которое есть у других менеджеров по персоналу. Это не только утомительно, но и может привести к ошибкам, если делать это вручную. Сравните это с простым добавлением роли «Менеджер отдела кадров» в профиль пользователя, который предоставит им такой же доступ, как и у любого другого пользователя с этой ролью.
Вы можете утверждать, что вы можете просто клонировать существующего пользователя (если ваша система поддерживает это), но, хотя это действительно дает пользователю правильные разрешения на тот момент времени, попытка добавить или удалить разрешение для всех пользователей в будущем может быть сложно. Примером такого сценария может быть то, что, возможно, в прошлом персонал отдела кадров также отвечал за начисление заработной платы, но в дальнейшем компания становится достаточно большой, чтобы нанимать персонал специально для обработки заработной платы. Это означает, что HR больше не нужен доступ к системе начисления заработной платы, поэтому разрешение может быть удалено. Если у вас есть 10 различных членов HR, вам нужно будет вручную пройти и убедиться, что вы удалили правильное разрешение, которое вводит возможность для ошибки пользователя. Другая проблема заключается в том, что она просто не масштабируется; По мере того, как вы получаете все больше и больше пользователей в данной роли, это значительно усложняет изменение роли. Сравните это с использованием ролей, где вам нужно всего лишь изменить общую роль, о которой идет речь, чтобы удалить разрешение, которое будет отражено каждым пользователем, которому принадлежит эта роль.