Invalid_request_signature

[Mgeza]

Tisztelettel kérdezem, hogy mi a helyes menete a request_signature meghatározásakor. Ti. a dokumentációban az szerepel, hogy a kész xml file-nak meghatározom az SHA3-512 értékét, majd az xml-t zip-pelem és ezt a méretének a függvényében feldarabolom, ha kell.
Ebből számomra az következik, hogy a request_signature-be az teljes xml állomány hash-értéke kerül. Viszont, ha így csinálom, akkor minden esetbeb invalid_request_signature üzenet jött vissza.
Ha viszont a zip-elt állományra készítettem el a hash-elést, akkor egy nagyon szép 200-s OK üzenet jött a servertől. Ennek így kell működnie, vagy valamit teljesen félreértek.

Tisztelettel
mgeza

[susanahu2-pzsu]

Valahol azt olvastam (annyifelé vannak az információmorzsák, hogy már meg nem mondom, hol találtam), hogy az éppen csatolt octet-stream tartalmát kell hash-elni. Ami passzol a tapasztalatodhoz.
Mindazonáltal természetesen hasznos lenne, ha a március végére ígért teljes körű leírás is megjelenne végre valahol.

[Mgeza]

Köszönöm válaszodat. A bosszantó, hogy a git-hubon találtam olyan - feltételezem navos - választ, ahol kifejezetten az uncompressed xml tartalomról beszél. Egyszerúen nem értem. 3 napom ment rá, amíg egy bolond ötlettől vezérelve ezt kipróbáltam Mégegyszer, köszönöm. Tisztelettel Michaletzky Géza NEXT Software Kft.

…

________________________________ Feladó: susanahu2-pzsu ***@***.***> Elküldve: 2026. április 14., kedd 12:18 Címzett: nav-gov-hu/eVAT ***@***.***> Másolatot kap: Michaletzky Géza (NEXT Software Kft.) ***@***.***>; Author ***@***.***> Tárgy: Re: [nav-gov-hu/eVAT] Invalid_request_signature (Discussion #204) Valahol azt olvastam (annyifelé vannak az információmorzsák, hogy már meg nem mondom, hol találtam), hogy az éppen csatolt octet-stream tartalmát kell hash-elni. Ami passzol a tapasztalatodhoz. Mindazonáltal természetesen hasznos lenne, ha a március végére ígért teljes körű leírás is megjelenne végre valahol. — Reply to this email directly, view it on GitHub<#204 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ANSQG2VVCN32E6EX5MTG3PT4VYF7ZAVCNFSM6AAAAACXXMJGDGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNJVGUZTGNQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[NTCA-JA]

Kedves Mgeza!
Röviden: a requestSignature nem az XML (sem a ZIP/GZIP) önálló hash-e, hanem egy aláírás, amit a NAV szerver is újra tud számolni a kérés metaadataiból.
Ezért kap INVALID_REQUEST_SIGNATURE hibát akkor, ha a requestSignature mezőbe “csak” a teljes XML SHA3 512 értékét teszi.

1. Mi a requestSignature helyes képlete?
   A NAV leírás szerint a requestSignature alapja a következő mezők összefűzése, majd erre SHA3 512, végül nagybetűsítés:
   • requestId
   • timestamp UTC-ben, yyyyMMddHHmmss formátumban
   • signingKey (aláírókulcs literál értéke)

Pszeudókód:
Plain Text
sig_base = requestId

• formatUTC(timestamp, "yyyyMMddHHmmss")
• signingKey
  requestSignature = UPPERCASE( SHA3_512( UTF8(sig_base) ) )

2. Mikor kell “pluszban” fájl/chunk hash-t is beleszámítani?
   Azoknál a végpontoknál, ahol multipart/form-data kérésben bináris fájl is megy (application/octet-stream), a gyakorlat és a NAV példák alapján a requestSignature alapjához hozzá kell fűzni a csatolt bináris tartalom hash-ét (azaz az éppen feltöltött octet-stream SHA3 512 értékét).
   Ezt támasztja alá az is, hogy Önöknél akkor lett 200 OK, amikor a hash-t a ténylegesen csatolt (tömörített/chunkolt) állományra készítették, nem pedig a nyers XML-re.
   Pszeudókód (fájlfeltöltéses/multipart hívás):
   Plain Text
   file_hash = SHA3_512( raw_bytes_of_attached_octet_stream )

sig_base = requestId

• formatUTC(timestamp, "yyyyMMddHHmmss")
• signingKey
• file_hash

requestSignature = UPPERCASE( SHA3_512( UTF8(sig_base) ) )
Fontos: ilyenkor a “file_hash” a csatolt bináris tartalom bájtjaira számolt hash (pl. a feltöltött gzip/chunk fájl raw bytejai), nem egy szövegesen újra-encode-olt változat.

3. Miért félrevezető a “kész XML hash → zip → darabol” leírás?
   A dokumentációban szereplő “XML hash, majd tömörítés és darabolás” lépések jellemzően a tartalom-azonosító hash-ekre (pl. contentHash, chunk_hash, attachment_hash) vonatkoznak, amelyekkel a szerver a beküldött tartalmat azonosítja és ellenőrzi.
   Ettől külön fogalom a requestSignature, ami az autentikáció része, és a szerver a fenti metaadatokból (és fájlfeltöltésnél a csatolt tartalom hash-éből) számolja újra.
4. Javasolt, “helyes” lépéssor (áttekintés)

1. (Ha releváns) XML tartalom hash (contentHash): a beküldendő XML-re számolt SHA3 512 (a specifikáció szerinti normalizálással).
2. Tömörítés + darabolás: a feltöltendő bináris (gzip/zip) létrehozása és szükség esetén chunk-olása.
3. Chunk hash-ek: minden feltöltött chunk bináris tartalmára SHA3 512 (ez megy chunk_hash/contentHash mezőbe).
4. requestSignature számítása:
   o nem multipart hívásnál: requestId + timestamp + signingKey
   o multipart (octet-streamet csatoló) hívásnál: requestId + timestamp + signingKey + (csatolt bináris tartalom hash-e)

5. Válasz a konkrét kérdésre
   Igen: az működik helyesen, hogy fájlfeltöltés (multipart + octet-stream) esetén a rendszer akkor fogadja el a kérést, ha a requestSignature számításába az éppen csatolt bináris tartalom hash-e is be van vonva.
   A teljes XML hash-e tipikusan nem a requestSignature “helyére” való, hanem a kérésben külön mezőként (contentHash jelleggel) szerepel, a szerver oldali tartalom-ellenőrzéshez.