serverest 3.2.0 → 3.2.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "serverest",
-  "version": "3.2.0",
+  "version": "3.2.2",
   "description": "Servidor REST local de forma rápida e simples para estudo de testes de API",
   "author": "Paulo Gonçalves <author@serverest.dev> (https://www.linkedin.com/in/paulo-goncalves/)",
   "license": "GPL-3.0",

package/src/app.js

@@ -50,6 +50,11 @@ if (process.env.BLOCKED_IPS) {
 }
 
 app.set('json spaces', 4)
+// Confia em exatamente um proxy, que é o do Cloud Run. Sem isso req.ip resolve para o
+// endereço do proxy e todos os clientes viram a mesma chave no rate limiter. Com 'true'
+// o Express passaria a ler o primeiro endereço do X-Forwarded-For, que o próprio cliente
+// pode forjar, então o número de saltos precisa ser explícito.
+app.set('trust proxy', 1)
 app.use(express.json())
 app.use(express.urlencoded({ extended: false }))
 app.use(queryParser())

package/src/middlewares/rate-limiter.js

@@ -6,9 +6,20 @@ const {
 } = require('../utils/ambiente')
 const { LOAD_TEST_DETECTED } = require('../utils/constants')
 
-const rateLimiter = new RateLimiterMemory({
-  points: 600, // requests
-  duration: 30 // segundo por IP
+// Limite por cliente. Depende do 'trust proxy' definido no app.js: sem ele req.ip resolve
+// para o endereço do proxy do Cloud Run e este limite passaria a valer para todos somados.
+const limitePorIp = new RateLimiterMemory({
+  points: 300, // requests
+  duration: 30 // segundos, por IP
+})
+
+// Limite agregado do container. Existe porque o limite por IP, sozinho, não impõe teto ao
+// total: bastariam vários clientes simultâneos para saturar a instância, que roda com
+// 256 MiB e max-instances 1. Fica acima do limite por IP para que um único cliente abusivo
+// seja barrado pelo próprio limite antes de consumir a cota que protege os demais.
+const limiteGlobal = new RateLimiterMemory({
+  points: 900, // requests
+  duration: 30 // segundos, somando todos os clientes
 })
 
 module.exports = async (req, res, next) => {
@@ -16,11 +27,17 @@ module.exports = async (req, res, next) => {
     return next()
   }
 
-  await rateLimiter.consume(req.ip)
-    .then(() => next())
-    .catch(() => {
-      return res.status(429).send({
-        message: LOAD_TEST_DETECTED
-      })
+  try {
+    // O global vem primeiro de propósito. Avaliar os dois em paralelo faria a requisição
+    // consumir a cota individual mesmo quando o bloqueio viesse do limite agregado, o que
+    // penalizaria clientes inocentes durante congestionamento e, pior, criaria uma chave
+    // por endereço no mapa mesmo para requisições já rejeitadas.
+    await limiteGlobal.consume('global')
+    await limitePorIp.consume(req.ip)
+    return next()
+  } catch (_) {
+    return res.status(429).send({
+      message: LOAD_TEST_DETECTED
     })
+  }
 }

package/src/server.js

@@ -7,16 +7,57 @@ require('dotenv').config({ path: path.resolve(__dirname, '../.env'), quiet: true
 
 const colors = require('colors')
 const debug = require('debug')('nodestr:server')
+const fs = require('fs')
 const http = require('http')
+const util = require('util')
 const open = require('open').default
 
 const { version } = require('../package.json')
 const { formaDeExecucao, urlDocumentacao, aplicacaoExecutandoLocalmente } = require('./utils/ambiente')
 const { conf } = require('./utils/conf')
 const getRandomFinancialContributor = require('./utils/getRandomFinancialContributor')
+const { log } = require('./utils/logger')
 
 const DEFAULT_PORT = 3000
 
+// Erros fora do ciclo de uma requisição encerram o processo sem deixar registro da causa,
+// o que no Cloud Run aparece apenas como um container reiniciando sem explicação.
+/* istanbul ignore next */
+process.on('uncaughtException', valor => {
+  // Node permite lançar qualquer valor, não só Error. Sem esta normalização, um throw de
+  // string ou null faria o próprio handler lançar ao acessar .code, perdendo o registro
+  // da causa, que é justamente o que estes handlers existem para garantir.
+  const erro = valor instanceof Error ? valor : new Error(util.inspect(valor))
+
+  // Responder a uma requisição já encerrada é inofensivo: a resposta chegou ao cliente e o
+  // processo segue íntegro. Derrubar o servidor por isso custaria uma indisponibilidade
+  // inteira para corrigir nada.
+  if (erro.code === 'ERR_HTTP_HEADERS_SENT') {
+    log({ level: 'error', message: `Tentativa de responder requisição já encerrada: ${erro.message}` })
+    return
+  }
+
+  encerrar(`Exceção não capturada: ${erro.message}. Stack: ${erro.stack}`)
+})
+
+/* istanbul ignore next */
+process.on('unhandledRejection', motivo => {
+  encerrar(`Promise rejeitada sem tratamento: ${motivo instanceof Error ? motivo.stack : util.inspect(motivo)}`)
+})
+
+// Sai de imediato em vez de drenar as conexões abertas. Com max-instances 1 no Cloud Run
+// não existe outra instância para atender quem chegar durante a drenagem, então esperar
+// só adiaria a subida do container substituto e prolongaria a indisponibilidade.
+/* istanbul ignore next */
+function encerrar (mensagem) {
+  // console.log é assíncrono quando stdout é um pipe, caso do Cloud Run, e process.exit
+  // não drena writes pendentes. A escrita síncrona no stderr garante que a causa fique
+  // registrada mesmo que o log estruturado seja truncado pelo encerramento.
+  fs.writeSync(2, `${mensagem}\n`)
+  log({ level: 'error', message: mensagem })
+  process.exit(1)
+}
+
 const yargs = require('yargs/yargs')
 const { hideBin } = require('yargs/helpers')