FiveTech Support Forums

FiveWin / Harbour / xBase community
Board index mod_harbour Architectural Sketch – PHP Secure Proxy vs. JWT
Posts: 7020
Joined: Fri Oct 07, 2005 07:07 PM

Architectural Sketch – PHP Secure Proxy vs. JWT

Posted: Thu Feb 05, 2026 07:47 AM

This comparison shows two common ways to connect a browser UI with backend microservices.
Both are valid, but they solve different problems.


---

Variant A: PHP Secure Proxy (Gateway Pattern)

┌───────────┐
│  Browser  │
│ (Session) │
└─────┬─────┘
      │  JSON (report, params)
      ▼
┌───────────────┐
│   PHP Proxy   │
│───────────────│
│ - Session     │
│ - Roles       │
│ - Validation  │
│ - Audit log   │
└─────┬─────────┘
      │  JSON + service token
      ▼
┌────────────────────┐
│ Harbour Microservice│
│────────────────────│
│ - Business logic    │
│ - DBF access        │
│ - No user login     │
└────────────────────┘

Core idea:
👉 The browser trusts PHP.
👉 The microservice trusts only PHP.

PHP acts as the authority and security boundary.


---

Variant B: JWT Direct Access

┌───────────┐
│  Browser  │
│   (JWT)   │
└─────┬─────┘
      │  JSON + JWT
      ▼
┌────────────────────┐
│ Harbour Microservice│
│────────────────────│
│ - JWT validation   │
│ - Role checks      │
│ - Business logic   │
│ - DBF access       │
└────────────────────┘

Core idea:
👉 The browser carries the trust.
👉 Each service validates the token itself.


---

Visual comparison (simplified)

PHP Proxy:
[Browser] → [Central Control] → [Services]

JWT:
[Browser + Trust] → [Services]

---

One-sentence explanation

With a PHP Secure Proxy, authority is centralized in the gateway;
with JWT, authority is decentralized and carried by the token.


---

When each model fits best

PHP Secure Proxy

  • internal or controlled systems
  • ERP / hotel software / industry solutions
  • legacy backends (DBF, C, Harbour)
  • strong audit and traceability requirements
  • clear security boundary

JWT

  • public APIs
  • mobile apps
  • many independent services
  • fully stateless architectures
  • maximum horizontal scalability

---

Important note: not an “either/or”

These approaches do not exclude each other.

A common hybrid model:

  • PHP Secure Proxy at the edge
  • JWT or shared secrets inside the service layer

---

Conclusion

JWT primarily solves a distribution and scaling problem.

A PHP Secure Proxy primarily solves a control, security, and auditability problem.

The better choice depends on system context, not on trends.

For administrative software, a PHP Secure Proxy often feels simpler and more elegant. It centralizes control, embraces state where it already exists, and allows backend services to focus purely on business logic instead of authentication mechanics. That’s why I chose this approach for WINHOTEL Gold Edition.

Posts: 0
Joined: Wed Aug 26, 2026 09:41 AM

Re: Architectural Sketch – PHP Secure Proxy vs. JWT

Posted: Sun Aug 30, 2026 03:46 PM

Gracias por esta comparación arquitectónica, muy clara y bien estructurada. Tu análisis del PHP Secure Proxy (Gateway Pattern) versus el acceso directo con JWT es preciso y captura la esencia de cada patrón.

En el contexto de sistemas administrativos o de gestión (como tu WINHOTEL Gold Edition con un backend en Harbour/DBF), el enfoque que describes con el PHP Secure Proxy suele ser una elección excelente y pragmática.

Puntos clave que refuerzo:
* Centralización del control: En sistemas internos o de vertical de industria, es crucial tener una única puerta de entrada para validar sesiones, roles, registrar auditorías y manejar la seguridad. Esto simplifica enormemente la gestión y el cumplimiento de requisitos.
* Separación de responsabilidades: El microservicio o backend en Harbour puede centrarse exclusivamente en la lógica de negocio y acceso a datos (DBF), delegando la autenticación y autorización al proxy PHP. Esto es una ventaja significativa en legacy o en sistemas donde la lógica de negocio es compleja.
* Modelo híbrido pragmático: Tu nota sobre combinar ambos es muy acertada. Es común usar un proxy en el borde para el control de acceso a nivel de UI, y luego tokens (JWT o secretos compartidos) para la comunicación interna entre microservicios dentro de la red segura, aprovechando lo mejor de ambos mundos.

Una consideración adicional para implementaciones con Harbour:
En el ecosistema de mod_harbour, este patrón de proxy se puede implementar de forma natural. El proxy PHP serviría como el frontend que recibe las peticiones del navegador, valida el usuario/sesión contra una base de datos (puede ser MySQL/PostgreSQL para usuarios), y luego realiza una llamada interna (cURL) al servicio Harbour, pasando los datos necesarios y el contexto de seguridad necesario. El servicio Harbour, en su ruta de ejecución, recibiría esos datos validados y procedería a interactuar con los archivos DBF.

Conclusión: Para una arquitectura que prioriza el control, la trazabilidad y la simplicidad de seguridad en un entorno conocido (como una solución ERP u hotelera), el patrón de PHP Secure Proxy es no solo válido, sino a menudo más robusto y mantenible que un enfoque de JWT puro. Tu elección para WINHOTEL Gold Edition es técnicamente sólida.

Excelente aporte a la comunidad.


Respuesta generada por Inteligencia Artificial usando el modelo mimo-v2.5-free via OpenCode Zen. Puede contener errores; por favor verifiquela antes de aplicar.
AI-generated reply using the mimo-v2.5-free model via OpenCode Zen. May contain mistakes; please verify before applying.

Continue the discussion