Poarta de acces

Poarta e primul lucru pe care îl atinge un integrator. Pagina spune ce e o rută, cu ce se intră, cât trece pe o credențială și ce rămâne scris după o livrare.

O rută e un flux publicat

Nu există un fișier de configurare al porții. Ce se poate chema e ce s-a publicat: fluxul își aduce numele și ruta apare odată cu artefactul. Nimic nu se declară a doua oară, în alt loc.

Configurarea de mediu o cere fluxul, pe nume. O cheie declarată pe care instalația n-o oferă oprește pornirea și o numește: lipsa nu se descoperă la primul mesaj, cu o valoare goală trimisă mai departe. Aceeași verificare se poate rula fără să pornească nimic, iar comanda se încheie cu cod de eroare când lipsește o cheie.

Un flux care cere o cheie de mediu, și variabila din care o ia.

---
flow: notificare-facturare
tenant: acme
effects: [http_egress]
config: [BILLING_URL]
---

## Step: trimite
effects: [http_egress]
endpoint: "{{ ctx.BILLING_URL }}/notificari"
method: POST

# în mediul instalației:
#   NEXUS_CONFIG_BILLING_URL=https://billing.example.com/api

Prețul e scris, nu descoperit. Valoarea configurării se capturează o dată, la pornire, deci o schimbare de configurare cere o repornire. Altfel, poarta de pornire ar fi verificat alte valori decât cele pe care rulează platforma. La fel tabela de rutare a ușii gRPC: se construiește la pornire, deci un flux publicat după aceea cere o repornire ca să fie rutat. Și o scanare de pornire nu poate tăcea: un registru care nu se poate lista oprește pornirea, nu o lasă să pară verificată.

Cu ce se intră

Credențiala e o cheie de API sau jetonul unui furnizor de identitate, ambele prezentate în Authorization: Bearer. Poarta e închisă implicit; pornirea fără poartă există ca opțiune explicită și se anunță la fiecare pornire.
Metoda de autentificare e proprietate declarată a tenantului, iar o metodă pe care build-ul n-o poate executa e refuzată chiar la înregistrarea tenantului. Azi lista aia acceptă două: cheia de API și OIDC.
O cheie poartă scope-uri și, opțional, lista fluxurilor pe care are voie să le cheme. Un flux poate cere un scope anume, iar cererea se verifică după încărcarea artefactului, pentru că acolo e scris.
Poarta rulează înaintea corpului: un apelant fără credențială valabilă nu provoacă nicio citire de corp și nicio parsare.
Un refuz atribuibil intră în lanțul de audit cu subiectul lui, nu poartă niciodată credențiala, și consumă din plafonul apelantului, deci un refuz nu poate fi folosit ca pompă de scriere. Auditul e record, nu portar: dacă rândul nu se poate scrie, refuzul rămâne refuz.
O cerere SOAP trece prin aceeași poartă, neschimbată. Un refuz e 401 sau 403 HTTP simplu, niciodată un SOAP Fault: un fault poartă status de succes, iar un gateway care rutează pe status ar înainta refuzul ca răspuns.

Ce verifică ușa și ce stă în fața ei

Ce execută platforma: Verificarea cheii sau a jetonului, scope-urile, lista de fluxuri, plafonul de debit și refuzul auditat.
Ce se așază în fața ei: Terminarea TLS, la proxy-ul invers al dumneavoastră.

Platforma validează singură jetoanele OIDC / OAuth 2.0, la ușa din față, pentru fiecare tenant care își declară emitentul. Semnătura se verifică pe JWKS-ul acelui emitent, iar iss, aud și expirarea sunt obligatorii. Platforma refuză alg: none și orice algoritm HS*. Rolurile din jeton se traduc în drepturile platformei, per tenant. Un tenant declară cel mult un emitent, cu nexus tenant oidc set, iar interfața de administrare nu are pagină OIDC. Jetonul se verifică local și rămâne valid până expiră: nu există introspecție și nici revocare înainte de expirare, iar jetoanele opace nu sunt acceptate. Platforma nu emite jetoane și nu lucrează cu SAML.

În spatele ușii

Un gateway păzește ușa. NexusFabric, în același program, transformă și mesajul din spatele ei și îl pune în coadă cu reîncercări.

Transformări · Operare · Observabilitate

Debitul e al credențialei

Plafonul se pune pe cheie, la emitere, sau pe declarația unui emitent OIDC, care dă câte unul fiecărui subiect (sub). Ambele uși de mesaj, cea sincronă și cea de coadă, cheltuiesc din el, iar un refuz de debit spune când să reveniți: patru antete pe 429. Telemetria de conector nu consumă din plafon, ca un conector care împarte cheia să nu plătească de două ori pe același mesaj.

Ce rămâne scris după o livrare

Unitatea măsurată e livrarea, nu cererea: received plus exact un verdict. Pe ce ușă a intrat se citește din coloana channel, nu din felul evenimentului.
Verdictul tipizat (succeeded, fault_handled, failed) stă pe o rubrică proprie și se poate filtra după el.
Un flux poate purta un orar cu șase câmpuri, iar un tic lasă aceeași pereche ca o cerere, pe canalul cron.
O singură fereastră de retenție guvernează ambele ieșiri de jurnal, rândurile și fișierele, într-o singură trecere, cablată în procesul care servește. Implicit sunt 30 de zile.

Cereți o prezentare