Un número creciente de aplicaciones web (más notablemente Basecamp 37Signals') asignar un subdominio para cada usuario/cuenta. Me preguntaba cuáles son los pros y los contras de ese enfoque. ¿Hay alguna razón en particular para hacer esto o es solo una característica cosmética? ¿Esto, por ejemplo, permite una escalabilidad mejor/más fácil y una seguridad mejorada?Pros/contras de subdominios en aplicaciones web
creo que puede estar relacionado con la política de mismo origen. Si las páginas de miembros de dos usuarios están en subdominios diferentes, los navegadores evitarán que los scripts de un subdominio accedan a documentos en otro subdominio. Entonces, si Mallory registra un sitio (mallory.example.org) y coloca una secuencia de comandos maliciosa, esa secuencia de comandos no podrá modificar el sitio DOM de Alice (alice.example.org). Si usaran rutas en su lugar (example.org/mallory y example.org/alice), el SOP no funcionaría, y el script de Mallory podría hacer todo tipo de cosas malas en la página de Alice, como falsificar una pantalla de inicio de sesión y publicar las contraseñas. De regreso a Mallory.
Esta protección SOP funciona incluso cuando ambos subdominios se resuelven en la misma IP: siempre que la parte del host de la URL sea diferente, los navegadores modernos bloquearán los intentos de scripts entre dominios (y algunas otras cosas potencialmente peligrosas).
Gracias por su aporte. En otras palabras, sugieres que tiene una ventaja de seguridad definitiva. –
Estamos haciendo esto por la única razón de que a las personas les gusta ver su marca. Conversion Support los clientes pueden elegir un subdominio para la marca de su panel de control y luego personalizarlo con su logotipo y colores.
La seguridad no es un factor, ya que nadie puede poner guiones. Es más una característica estética.
yo quiero mencionar que dos subdominios se pueden comunicar si ambas páginas tienen la document.domain JavaScript conjunto de propiedades al dominio. Por ejemplo:
document.domain = 'example.com';
Esto significa que la política del mismo origen está deshabilitado para a.example.com y b.example.com a n.example.com, siempre y cuando todos los subdominios tienen el conjunto de propiedades.
Gracias por su respuesta. Si solo se trata de una característica cosmética, ¿no sería más fácil usar mod_rewrite para dar al usuario la impresión de tener un subdominio separado? –
@bare_nature - Si está usando Apache, creo que podría. Pero supongamos que estás usando Jetty? Jetty tiene un motor de reescritura, pero está integrado en el nivel de aplicación para 301 redirecciones. Un filtro de primavera o interceptor en mi caso hace el trabajo perfectamente, y nos permite realizar acciones diferentes según el subdominio. Además, las reescrituras implican más procesamiento y ninguna lógica comercial. Además, no son dinámicos, debe codificarlos. ¿Cuánto más rápido sería tu aplicación si * .example.com resolviera tu aplicación de inmediato? a.example.com, b.ejemplo.com, sin procesamiento adicional. – jmort253
El uso de un subdominio para cada aplicación resuelve el problema básico de saber qué aplicación utilizar. Esto permite al usuario abrir varias aplicaciones a la vez en el mismo navegador.
Un beneficio adicional es que mediante la unión del inicio de sesión para el subdominio un usuario puede iniciar sesión como un usuario diferente en las diferentes aplicaciones. No es necesario cerrar la sesión de la aplicación A para iniciar sesión en la aplicación B. Se puede iniciar sesión en ambos con un inicio de sesión diferente.
El beneficio de la escalabilidad depende de su arquitectura. Cuantos más recursos compartidos (una única base de datos) tenga la aplicación, más difícil será separar la aplicación. Por otro lado, si tiene una base de datos para cada aplicación, el control de versiones de las bases de datos es mucho más problemático. Creo que la mayoría de las aplicaciones usan una única base de datos y subdominios virtuales. Una sola base es más fácil de mantener (pero más difícil de escalar).
Un punto negativo del uso de subdominios es que para SSL necesita un certificado comodín que cuesta más que un certificado de dominio único.
Gracias por la respuesta, Stefaan. Creo que ha leído mal mi pregunta (o no estaba lo suficientemente claro), pero estoy pensando en usar subdominios para diferentes usuarios, no para diferentes aplicaciones. De todos modos, la mayor parte de su razonamiento se aplica en cualquier caso. También es interesante saber lo que mencionas sobre los certificados SSL. No sabía eso. –
Esto puede ser útil: http://myhosting.com/blog/2010/08/benefits-subdomains-ezinearticles/ –
Gracias Harry. Sin embargo, el enlace que menciona habla más sobre el uso (más) tradicional de los subdominios y no específicamente sobre la creación dinámica de subdominios en las aplicaciones web. –