- Shipped
- 20 de agosto de 2026 a las 3:48 UTC
- Author
- Kamo
- Commit
- 9e244db
Abrir una instancia de Linux asignada siempre aterrizó en el genérico de Guacamole "Un error ha ocurrido y esta acción no se puede completar" modal, y siempre funeró después de un refresca. El límite de la tarifa de escritorio de ancho de ancho era promedio de 10 / reventar 20, pero una carga fría de la El enlace profundo de SSO dispara 41 solicitudes dentro de un segundo. Traefik respondió 23 y 429'd 18 de ellos - incluyendo las tres conexionesGroups/ROOT/llamadas de árbol y la la conexión websocket-tunnel. El usuario de GuacamolePageService.getHomePage () alimenta a esos llamadas de árbol en un cable de $q.all para solicitarService.DIE, así que un solo 429 allí emite guacFatalPageError y cambia toda la UI por APP.ERROR-PAGE-UNAVAILABLE -- el modal exacto -- mientras que el túnel rechazado no significaba nada conectado de todos modos. El refrescarse "arreglado" sólo porque la segunda carga sirve los paquetes del navegador caché y así se queda dentro del cubo. Se pedía un límite para hacer dos trabajos. Diviértelos: el anfitrión mantiene una página cargada límite con espacio real (promedio 100 / reventar 200, 5x una carga fría), y el El acelerador de relleno de credenciales mantiene sus números originales en el único camino que En realidad autentica, POST /api/tokens. Queda la prohibición por IP incorporada de Guacamole el verdadero control de la fuerza bruta debajo. Ambas rutas tienen una prioridad explícita porque kamo/kamo-no-route es un comodín **************** catch-all sitting-asent en la prioridad 1 - un escritorio ruta que no supera tiene a todo el anfitrión tragado y servido 404s. Verificado contra la puerta viva: la explosión de 41 peticiones que había vuelto previamente 23x200 / 18x429 ahora devuelve 41x200 (120 concurrentes también limpio), mientras que 30 solicitudes a /api/tokens todavía acelerado a 22 a través / 8 rechazado.