Использование поддомена для идентификации клиента

Question

Я работаю над созданием приложения Silverlight, в то время как мы хотим, чтобы клиент мог перейти по URL-адресу, например:

http://{клиент}.domain.com/

и войдите в систему, где часть {клиент} - это название их компании.так, например, в Google было бы:

http://google.domain.com/

Мне было интересно, смог ли кто-нибудь в silverlight использовать эту модель поддомена для принятия решений по вызову веб-сервера, чтобы вы могли переключиться на определенную базу данных для выполнения запроса?К сожалению, это то, что совершенно необходимо для проекта, поскольку мы пытаемся облегчить их сотрудникам получение специфичной для их компании информации для нашего программного обеспечения.

Answer 1

Разве не сработало бы поместить службу на определенный поддомен, например wcf.example.com, а затем настроить файл междоменной политики в службе, чтобы разрешить ей доступ к нему?

Пока это будет работать, вы могли бы просто загрузить silverlight в соответствующий поддомен, а затем передать этот поддомен вашему сервису и позволить ему делать свое дело.

Некоторые примеры этого приведены ниже:

• Междоменные сервисы Silverlight
• Помощники по Междоменной политике Silverlight

Answer 2

На стороне сервера вы можете проверить заголовок HTTP 1.1 Host, чтобы увидеть, как пользователь попал на ваш сервер, и выполнить необходимые настройки на основе этого.

Answer 3

Я думаю, вы не можете сделать это с помощью Silverlight в одиночку, я знаю, что вы не можете сделать это без проблем с Javascript, Ajax и т.д..Это связано с тем, что браузеры - по соображениям безопасности - рассматривают поддомен иначе, чем подстраницу.

Как насчет следующей идеи:Вставьте правило перезаписи в программное обеспечение вашего веб-сервера.Так что , если http://google.domain.com вызывается, веб-сервер сам переписывает URL-адрес на что-то вроде http://www.domain.com/google/ (или лучше: http://www.domain.com/customers/google/).Помогло бы это?

Answer 4

Georgi:

Это помогло бы, если бы все было статично, но, увы, все это будет динамичным.Моя надежда состояла в том, чтобы иметь 1x развертывание для приложения и использовать http://google.domain.com/ идея переключиться на правильную базу данных для пользователя.Я помню, что делал это однажды, когда мы создавали веб-сайт asp.net, используя контекст домена, чтобы определить, какой скин использовать и т.д.

Атес:Не могли бы вы подробнее объяснить, о чем вы говорите?..похоже, вы близки к тому, что я пытаюсь придумать.Вы видели такой учебник по этому вопросу?

Единственный другой способ, который я придумал, чтобы заставить это работать, - это создать метабазу, которая при входе пользователя в систему переключит его на соответствующую базу данных по мере необходимости...просто я тоже думал о том, чтобы сказать Клиенту x, чтобы он ударил:

http://ClientX.domain.com/ было бы приятнее, чем сказать "ударить" http://www.domain.com/ и войдите в систему.Казалось, что если бы они указали свое имя и показали его персонализированным для них прямо на экране входа в систему, это было бы гораздо привлекательнее для клиентской базы.

Answer 5

@Ричард Би:Нет, я не могу припомнить ни одного подобного учебника, который я видел раньше.Я постараюсь быть более подробным.

Более подробно рассмотрим подход на стороне сервера:

1. Направляйте *.example.com на тот же IP-адрес в настройках DNS.
2. Серверное приложение, которое обрабатывает вход в систему, проверяет Host HTTP- заголовок (например,серверная переменная "HTTP_HOST" на некоторых платформах).Это будет содержать точный код subdomain.example.com, который клиент использовал для доступа к вашему серверу.Извлеките часть поддомена и продолжайте...

Также может существовать подход только на стороне клиента.Я мало что знаю о Silverlight, но я предполагаю, что вы должны иметь возможность взаимодействовать Silverlight с JavaScript.Вы могли бы прочесть document.location с помощью JavaScript и передайте его вашему апплету Silverlight, после чего выполните дальнейшую выборку данных и т.д.логика будет зависеть от поддомена, который был передан JavaScript.

Answer 6

@Ates:

Именно это мы и сделали, когда писали систему ASP.Net...мы подключили множество * .example.com хостов к веб-серверу и обрабатывали их с помощью HTTP-заголовков.Задержка возникает при работе с WCF, передающим информацию между клиентом и сервером...он может существовать только в одном домене...

Так, например, когда у вас есть {client}.example.com и {sandbox}.example.com, служба WCF не может быть зарегистрирована для обоих.Он также не может быть зарегистрирован просто как * .example.com или example.com, так что именно здесь появляется уловка 22.со всем остальным у меня есть предварительные знания об обращении.

Я вспоминаю метод, с помощью которого приложение может "подделать" другое доменное имя в определенных случаях.Я так понимаю, в этом случае мне нужно было бы сделать такую конфигурацию?Я полагаю, что еще многое предстоит исследовать.