Зачем использовать субдомены для обозначения клиентов в мультитенантном веб-приложении?

Вопросов

  1. Почему некоторые мультитенантные веб-приложения используют субдомены для обозначения клиента, а другие - нет?
  2. Есть ли технические причины, соображения конфиденциальности или безопасности?
  3. Зависит ли это от языка или структуры, используемой для разработки веб-приложения?
  4. Это просто вопрос стиля или выбора разработчика?

Примеры веб-приложений, использующих субдомены для назначения клиентов

Примеры веб-приложений, не использующих субдомены для назначения клиентов


multi-tenant subdomain
person Matthew Rankin    schedule 13.02.2011    source источник
comment
В качестве рекомендации я бы посоветовал с самого начала разрабатывать свое приложение так, чтобы не использовать поддомены, а затем встраивать эту функциональность в качестве последнего слоя. Если вы интегрируете субдомены на всем протяжении, их будет очень негибко менять в будущем. (источник: опыт)   -  person cjm2671    schedule 30.01.2014
comment
Здравствуйте, если вы можете избежать использования поддоменов, сделайте это! Мы вынуждены использовать пользовательские домены (а не только субдомены) для нашего приложения, потому что наш продукт представляет собой полное решение с белой меткой, и оно часто требует, чтобы наши клиенты настраивали пользовательские домены в файле своих хостов и указывали на нашу систему и также включить то же самое, что и параметр в системе. Излишне говорить, что это длительный процесс, поскольку многие из наших клиентов также являются торговыми посредниками и должны делать то же самое. Я действительно думаю, что от этого никуда не деться, но если получится, постарайся избежать :)   -  person Anup Marwadi    schedule 21.08.2014

Ответы (2)


arrow_upward
31
arrow_downward

Определить арендатора на уровне HTTP можно несколькими способами:

  • домен - арендатор определяется целым заголовком Host
  • sub-domain - часть поддомена заголовка Host,
  • на основе пути - сегмент пути, обычно по префиксу host.com/tenantId/...
  • на основе файлов cookie - значение cookie содержит идентификатор клиента (хорошая структура зашифровывает это!)
  • на основе пользователя - сеанс пользователя или некоторые записи данных на сервере

Вот ответы на ваши вопросы:

  1. Мультиарендность (под) домена хороша, если вы хотите дать пользователю ощущение полностью изолированной аренды. Заказчику может потребоваться настраиваемая страница приветствия и входа в систему, отдельная база пользователей и т. Д. С другой стороны, мультиарендность на основе пути хороша для пользователей, которые не привязаны к единому пространству имен арендатора. В основном он используется в социальных сетях, таких как Facebook, GitHub и т. Д.

  2. (Под) домены могут дать вам лучшую изоляцию и контроль безопасности для файлов cookie, совместного использования ресурсов из разных источников (CORS). Это немного усложняет кросс-тенантный CSRF или XSS. Более того, если у вас есть контроль над DNS или балансировщиком нагрузки, вы можете назначать клиентов разным IP-адресам (например, гео-маршрутизация) или различным версиям приложения (например, бета-клиентам). Вы можете назначить отдельный экземпляр приложения или сервер для наиболее важных клиентов. Таким образом, вы получаете дешевый инструмент для контроля риска сбоя в одной точке и все яйца в одной корзине.

  3. Любая веб-платформа, которая дает вам доступ к заголовкам HTTP (Host), поддерживает поддомены. Любой серьезный веб-фреймворк MVC должен предоставлять вам субдомен в качестве параметра действия напрямую или через плагин.

  4. Это определенно выбор дизайна. Если вы хотите знать, как лучше, подумайте, какой уровень изоляции вы хотите для своих арендаторов. Если вы решите, но обнаружите, что путь неправильный, вы можете перейти на другой уровень с помощью перенаправления HTTP 301.

person gertas    schedule 09.11.2014
comment
Привет, @gertas, у меня есть приложение, в котором пользователи создают свои собственные веб-сайты, и я хочу разрешить им редактировать html и css шаблона, который они выбирают, не влияя на безопасность моего приложения. Как вы думаете, мультитенантность - хорошее решение? Благодарность! - person medBouzid; 02.03.2015
comment
Вы должны, любое пользовательское пространство = мультитенантность. Я бы выбрал уровень поддомена или домена с правильными заголовками CORS, чтобы предотвратить XSS. Однако, если у вас очень хороший дезинфицирующий агент html / css или вы проводите модерацию, вы можете попробовать мультитенантность на основе пути, см. Ebay или старый myspace. Но, по крайней мере, поместите модуль администратора в отдельный домен и не отображайте эти HTML-файлы напрямую - в админке попробуйте iframes. - person gertas; 03.03.2015
comment
Я провел некоторое исследование и обнаружил, что существуют (отдельные базы данных), (общая база данных, отдельная схема), (общая база данных, общая схема), поскольку я использую структуру Rails, есть жемчужина под названием квартира, которая использует (общую базу данных , отдельная схема), но похоже, что хостинг, такой как heroku, настоятельно рекомендует не использовать его, так как он вызывал множество проблем в работе ...) они также говорят, что даже ›50 может серьезно повлиять на производительность ..), пожалуйста, попросите вас какой-либо опыт в этой теме? может только поддомен решить проблему? - person medBouzid; 04.03.2015
comment
Вы упомянули другой уровень изоляции мультитенантности - БД. Я использую одну схему БД со столбцом tenant_id в каждой таблице. - person gertas; 05.03.2015
comment
Я также ищу аналогичную концепцию для реализации в одном из проектов, где мне нужно решить использовать Single Domain V / S Multi Sub Domain, для единой базы кода, Multiple DB для каждой учетной записи. Планируете использовать Load Balancer, что лучше: один домен - несколько клиентов или несколько субдоменов - несколько клиентов? - person Pragnesh Karia; 10.08.2016

arrow_upward
4
arrow_downward

  1. См. ниже.
  2. Файлы cookie будут наиболее очевидными, во-вторых, вы можете изменить настройки DNS для поддомена, но не для пути.
  3. No
  4. Частично см. Выше.
person Noon Silk    schedule 13.02.2011