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