Я хотел бы знать, как лучше настраивать пользовательские домены при создании веб-приложений. Например, если вы посмотрите на что-то вроде базового лагеря, когда вы подписываетесь на это, вы создаете свой собственный «поддомен», к которому вы используете для входа в basecamp.
Кроме того, если вы посмотрите на это, например, на размещенные сайты электронной торговли, вы можете использовать свой собственный домен вместо использования своего поддомена.
Лично я не вижу, чтобы эти веб-приложения «запирали» каждый пользовательский домен на учетной записи хостинга веб-приложений или добавляли DNS, если он использует субдомен, такой как Base Camp.
Поэтому единственный способ, которым я могу думать о том, чтобы делать что-то динамически, – это, возможно, использовать mod_rewrite для перенаправления всего на определенный скрипт, который выполняет «маршрутизацию» на основе URL-адреса. Затем для доменов клиентов клиенту просто нужно добавить CNAME для своего домена к чему-то вроде custom.webappname.com, который затем, в свою очередь, будет загружен mod_rewrite и файлом маршрутизации php.
Если это лучший способ продвижения вперед, есть ли проблемы с производительностью при маршрутизации всех входящих запросов через этот «файл маршрутизации»?
Извините, если я не понял, попытался объяснить все, что могу.
Да, ваше решение было бы лучшим способом. Так делают и другие сайты. Повторное перенаправление всех запросов через центральный файл с использованием правил перезаписи требует небольшого штрафа за производительность, но это того стоит.
Фактически, в большинстве приложений вы уже платите этот штраф в любом случае. Любая структура, использующая шаблон FrontController , уже делает именно это. Это включает в себя почти все структуры, такие как Zend, Symfony 1 и 2, CakePHP, CodeIgniter и многие другие.
Это действительно зависит от веб-приложения, с которым вы работаете.
Например, у нас есть размещенная CMS, с использованием API cPanel мы создаем фактическую учетную запись хостинга для каждого клиента и устанавливаем около 50 Кбайт файлов при создании учетной записи, включая шаблон по умолчанию, начальный сценарий настройки (обрабатывает установку БД, начальную совокупность данных и основные настройки, среди прочего) и несколько базовых сценариев управления внешним интерфейсом, таких как форма контакта, говоря, что мы не предоставляем доступ к учетной записи хостинга, все взаимодействие осуществляется через наше веб-приложение. В нашем случае это независимо от того, является ли он поддоменом или полностью доменом. Наши клиенты имеют возможность самостоятельно размещать свой домен, или мы будем его размещать, потому что у нас есть полная инфраструктура хостинга cPanel, для нас нет никакой разницы, где находится DNS, но если у клиента есть это от нас, это полностью их ответственность.
Причина, по которой мы устанавливаем этот хостинг, заключается в том, что клиенты могут загружать свои собственные шаблоны, для управления дисковыми хранилищами (нам не интересно быть файловым сервером, но клиентам нужно некоторое пространство для PDF-файлов, изображений и т. Д.) И убедиться, что контент из 1 клиента не смешивается с содержимым другого. В качестве премиального платного обслуживания наши юристы рекомендовали на сервере хранить как минимум отдельные идентифицируемые папки для хранения файлов.
Другим примером является blogger / blogspot, хорошо известно, что они используют mod_rewrite для своих поддоменов. Для них это подходит, иначе они должны были бы создать отдельную зону DNS для каждого блога как минимум, и это боль (отсюда и почему мы используем cPanel), плюс у вас есть все ваши другие настройки виртуального хостинга , С mod_rewrite, поскольку вы будете знать, что он будет использовать единую зону wild-card для управления поддоменами, а правило mod_rewrite легко применить. Оттуда он просто создает папку и перенаправляет запросы на поддомен к ней или направляет сценарий для управления вашим приложением в зависимости от того, что вы делаете.
Истина заключается в том, что для автоматизированной системы, использующей поддомены, я бы использовал mod_rewrite, но для чего-то более сложного, как полномасштабная премиальная CMS, требующая полного юридического соответствия, управления квотами, приостановки, завершения и удаления файлов, тогда я бы рекомендовал посмотреть на хост-панель управления, такая как cPanel, в качестве возможного решения.
У тебя есть правильная идея. Вы сохраняете одну кодовую базу, работающую (ради аргумента) на одном IP-адресе. Вам не нужно беспокоиться о виртуальных хостах или даже mod_rewrite (помимо того, что вам нужно для вашего приложения).
Веб-приложение просто обрабатывает любые запросы на этот IP-адрес (на порту 80 или 443 или что-то еще).
Когда ваше приложение загружается в ответ на запрос, оно заглядывает в $ _SERVER ['HTTP_HOST'] и настраивается для клиента, связанного с этим доменным именем. Если не найдено, это 404s, или что-то самое важное.