AMPLIACIÓN POSTERIOR
El recorrido actual publica manualmente deploy.zip y usa el dominio predeterminado. Este tema prepara una siguiente fase; no forma parte del procedimiento habitual del equipo que estamos reproduciendo.
CAPÍTULO 9 · El mismo proyecto llega a Azure
El nombre público puede cambiar sin que cambie el proyecto
La primera publicación puede utilizar el hostname predeterminado de App Service. Eso permite completar el aprendizaje sin comprar ni configurar todavía un dominio. Si más adelante se necesita una dirección propia, no será solamente un cambio de texto en el navegador: habrá que relacionar ese nombre con el destino correcto y proteger la conexión.
Estudiamos DNS, validación del dominio y TLS como una ampliación posterior. También reconocemos que el plan debe admitir las funciones necesarias. Una nueva dirección afecta los hosts permitidos y, cuando hay autenticación, las URLs de retorno. El nombre público participa en varias decisiones que ya existen dentro del proyecto.
Volvemos por ahora al dominio con el que estamos publicando. Sea predeterminado o propio, la conexión externa pasa por infraestructura que puede terminar TLS antes de entregar la petición a Django. Entender ese tramo resulta imprescindible para que la aplicación interprete correctamente si el usuario llegó por HTTPS.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Un nombre llega a un servicio seguro
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Dominio. Nombre público de la app
- DNS. Resuelve y verifica propiedad
- TLS. Certificado y binding válidos
- Django. Hosts, CSRF y enlaces canónicos
01 / EL PROBLEMA
¿Para qué sirve?
Un dominio puede resolver correctamente por DNS y aun así tener un certificado inválido, un Host rechazado por Django o callbacks de identidad rotos.
02 / COMPRENDER
El concepto, explicado
Ampliación posterior del recorrido: el equipo publica actualmente por ZIP manual y usa el dominio predeterminado. Esta lección conserva la base conceptual para abordar dominio personalizado y TLS cuando se configure esa fase.
Para un subdominio suele usarse CNAME al hostname de App Service. Para el dominio raíz se utiliza el registro apropiado, normalmente A según la guía. TXT asuid demuestra propiedad y ayuda a prevenir apropiación del subdominio.
Validar el dominio y asociar un certificado son pasos diferentes. SNI permite certificados por nombre; un dominio agregado sin binding TLS no garantiza HTTPS válido.
Comprar un dominio tiene costo separado. Revisa nivel de plan y condiciones del certificado administrado antes de elegirlo; no prometas plazo fijo de emisión.
En Django ALLOWED_HOSTS contiene hosts, CSRF_TRUSTED_ORIGINS contiene orígenes con esquema cuando se necesitan. En una app autenticada, callbacks y enlaces canónicos deben usar el dominio final.
03 / CONSTRUIR
Implementación paso a paso
- Confirma dominio, control del DNS y plan compatible.
- En Custom domains copia los registros requeridos desde el recurso correcto.
- Agrega CNAME/A y TXT según dominio raíz o subdominio; verifica resolución.
- Valida y asocia el dominio en App Service.
- Configura certificado y binding TLS; verifica nombre, cadena y renovación.
- Actualiza Django y callbacks aplicables, prueba HTTPS y documenta retiro seguro de DNS.
04 / APLICAR
Ejemplo en SensorHub
# Ejemplo conceptual: usa los valores que entrega tu App Service.
# DNS subdominio:
# CNAME academia -> <HOSTNAME_REAL_APP_SERVICE>
# TXT asuid.academia -> <DOMAIN_VERIFICATION_ID>
# Settings Django del entorno:
ALLOWED_HOSTS = ["academia.example.com"]
CSRF_TRUSTED_ORIGINS = ["https://academia.example.com"]
CANONICAL_ORIGIN = "https://academia.example.com"Cómo leer el ejemplo
- No incluyas https:// en ALLOWED_HOSTS.
- El dominio example.com es ilustrativo y no debe copiarse como destino real.
- CSRF_TRUSTED_ORIGINS no concede permisos ni es una configuración CORS.
Error habitual
Usar CNAME para todo dominio sin revisar DNS o eliminar la app dejando apuntamientos DNS abandonados.
05 / PRACTICAR
Tu turno
La página carga por azurewebsites.net pero el dominio propio devuelve DisallowedHost. ¿Dónde corriges?
Ver solución orientativa
Verifica que el dominio llegue al recurso correcto y añádelo al ALLOWED_HOSTS del entorno. Revisa por separado TLS y CSRF para escrituras; no habilites comodines como solución rápida.
06 / VERIFICAR
Cómo sabes que funciona
- DNS resuelve al destino esperado.
- HTTPS tiene certificado válido para el nombre.
- Django acepta únicamente hosts definidos.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Endurecer Django detrás de un proxy →Continuar en modo relato