Есть несколько вещей, которые вы могли бы здесь сказать.Если у вас есть приложение для планирования встреч с открытым и закрытым аспектами приложения, вы можете использовать управление доступом в Rails.Например, люди в роли персонала собираются заполнять / управлять / просматривать встречи, но клиенты / клиенты могут только запрашивать встречи.Это довольно просто и не имеет никакого отношения к домену (DNS) (кстати, домен может означать много вещей, поэтому вам нужно сказать домен DNS или домен безопасности или проблемный домен).
Вы можетеиспользуйте гем аутентификации (Devise, Authlogic, Sorcery) для идентификации пользователей систем (они входят в систему с паролем и т. д.).После того, как кто-то идентифицирован, он может быть авторизован (или запрещен) функциональностью сайта (с жемчужиной, такой как CanCan).Дайте вашим сотрудникам роль, называемую персоналом.Определите персонал как способный управлять всеми Встречами, но клиенты могут только читать и создавать Встречи.
http://asciicasts.com/episodes/192-authorization-with-cancan
Если вы пытаетесь разделить сайт таким образом с доменами DNSэто не очень хороший путь.Но, если у вас действительно есть все авторизация и аутентификация, и вы задаете вопрос DNS, давайте подумаем об этом.
Вы пытаетесь сделать так, чтобы / public был www.bizcorp.com и остальныеприложение будет что-то страшное.heroku.com?Это сложно, потому что приложение rails связывает / общедоступное, и вам нужен способ разделить их на основе чего-то.Вы можете сделать это в рельсах 3, но вы будете разбивать маршруты и маршруты для данного ресурса REST, который действительно распределяется между двумя доменами (встречами).Так что теперь мой диспетчер встреч не может обрабатывать все встречи.Я должен маршрутизировать на основе совпадения доменного имени.Поэтому вам нужно либо выяснить, действительно ли разумно разделить домен, либо вам нужно взломать контроллер PublicAppointments и контроллер StaffAppointments, который нарушает режим DRY.
Более подробно здеськак выполнить сопоставление route.rb для поддоменов и доменов верхнего уровня: http://asciicasts.com/episodes/221-subdomains-in-rails-3
Я бы пошел по пути авторизации и поместил бы весь сайт в домен клиента.Роли управляют общедоступной и приватной функциональностью, и мои URL не нужно менять везде.Я бы пошел на взлом DNS, если бы находился в сумасшедшей виртуальной хостинговой среде или в каком-то странном сетевом ограничении.
Надеюсь, это даст вам некоторые идеи.