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

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

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

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

• Междоменные службы Silverlight
• Междоменная политика Silverlight Помощники

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

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

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

Георгий:

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

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

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

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

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

Подробнее о серверном подходе:

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

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

@Ates:

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

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

Я вспоминаю метод, с помощью которого приложение может в определенных случаях «подделать» другое доменное имя. Я так понимаю, мне нужно было бы сделать такую ​​настройку? Я верю, что многое еще предстоит изучить.