Usar un subdominio para identificar a un cliente

Question

Estoy trabajando en la creación de una aplicación Silverlight, mientras que queremos que un cliente acceda a una URL como:

http: // {cliente} .dominio.com /

e inicie sesión, donde la parte {cliente} es su nombre comercial. así, por ejemplo, google sería:

http://google.domain.com/

Lo que me preguntaba era si alguien ha podido, en Silverlight, poder utilizar este modelo de subdominio para tomar decisiones sobre la llamada al servidor web para que pueda cambiar a una base de datos específica para ejecutar una consulta. Desafortunadamente, es algo muy necesario para el proyecto, ya que estamos tratando de facilitar que sus empleados obtengan información específica de su compañía para nuestro software.

Answer 1

¿No funcionaría poner el servicio en un subdominio específico en sí mismo, como wcf.example.com, y luego configurar un archivo de política de dominio cruzado en el servicio para permitirle acceder a él?

Mientras esto funcione, puede cargar Silverlight en el subdominio adecuado y luego pasar ese subdominio a su servicio y dejar que haga lo suyo.

Algunos ejemplos de esto a continuación:

• Silverlight Servicios de dominio cruzado
• Silverlight Ayudantes de políticas de dominio cruzado

Answer 2

En el lado del servidor, puede verificar el encabezado del host HTTP 1.1 para ver cómo llegó el usuario a su servidor y hacer la personalización necesaria en función de eso.

Answer 3

Creo que no puede hacer esto solo con Silverlight, sé que no puede hacerlo sin problemas con Javascript, Ajax, etc. Esto se debe a que un subdominio es, por razones de seguridad, tratado de forma diferente a una subpágina por los navegadores.

¿Qué pasa con la siguiente idea? Inserte una regla de reescritura en el software de su servidor web. Entonces, si se llama a http://google.domain.com , el servidor web reescribe la URL a algo como http://www.domain.com/google/ (o mejor: http://www.domain.com/customers/google/ ). ¿Eso ayudaría?

Answer 4

Georgi:

Eso ayudaría si fuera estático, pero, por desgracia, todo será dinámico. Esperaba tener una implementación 1x para la aplicación y usar el http://google.domain.com/

Ates: ¿Puedes explicar más sobre lo que estás diciendo? Parece que estás cerca de lo que estoy tratando de inventar. ¿Has visto un tutorial para esto?

La única otra forma en que se me ocurrió hacer que esto funcione es tener una metabase que cuando el usuario inicia sesión, los cambiará a la base de datos apropiada según sea necesario ... solo estaba pensando que decirle al Cliente x golpear:

http://ClientX.domain.com/ hubiera sido más dulce que decir golpear http://www.domain.com/ e inicie sesión. Parecía que iban a dar con su nombre, y mostrarlo personalizado para ellos directamente desde la pantalla de inicio de sesión habría sido mucho más atractivo para la base de clientes.

Answer 5

@Richard B: No, no puedo pensar en ningún tutorial que haya visto antes. Trataré de ser más detallado.

El enfoque del lado del servidor con más detalle:

1. Dirija * .example.com a la misma IP en su configuración de DNS.
2. La aplicación de back-end que maneja el inicio de sesión verifica el encabezado HTTP Host (por ejemplo, la variable de servidor " HTTP_HOST " en algunas plataformas). Eso contendría el subdominio.example.com exacto que el cliente usó para llegar a su servidor. Extraiga la parte del subdominio y continúe ...

También puede haber un enfoque solo del lado del cliente. No sé mucho sobre Silverlight, pero supongo que deberías poder conectar Silverlight con JavaScript. Puede leer document.location con JavaScript y pasarlo a su applet Silverlight, donde la obtención de datos adicionales, etc., la lógica dependería del subdominio que fue pasado por JavaScript.

Answer 6

@Ates:

Eso es lo que hicimos cuando escribimos el sistema ASP.Net ... empujamos una gran cantidad de hosts * .example.com contra el servidor web, y lo manejamos usando los encabezados HTTP. El retraso se produce cuando se trata de WCF que empuja la información entre el cliente y el servidor ... solo puede existir en un dominio ...

Entonces, por ejemplo, cuando tiene {cliente} .example.com y {sandbox} .example.com, el servicio WCF no se puede registrar en ambos. Tampoco se puede registrar solo en * .example.com o example.com, así que ahí es donde entra la captura 22. todo lo demás tengo el conocimiento previo de manejo.

Recuerdo un método por el cual una aplicación puede "falsificar" otro nombre de dominio en ciertos casos. Supongo que en este caso, ¿tendría que hacer esa configuración? Mucho por investigar todavía creo.