Creé un middleware personalizado que hace que la API y el administrador sean inalcanzables cuando lo habilito.
El middleware es bastante simple, agrega una identificación de solicitud a la solicitud entrante en el servidor:
const { createNamespace } = require('cls-hooked'); const { v4: uuidv4 } = require('uuid'); const loggerNamespace = createNamespace('logger'); module.exports = (strapi) => { return { initialize() { strapi.app.use((ctx, next) => { const reqId = ctx.request.get('X-Request-Id') || uuidv4(); ctx.response.set('X-Request-Id', reqId); loggerNamespace.run(() => { loggerNamespace.set('requestId', reqId); next(); }); }); }, }; }; Se habilita usando el archivo de configuración ./config/middleware.json :
module.exports = { settings: { addRequestId: { enabled: true, }, }, }; Luego, cuando está habilitado, llamar a un punto final de API o intentar conectarse al administrador da como resultado 404 No encontrado.
Uso strapi 3.6.8 con el nodo 14.18.1 .
¿Alguna idea de por qué?
PD: Sospeché que cls-hooked era el culpable, pero eliminarlo para probarlo con un middleware anémico tampoco funciona.
@Salvino me puso en el camino correcto sugiriendo que debería esperar la ejecución de next .
Buscando en el código de cls-hooked , encontré el método runPromise que es similar a run y devuelve una Promise que se puede esperar. Resolvió el problema.
Código fijo:
const { createNamespace } = require('cls-hooked'); const { v4: uuidv4 } = require('uuid'); const loggerNamespace = createNamespace('logger'); module.exports = (strapi) => { return { initialize() { strapi.app.use(async (ctx, next) => { const reqId = ctx.request.get('X-Request-Id') || uuidv4(); ctx.response.set('X-Request-Id', reqId); await loggerNamespace.runPromise(async () => { loggerNamespace.set('requestId', reqId); await next(); }); }); }, }; };