Несколько систем аутентификации

Question

У меня есть 2 таблицы, Users и Customers и 2 различных действия для них.поэтому мне нужно 2 системы аутентификации.Пользователи входят с именем пользователя и паролем, а клиенты - с идентификатором и паролем.

Я знаю, что торт по умолчанию AuthComponent может работать только с 1 моделью, User моделью.потому что userModel может быть строкой, а не массивом (не так ли?).

Как я могу использовать его с 2 моделями (и таблицами) с 2 страницами входа и 2 ....1010 * (примечание: я не могу объединить 2 таблицы. У них разные схемы)

Answer 1

Вместо того, чтобы пытаться поддерживать 2 разные системы аутентификации, я настоятельно рекомендую вам изучить ACL и ARO. Это позволит вам связывать пользователей с различными группами доступа - в вашем случае у вас могут быть такие группы, как «Внутренняя» ¹ и «Клиенты», и каждая новая учетная запись пользователя является членом одной или другой группы.

Затем вы можете предоставлять разрешения на уровне группы. Пользователи-клиенты имеют доступ к своему контенту, внутренние пользователи имеют доступ к другому контенту.

В новой книге CakePHP есть хорошее руководство: Простое контролируемое Acl приложение

^{1 Полагаю, когда вы в общем относитесь к «пользователям», вы имеете в виду внутренних пользователей, но не стесняетесь адаптировать терминологию и имена групп к вашей конкретной ситуации.}

Answer 2

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

Насколько я понимаю, это обзор процесса аутентификации (обратите внимание, что я не эксперт по безопасности):

Этап идентификации связан с получением учетных данных пользователя. Подойдет простая форма, которая получает имя пользователя и пароль.

Фаза аутентификации представляет процесс, который сопоставляет учетные данные пользователя с пользователем. По сути, он идентифицирует провайдера идентификации и использует его для получения идентификатора пользователя для предоставленных учетных данных пользователя.

При просмотре как сервисы они выглядят примерно так:

// You can have many IdentityProviders. This mecanism allows you to extend your
// authentication system so you can use any mechanism (WebDav, Kerberos, etc).
IIdentityProvider
{
    // Returns a pozitive id if the user is found and the credentials are valid
    // or zero if user credentials are invalid (or negative numbers that represent
    // error codes).
    UserID GetUser(UserCredentials)
}

IAuthenticationService
{
    Session SignIn(UserCredentials)
    void SignOut(Session)
}

DefaultIdentityProvider : IIdentityProvider
{
    // Search the user in your database.
    UserID GetUser(UserCredentials credentials)
}

AuthenticationService : IAuthenticationService
{
    IIdentityProvider[] identityProviders

    Session SignIn(UserCredentials credentials)
    {
        IIdentityProvider provider = identityProviders[credentials.Type]
        Session session = null

        if (provider)
        {
            UserID userID = provider.GetUser(credentials)

            if (userID > 0)
            {
                session = new Session
                session.UserID = userID
            }
        }

        return session
    }

    void SignOut(Session session)
    {
        delete session
    }
}

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

В вашем примере, клиент - это роль. Ресурсом является, например, продукт. Продукт представлен типом продукта, имеет идентификатор и может иметь несколько связанных категорий («Электроника» и «Опасный»). Операции можно рассматривать как варианты глаголов Создать / Читать / Обновить / Удалить. Теперь роль «Клиент» будет содержать набор разрешений, в которых четко указано, что пользователь с этой ролью может делать с управляемыми ресурсами. Например, клиент может только читать определенную информацию о продукте, но не может создавать, обновлять или удалять продукт. Обратите внимание, что если пользователь имеет более одной связанной роли, он получает все разрешения от этих ролей (операция объединения, а не пересечение).

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

Answer 3

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

Answer 4

Я бы предположил 2 отдельные области входа или переключатель, чтобы указать, какую попытку входа они предпринимают.

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

if (customer) {
 do customer stuff;
} elseif (user) {
 do user stuff;
} else {
 you didn't login;
}