Autenticación, headers y estados HTTP en REST
Separa credenciales, autorización, transporte y respuesta en REST Protheus.
Descripción general
Identificar implementación: autenticación de REST AdvPL/2.0 y tlppCore no tiene configuración intercambiable. Protheus documenta Basic y Bearer. Basic codifica en Base64 sin cifrar; usar HTTPS. En JWT, enviar access_token en Authorization: Bearer; refresh_token corresponde a renovación, no sustituye token de acceso. Leer expires_in sin fijar duración universal. TOTVS informa autenticación obligatoria desde release 12.1.2410: no reutilizar consejo antiguo de desactivar Security. Excluir credenciales de URL, código versionado y logs. (TOTVS, s.f., refs. 1–4) 401 requiere autenticación válida; 403 indica rechazo de atención; 404 recurso no encontrado y 500 error de servidor. HTTP 200 no sustituye validar resultado de negocio del cuerpo. Ejemplo representa HTTP con dominio, ruta y token ficticios; no llama endpoint real ni configura servicio. (IETF, 2022, ref. 5)
Retorno
No hay retorno único: se trata de un flujo compuesto.
Ejemplo comentado
GET /rest/test-resource HTTP/1.1
Host: api.example.invalid
Accept: application/json
Authorization: Bearer <ACCESS_TOKEN>No se ejecutó solicitud. Usar ruta contratada y obtener token por flujo soportado sin publicarlo. Tratar estado y cuerpo por separado. En revisión: ejemplo editorial no compilado ni ejecutado en Protheus. Comprobar includes, release, RDD y contexto antes de probar.
- Guardar secretos en mecanismo apropiado, restringir permisos y renovar según contrato. Excluir Authorization, contraseñas y refresh_token de logs; probar token ausente, vencido y usuario sin acceso.
- En revisión: ejemplo editorial no compilado ni ejecutado en Protheus. Comprobar includes, release, RDD y contexto antes de probar.
Comentarios
Todavía no hay comentarios aprobados.
Inicia sesión con Google o Microsoft para comentar.