При расширении числа клиентов и количества разных программных конфигураций нашей облачной CRM-системы возникла необходимость организовать единый вход с сайта-лендинга (основного сайта) во все доступные определенному сотруднику конфигурации.
Под конфигурацией мы понимаем отдельный экземпляр СРМ-системы, расположенный на отдельном поддомене (например, conf1.acme.com), имеющий собственную базу данных (MySQL). Во всех конфигурациях всегда присутствует таблица пользователей, имеющая одинаковую или примерно одинаковую структуру: поля «логин» и «пароль» всегда одинакового типа. В рамках одной конфигурации может быть доступно несколько организаций: документы определенных видов привязаны и доступны только в конкретной организации. Один и тот же пользователь может состоять в нескольких разных организациях в одной конфигурации.
На сайте-лендинге (acme.com) находится форма ввода логина/пароля.
Чтобы не привлекать сторонние службы, было решено разработать внутреннее программное решение для единого входа во все конфигурации. Сделано допущение, что аккаунт MySQL, с которого ведется работа с базой данных сайта, имеет доступ для чтения к таблицам пользователей баз данных конфигураций. Кроме того, для формы сброса пароля необходимо предоставить аккаунту права на запись к полю пароля и хэша сброса пароля в таблицах пользователей конфигураций.
Список конфигураций заносится в таблицу конфигураций БД основного сайта.
При авторизации происходят следующие действия:
1. Пользователь вводит логин и пароль на сайте, нажимает кнопку «Войти». Согласно таблице конфигураций, отправляются запросы на совпадение логина и пароля в таблицах пользователей конфигураций и наличие такого пользователя в организациях конфигураций.
2. Строится и возвращается список доступных пользователю конфигураций и организаций. Если ни одного совпадения не найдено – то выводится сообщение «неверный логин/пароль».
3. Путем клика по необходимой конфигурации и организации пользователь входит в систему.
Одним из преимуществ такого подхода можно считать определенную секретность: пользователь с одним и тем же логином может иметь разные пароли в разных конфигурациях. При вводе логина и одного пароля он не увидит конфигурации с другим паролем. Это бывает полезно в случае, если, например, в присутствии одного заказчика нельзя показывать, что существует другой заказчик. К сожалению, этот же момент можно отнести и к недостаткам: необходимо помнить множество разных паролей, и теряется смысл единого входа.
Для добавления новой конфигурации СРМ к такой модели достаточно внести соответствующую строчку в таблицу конфигураций и прописать указанные ранее права в БД конфигурации.
Для удаления — достаточно удалить соответствующую строчку из таблицы конфигураций.
В случае этой модели возможно реализовать быструю смену конфигурации на любую другую из доступных. Например, можно из конфигурации 2 быстро перейти в конфигурацию 1. Либо-переключиться между организациями одной конфигурации. В этом случае для обеспечения работы скрипта необходимо либо дать права на чтение таблицы конфигураций MySQL-аккаунту конфигурации, либо обращаться к этой таблице через MySQL-аккаунт основного сайта.
Под конфигурацией мы понимаем отдельный экземпляр СРМ-системы, расположенный на отдельном поддомене (например, conf1.acme.com), имеющий собственную базу данных (MySQL). Во всех конфигурациях всегда присутствует таблица пользователей, имеющая одинаковую или примерно одинаковую структуру: поля «логин» и «пароль» всегда одинакового типа. В рамках одной конфигурации может быть доступно несколько организаций: документы определенных видов привязаны и доступны только в конкретной организации. Один и тот же пользователь может состоять в нескольких разных организациях в одной конфигурации.
На сайте-лендинге (acme.com) находится форма ввода логина/пароля.
Чтобы не привлекать сторонние службы, было решено разработать внутреннее программное решение для единого входа во все конфигурации. Сделано допущение, что аккаунт MySQL, с которого ведется работа с базой данных сайта, имеет доступ для чтения к таблицам пользователей баз данных конфигураций. Кроме того, для формы сброса пароля необходимо предоставить аккаунту права на запись к полю пароля и хэша сброса пароля в таблицах пользователей конфигураций.
Список конфигураций заносится в таблицу конфигураций БД основного сайта.
При авторизации происходят следующие действия:
1. Пользователь вводит логин и пароль на сайте, нажимает кнопку «Войти». Согласно таблице конфигураций, отправляются запросы на совпадение логина и пароля в таблицах пользователей конфигураций и наличие такого пользователя в организациях конфигураций.
2. Строится и возвращается список доступных пользователю конфигураций и организаций. Если ни одного совпадения не найдено – то выводится сообщение «неверный логин/пароль».
3. Путем клика по необходимой конфигурации и организации пользователь входит в систему.
Одним из преимуществ такого подхода можно считать определенную секретность: пользователь с одним и тем же логином может иметь разные пароли в разных конфигурациях. При вводе логина и одного пароля он не увидит конфигурации с другим паролем. Это бывает полезно в случае, если, например, в присутствии одного заказчика нельзя показывать, что существует другой заказчик. К сожалению, этот же момент можно отнести и к недостаткам: необходимо помнить множество разных паролей, и теряется смысл единого входа.
Для добавления новой конфигурации СРМ к такой модели достаточно внести соответствующую строчку в таблицу конфигураций и прописать указанные ранее права в БД конфигурации.
Для удаления — достаточно удалить соответствующую строчку из таблицы конфигураций.
В случае этой модели возможно реализовать быструю смену конфигурации на любую другую из доступных. Например, можно из конфигурации 2 быстро перейти в конфигурацию 1. Либо-переключиться между организациями одной конфигурации. В этом случае для обеспечения работы скрипта необходимо либо дать права на чтение таблицы конфигураций MySQL-аккаунту конфигурации, либо обращаться к этой таблице через MySQL-аккаунт основного сайта.