Despliegue

Ejecutar el admin detrás de un proxy inverso cambia dos cosas que en desarrollo local puede ignorar: la clave secreta debe ser estable entre los procesos worker, y las URLs generadas deben reflejar HTTPS aunque su aplicación solo reciba HTTP plano desde el proxy.

import os

from sqlalchemy import create_engine
from starlette.applications import Starlette
from starlette_admin.contrib.sqla import Admin, ModelView

from myapp.models import Post

engine = create_engine(os.environ["DATABASE_URL"])
app = Starlette()

admin = Admin(
    engine,
    title="My Admin",
    base_url="/admin",
    secret_key=os.environ["ADMIN_SECRET_KEY"],
)
admin.add_view(ModelView(Post))
admin.mount_to(app)

uvicorn myapp.main:app --forwarded-allow-ips='*' --proxy-headers

Clave secreta

Admin genera una secret_key aleatoria al arrancar cuando usted no pasa una. Esto es aceptable para un único proceso local, pero cada proceso worker genera su propia clave de forma independiente, por lo que un token CSRF firmado por un worker no se validará en otro. Defina secret_key a partir de una variable de entorno antes de ejecutar más de un proceso. Consulte Seguridad para conocer el modo de fallo completo con múltiples workers y cómo se utiliza la clave.

Proxy inverso y HTTPS

Admin construye cada enlace interno (páginas de listado, formularios de edición, exportaciones, el mount /static, los archivos subidos servidos a través de /_files/...) llamando a request.url_for(...), que deriva su esquema de la petición entrante. Cuando un proxy como Nginx, Caddy o Traefik termina TLS y reenvía HTTP plano a su aplicación, Starlette no puede saber que la petición original era HTTPS a menos que el proxy envíe X-Forwarded-Proto y su servidor ASGI confíe en él. Si deja esto sin configurar, los enlaces generados degradan a http://, lo que los navegadores bloquean o reescriben cuando la página misma se cargó sobre HTTPS.

Corrija esto en dos lugares:

1. El proxy reenvía la cabecera:

   nginx

   location /admin/ {
       proxy_pass http://127.0.0.1:8000/admin/;
       proxy_set_header Host $host;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   }
   

2. Uvicorn confía en ella, mediante --proxy-headers junto con --forwarded-allow-ips indicando la IP del proxy (o '*' si el proxy solo es accesible desde dentro de su red):

   uvicorn myapp.main:app --forwarded-allow-ips='*' --proxy-headers
   

El uvicorn.workers.UvicornWorker de Gunicorn lee estas dos mismas opciones de --forwarded-allow-ips. Consulte la documentación de despliegue de Uvicorn para ver el conjunto completo de opciones para gestores de procesos.

Recursos estáticos

Los CSS y JS del admin se distribuyen dentro del paquete starlette_admin, y Admin los sirve él mismo mediante un mount /static bajo base_url en lugar de hacerlo desde un host estático separado. static_dir solo le permite sobrescribir archivos individuales (consulte Plantillas); no traslada el servicio de recursos fuera del proceso de su aplicación. No existe ninguna opción integrada para servir estos recursos desde un CDN. Si necesita una, añada en la capa de proxy una regla de Cache-Control favorable al caché para {base_url}/static/*.

Los archivos subidos son distintos: LocalStorage también los sirve a través de la aplicación (/_files/{storage}/{path}, de modo que el middleware de autenticación sigue aplicándose), pero S3Storage y otros backends remotos pueden servirlos directamente desde el proveedor. Consulte Almacenamiento de archivos.

Próximos pasos

• Seguridad: El problema de la secret_key con múltiples workers en detalle, además de todo lo que las protecciones integradas cubren y no cubren.
• Autenticación: Restrinja el acceso al admin antes de que sea accesible en producción.
• Almacenamiento de archivos: Configuración de S3Storage y otros backends remotos.