У вас действительно есть только 2 варианта:
- Убедитесь, что пользователи входят в систему с помощью URL-адреса конкретного клиента
- У вас есть возможность сопоставить учетные данные для входа с арендатором
Проблема с (2) отображением учетных данных для входа в учетную запись состоит в том, что она запрещает повторное использование учетных данных, что является препятствием для показа, когда пользователь хочет иметь доступ к 2 вашим клиентам одновременно.Чтобы справиться с этим делом, вы должны дать каждому пользователю специфичный для арендатора идентификатор, который является глобально уникальным.Вы можете сделать это
- , включив какой-либо идентификатор арендатора в идентификатор пользователя (безобразно) или
- , заставив пользователей, имеющих учетные записи с более чем одним арендатором, войти в систему с некоторымиглобальный уникальный идентификатор, который отличается для каждого арендатора (плохой пользовательский опыт, который трудно объяснить вашей группе поддержки клиентов).
Большинство компаний находят эти варианты неприемлемыми, но я видел, что это иногда делалось.
Большинство компаний предпочитают разрешать пользователям повторно использовать свой адрес электронной почты в качестве своего идентификатора в том случае, если онииметь учетные записи на нескольких арендаторов.Вместо этого компании выбирают разделение учетных записей арендаторов, предоставляя каждому арендатору уникальный URL-адрес для входа и не разрешая прямой вход через основной сайт (компания-поставщик услуг с приложением с несколькими арендаторами).Вместо этого они требуют, чтобы пользователи заходили на сайт арендатора и нажимали там какую-то кнопку login, которая направляет их на страницу входа для конкретного арендатора.
Варианты URL-адресов, специфичных для арендатора, включают:
Большинство компаний выбирают субдомены по двум причинам:
- Это делает более чистый URL, чем добавление параметра ID арендатора в URL.
- Это означает, что каждыйу клиента может быть один и тот же путь и нет параметра клиента для каждого URL-адреса, что может упростить как разработку, так и тестирование, а также повысить эффективность SEO.
- В той степени, в которой содержание страницы варьируется в зависимости от арендатора, он значительно поддерживает поисковые системы и SEO.лучше, потому что варианты страниц находятся на разных доменах, а не сворачиваются в один домен и запускаются каким-то непрозрачным параметром.
- Это значительно упрощает разбиение.Когда вы достигнете некоторого разумного числа арендаторов на одном сервере, вместо того, чтобы прыгать через обручи для продолжения вертикального масштабирования, вы можете легко масштабировать горизонтально, используя субдомен для маршрутизации трафика на другой сервер (кластер) для следующего набора арендаторов.
Поэтому, хотя вы могли бы создать карту почтовых учетных записей для арендаторов, я бы посоветовал против нее, потому что она будет мучительно терпеть неудачу, как только пользователь попытается создать учетную запись со вторым арендатором, используя тот жеЭл. адрес.Даже если вы думаете, что никто никогда не сделает этого, вы не можете быть уверены, особенно с ростом вашей компании.И даже если 99,99% ваших пользователей этого не делают, к тому времени, когда вы наберете 1 миллион пользователей, у вас будет 100 таких.
Если вы намерены разрешить пользователям использовать свой адрес электронной почты в качестве своегоИдентификатор пользователя и вход в него через общий URL-адрес. Я бы рекомендовал вашим пользователям также указывать, в какого арендатора они входят, через текстовое поле или меню параметров, которые можно предварительно заполнить / выбрать на основе значения файла cookie.В этом случае для входа в систему необходимо указать идентификатор пользователя, идентификатор клиента и пароль.
Если вы согласны с тем, что пользователи не используют свой адрес электронной почты в качестве идентификатора пользователя, я бы просто включил идентификатор арендатора в идентификатор пользователя.Таким образом, пользователь 'steve' в клиенте 'apt' может иметь идентификатор пользователя 'steve_apt'.
Эти 2 варианта позволяют пользователю иметь учетные записи более чем для одного арендатора, а также работают без какой-либо глобальной карты идентификаторов пользователей для арендаторов.
Если вы обязуетесь разрешить пользователям использовать свой адрес электронной почты в качестве идентификатора пользователя и разрешать им входить по общему URL, и вы не хотите, чтобы им приходилось осознавать тот факт, что компания является одним из арендаторовмногие в вашей системе, тогда да, вам нужен какой-то идентификатор пользователя для сопоставления арендатора.
Вы можете обеспечить это сопоставление несколькими способами.
- Вы можете поместить cookie в браузер, чтобы дать вам подсказку о том, к какому арендатору принадлежит пользователь, а затем просто запросить этого арендатора.Вы можете вернуться к опросу всех ваших арендаторов, если этот запрос не выполнен или файл cookie не предоставлен.
- Вы можете заполнить кэш Redis сопоставлениями между идентификаторами пользователей и арендаторами с помощью некоторого фонового задания или по запросу, а также принудительных обновлений при добавлении новых пользователей, чтобы вы могли быстро выполнить поиск в кэше Redis почтипостоянно возвращаясь к опросу каждого арендатора, только в редком случае отсутствия кэша.
- Вы можете относиться к входу в систему как к стороннему поставщику.Создайте приложение, которое просто хранит ID пользователя, пароль и владельца, чтобы люди входили в это приложение, а затем это приложение перенаправляет вошедшего в систему пользователя в основное приложение, передавая аутентифицированные ID пользователя и ID арендатора.Если все приложения находятся в одном домене, то это не должно быть сложно, поскольку все, что требуется приложению для аутентификации, - это создать тот же файл cookie, который другие приложения уже принимают в качестве аутентификации вошедшего в систему пользователя.
Опрос арендаторов, ищущих идентификатор пользователя, также можно выполнить несколькими различными способами.Я бы не рекомендовал этот подход в целом, но если вы собираетесь это сделать, я бы порекомендовал вам сделать это с помощью базы данных PostgreSQL, храня каждого арендатора в отдельной схеме в той же базе данных и либо с использованием материализованного представления , либо с хранимой динамической SQL-процедурой PL / pgSQL.
Я не большой поклонник любого из этих решений, но, думаю, если бы у меня былчтобы выбрать, я бы выбрал схему authentication, которая содержит идентификатор пользователя, пароль и tenant_id и используется только для входа в систему, предпочтительно изолированным и более безопасным приложением.Как вы справляетесь с тем фактом, что для этого требуется, чтобы идентификатор пользователя и сопоставление арендаторов существовали в 2 разных местах, которые оба могут претендовать на то, чтобы быть источником правды, и то, что вы делаете, когда они не согласны, является проблемой, для которой мое основное предложение состоит в том, чтобыне делай этого в первую очередь.