Sziasztok
A teszt rendszer ma egész nap elég bizonytalan, hol működik hol nem. Connection reset jön különböző helyeken: tokenExchange, queryTransactionStatus
utolsĂłk pl.:
2020-11-23 13:39:41.896 [https-jsse-nio-8443-exec-5] ERROR java.net.SocketException: Connection reset
2020-11-23 13:52:52.764 [https-jsse-nio-8443-exec-3] ERROR java.net.SocketException: Connection reset
Köszi a jelzést, nézik az illetékesek.
Ăśdv
Ráolvasással?
Kb. mikor lesz újból elérhető?
Nekem továbbra sem megy.
Tegnap 9:52 Ăłta tapasztalom a problĂ©mát. Az onlineszamla-test.nav.gov.hu -n nem találtam Ă©rtesĂtĂ©st, hogy ĂĽzemszĂĽnet lenne.
Sziasztok!
Mi is látjuk a hibákat. Dolgozunk rajta, hogy minél hamarabb minden hiba elháruljon. Addig is a türelmeteket kérjük! Amint van előre lépés szólunk. Köszi
Érdemes lenne kitenni Ă©rtesĂtĂ©st a webre, mert tegnap több Ăłrán át kerestem, hogy mit rontottam el - feleselegesen.
Én is kerestem egész délután a nagy semmit, mi lehet a bibi... Hol jó volt amit felküldtem, hol nem...
Valóban jó lenne kitenni a teszt oldalra, hogy bizonytalan a teszt-szerver, próbálkozzatok később.
Én egy XML választ kaptam már TechnicalFault root node-dal.
Erre az ĂĽzenetre gondolsz? RESTEASY003210: Could not find resource for full path: [protocol://host]/testAliveinvoiceService/v3/tokenExchange
Nem tűnik üzemszerű működésnek, főleg nem a fejléc...
Ăśdv!
Ezek szerint még nem működik... OPERATION_FAILED Feldolgozás sikertelen! üzenetet kapok TokenExchangere.
Mikor lesz működőképes?
Kedves @hosszuful
Sok üzenet érkezik be, és valóban van ami elhasal, kollégák dolgoznak rajta. Nem tudjuk még mikor lesz jó. Igyekszünk. Köszönjük a megértést és a türelmet.
@renced42
Köszi... várok... ha működik majd Ărd meg lĂ©gyszi... Köszi.
Kedves @NTCA-supporter !
Érdeklődnék, hogy mikorra várható a megoldás?
Mert a 3.0-s fejlesztéshez is jó lenne, ha lehetne tesztelni a NAV feltöltést.
Előre is köszönöm a választ!
Egy kicsit bővebb választ szeretnénk. Nekünk is dolgozni kellene. Köszönöm
Sziasztok! Azt szeretném megkérdezni, hogy a 2.0-ás tokenExchange sem jó nálatok, vagy csak a 3.0 ? Mert nálam a 2.0-ás is 500-as hibával és OPERATION_FAILED üzenettel jön.
Nekem ma már ment be 3.0-s számla, szóval ma 90%-ban működött, az egyik manageInvoice-nál volt csak egy kis elakadás, de 2. próbára már az is bement.
Sziasztok! Azt szeretném megkérdezni, hogy a 2.0-ás tokenExchange sem jó nálatok, vagy csak a 3.0 ? Mert nálam a 2.0-ás is 500-as hibával és OPERATION_FAILED üzenettel jön.
Nekem ment a 2.0... a 3.0 mondott OPERATION_FAILED-et.
Most már megy a tokenkérés.
Működik. A 3.0-t prĂłbáltam. Belföldi, közössĂ©gen belĂĽli, közössĂ©gen kĂvĂĽli, magánszemĂ©ly, Normál, Ă©rvĂ©nytelenĂtĹ‘, helyesbĂtĹ‘ okirat stb.. JĂł.
Fentebb @NTCA-supporter Ărta hogy javĂtanak valamit. Itt azĂłta nem jeleztĂ©k mĂ©g hogy ĂşjbĂłl ĂĽzemkĂ©pes lenne a rendszer. Ami elbizonytalanĂt, hogy a "HĂrekbe" viszont kikerĂĽlt hogy csak tegnap volt gond. Tehát szándĂ©k szerint már megy? Mert nekem sajnos továbbra sem. Az Online Invoice Test Tool-al is megprĂłbáltam, azzal sem sikerĂĽlt tokent kĂ©rni.
Ne a hĂreket nĂ©zd! Ma sem működött. Most viszont működik a 3.0
Sziasztok!
Tájkoztatást azĂ©rt nem adtunk, mert mĂ©g 100%-osan nem tudjuk állĂtani, hogy minden tökĂ©letes.
Most úgy látjuk működik az alkalmazás, folyamatos a számlafeldolgozás.
Nekem több teszt után is stabilan működött a tokenkérés, v2 és v3 esetben is.
Garantált jĂł működĂ©s akkor lesz, ha a hĂrt is frissĂtjĂĽk Ă©s itt is jelzek. Mivel jĂł ideje nem látok hibát, Ăgy lehet prĂłbálgatni a bekĂĽldĂ©st, Ă©s az esetleges hibára futott requestId-t ide megĂrni, igyekszem reagálni rájuk, (persze ha az egyedi hiba).
Köszi a türelmet!
Ezt az imént próbáltam:
<common:requestId>TEXCH_000000308077</common:requestId>
<common:timestamp>2020-11-25T12:50:24.592Z</common:timestamp>
De próbáltam az imént egy Online Invoice Test Tool-al is:
<common:requestId>RIDHx9Pw4Rn8Tx3</common:requestId>
<common:timestamp>2020-11-25T13:48:56.568Z</common:timestamp>
A log tartalma:
2020.11.25 14:48:56:5837 Waiting for : 1000 ms to post XML
2020.11.25 14:48:57:6026 tokenExchange Request start
2020.11.25 14:48:57:6182 IP address:169.254.80.45
2020.11.25 14:48:57:6182 Target URL: https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3/tokenExchange
2020.11.25 14:48:59:4549 Error occured:Érvénytelen URI: Az állomásnév nem elemezhető.
Sziasztok!
Most próbáltam ki a 3.0-t és hiba nélkül felment.
Sziasztok!
Tegnap (14:50 után ) és ma is a teszfelületen számlabeküldésre csak ezt kapom vissza:
'''
Tr.code 1-2-3 kisérletre megjön.
requestId: RID202011270945165, bekĂĽldve ma 9:53-kor
Megnéznétek? Köszi
Sziasztok!
Tegnap (14:50 után ) és ma is a teszfelületen számlabeküldésre csak ezt kapom vissza:
'''ERROROPERATION_FAILEDRESTEASY003210: Could not find resource for full path: [protocol://host]/external/public/invoiceService/invoice/interface/invoiceRequest
Tr.code 1-2-3 kisérletre megjön.
requestId: RID202011270945165, bekĂĽldve ma 9:53-kor
Megnéznétek? Köszi
Kedves @clapygeza ellenőrizd az URL-t, hogy mire küldöd a kérést.
Az URL vége simán manageInvoice, de úgy néz ki, hogy hozzáteszel még egy Request toldalékot, ami nem létezik.
Megoldódott, köszönöm
Kedves @NTCA-supporter!
Kérlek nézd meg TEXCH_000000309030 request-et miért nem sikeres (timestamp: 2020-11-27T13:38:36.294Z).
Az URL: https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3/tokenExchange
Köszönöm
Kedves @NTCA-supporter!
Kérlek nézd meg
TEXCH_000000309030request-et miért nem sikeres (timestamp: 2020-11-27T13:38:36.294Z).
Az URL: https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3/tokenExchangeKöszönöm
Megoldódott, köszönöm
Kedves @NTCA-supporter!
LehetsĂ©ges, hogy 1-2 hete törtĂ©nt a teszt szerveren vmi olyan beállĂtás, konfiguráciĂł, ami miatt az stunnel-en keresztĂĽl kĂĽldött request-ek, bármelyik vĂ©gponttal is prĂłbálom, kivĂ©tel nĂ©lkĂĽl 404-es hibát adnak? Az URL-ek biztosan jĂłk, 2 hete mĂ©g vĂgan ment a tesztszerverre valĂł bekĂĽldĂ©s v3 alatt is. Jelenleg v2-vel Ă©s v3-mal is ugyanaz a helyzet (404).
Az éles szerverrel továbbra sincs gond, megy minden, mint eddig. Mind az élesen, mind a gyakorlón ugyanaz a megoldás működik a kezdetek óta, természetesen a megfelelő URL-ekkel.
Előre is köszönöm a választ.
ĂĽdv
Kedves @lacih
A 404 az 404, kérlek ellenőrizd arról a gépről amiről küldesz adatot, böngészőből vagy wget-ből, hogy eléred-e a https://api-test.onlineszamla.nav.gov.hu/ oldalt itt egy OK-t kell kapj vissza. Ha nem éred el akkor hálózati problémád van.
Kedves @lacih
A 404 az 404, kérlek ellenőrizd arról a gépről amiről küldesz adatot, böngészőből vagy wget-ből, hogy eléred-e a https://api-test.onlineszamla.nav.gov.hu/ oldalt itt egy OK-t kell kapj vissza. Ha nem éred el akkor hálózati problémád van.
Kedves @renced42 !
Igen, elérem természetesen, OK jön vissza.
A request-eknĂ©l ahogy Ărtam egy stunnel van közbeiktatva, csak arra tudok gyanakodni, hogy akörĂĽl nem stimmel valami a szerver oldalon. A topik tĂ©máját jelentĹ‘ ĂĽzemzavar utántĂłl van ez a 404-es jelensĂ©g. Az a frusztrálĂł, hogy elĹ‘tte már Ă©vek Ăłta ment mind a teszt, mind az Ă©les bekĂĽldĂ©s. Az Ă©les most is megy gond nĂ©lkĂĽl, ugyanezzel a struktĂşrával.
ĂĽdv
A topik témáját jelentő üzemzavar utántól van ez a 404-es jelenség.
LĂ©gyszĂves kĂĽldj IP cĂmet meg idĹ‘pontot esetleg RequestID-t, bár ha 404-et kapsz vissza nyĂlván el sem tudod kĂĽldeni.
az stunelből kellene valami verbose logot kicsikarni, hogy hol akad el a folymat.
LĂ©gyszĂves kĂĽldj IP cĂmet meg idĹ‘pontot esetleg RequestID-t, bár ha 404-et kapsz vissza nyĂlván el sem tudod kĂĽldeni.
az stunelből kellene valami verbose logot kicsikarni, hogy hol akad el a folymat.
stunnel.conf vonatkozĂł tartalom:
[nav-https-test]
client = yes
accept = 127.0.0.1:8008
connect = api-test.onlineszamla.nav.gov.hu:443
CAfile = ca-certs.pem
OCSPaia = yes
friss próbálkozás egy queryTaxpayer request-tel, az stunnel log tartalma:
2020.12.02 11:06:25 LOG5[main]: stunnel 5.57 on x64-pc-mingw32-gnu platform
2020.12.02 11:06:25 LOG5[main]: Compiled/running with OpenSSL 1.1.1h 22 Sep 2020
2020.12.02 11:06:25 LOG5[main]: Threading:WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI
2020.12.02 11:06:25 LOG5[main]: Reading configuration from file stunnel.conf
2020.12.02 11:06:25 LOG5[main]: UTF-8 byte order mark detected
2020.12.02 11:06:25 LOG4[main]: Service [nav-https-test] needs authentication to prevent MITM attacks
2020.12.02 11:06:25 LOG5[main]: Configuration successful
2020.12.02 11:06:52 LOG5[0]: Service [nav-https-test] accepted connection from 127.0.0.1:64071
2020.12.02 11:06:52 LOG5[0]: s_connect: connected 84.206.52.71:443
2020.12.02 11:06:52 LOG5[0]: Service [nav-https-test] connected remote server from 192.168.168.76:64072
2020.12.02 11:06:52 LOG5[0]: Connection closed: 1373 byte(s) sent to TLS, 326 byte(s) sent to socket
Kedves @lacih mindenkĂ©ppen kellene a NAT-olt cĂmetek, mert biztosan nem 192.168.168.76-al jöttök hozzánk.
Még pár dolog TLS és Http protocol verzió ok?, A TLS-nek 1.2-nek kellene lennie.
Ha jó látom ez egy Windowson futtatot cygwin-es környezet, de lehet, hogy tévedek. Mire kell az Stunnel? Ezen keresztül látsz ki a hálózatodból?
Egy Wget-es parancsot ki tudsz adni ezen a csatornán?
Egy Wget-es parancsot ki tudsz adni ezen a csatornán?
Szia!
NAT-olt IP: 78.131.11.206
TLS 1.2
stunnelt azĂ©rt használunk, mert a szerver, ami kĂĽldi a request-et nem tud csak http-t, át kell fordĂtani https-re
wget és az stunnel debug logjait (teszt, éles) csatoltam, időpontok benne vannak:
wget_log_eles.txt
wget_log_teszt.txt
stunnel_log_teszt.txt
stunnel_log_eles.txt
stunnel láthatóan felveszi a kapcsolatot mindkét esetben, de nem kap választ a tesztnél
Kedves @lacih mindenkĂ©ppen kellene a NAT-olt cĂmetek, mert biztosan nem 192.168.168.76-al jöttök hozzánk.
Még pár dolog TLS és Http protocol verzió ok?, A TLS-nek 1.2-nek kellene lennie.
Ha jó látom ez egy Windowson futtatot cygwin-es környezet, de lehet, hogy tévedek. Mire kell az Stunnel? Ezen keresztül látsz ki a hálózatodból?
Egy Wget-es parancsot ki tudsz adni ezen a csatornán?
Ăśdv!
Sikerült esetleg valamire jutni ezzel a linkelt log-ok és adatok alapján?
Kedves @lacih kérlek próbálj egy újat.
Kedves @lacih kérlek próbálj egy újat.
Szia!
Linkelem a két friss mai próbálkozás stunnel-es logját.
Ami látszik belőlük, hogy éles rendszerre kiadott request esetén a logban lévő
2020.12.08 11:29:18 LOG7[0]: Compression: null, expansion: null
sor után egy fél perc múlva a socket és minden egyéb lezáródik:
2020.12.08 11:29:48 LOG6[0]: SSL_read: Socket is closed
Ezzel szemben a tesztre kiadott request esetén szintén eljutunk a fenti sorig:
2020.12.08 11:36:32 LOG7[0]: Compression: null, expansion: null
majd ezután se kép, se hang, semmilyen újabb történés. Mintha nem jönne válasz a teszt szervertől többet.
Ez a request oldalán 404-es hibaként jelenik meg.
Kedves @lacih
Látjuk a próbálkozásokat, de valami nem stimmel a küldéssel
KĂ©rlek kĂĽldj egy rendes POST-os kĂ©rĂ©st Ă©s kĂĽldmeg a pontos URL-t hogy mit hĂvsz.
Vagy egy printscreent, hogy lássuk :)
Azt nem teljesen értettem, hogy a gép amiről küldötök nem tud https-t.
Kedves @lacih
Látjuk a próbálkozásokat, de valami nem stimmel a küldéssel
KĂ©rlek kĂĽldj egy rendes POST-os kĂ©rĂ©st Ă©s kĂĽldmeg a pontos URL-t hogy mit hĂvsz.
Vagy egy printscreent, hogy lássuk :)Azt nem teljesen értettem, hogy a gép amiről küldötök nem tud https-t.
Kedves @renced42!
Az ERP rendszer szervere, amin tesztelek, http request-et tud kiadni, azért kell az stunnel, hogy azon keresztül https request mehessen a NAV szerverre.
Most indĂtottam egy queryTaxpayer operáciĂłt, stunnel log linkelve.
URL: 127.0.0.1:8008/invoiceService/v2/queryTaxpayer
Az stunnel config vonatkozó részlete:
[nav-https-test]
client = yes
accept = 127.0.0.1:8008
;connect = api.onlineszamla.nav.gov.hu:443
connect = api-test.onlineszamla.nav.gov.hu:443
CAfile = ca-certs.pem
OCSPaia = yes
_Azaz:_
accept = 127.0.0.1:8008
A localhoston (ezen megy az ERP rendszer szervere, ami a NAV-ot megszĂłlĂtja) a 8008-as porton Ă©rkezĹ‘ request-et https-re fordĂtva kĂĽldje tovább
connect = api-test.onlineszamla.nav.gov.hu:443
a NAV teszt szerverére
Ez az egész konstrukció 2018 óta megy partnereknél is mind az éles, mind a teszt szerveren. Az élesen most sincs vele semmi baj, a teszt szerveren a novemberi karbantartás óta van a jelenség (404).
Kedves @lacih
Még egy próbát kérlek
Kedves @lacih
Kicsit nézegettem az stunel doksikat.
Kérlek a konfighoz add hozzá ezt a sort és próbáld meg
[nav-https-test]
sni = api-test.onlineszamla.nav.gov.hu
Kedves @lacih
Kicsit nézegettem az stunel doksikat.
Kérlek a konfighoz add hozzá ezt a sort és próbáld meg
[nav-https-test]
sni = api-test.onlineszamla.nav.gov.hu
Kedves @renced42!
Kipróbáltam, nincs változás. A linkelt logban is úgy láttam, hogy használ SNI-t.
Kedves @lacih
Na mégegyszer :)
Kedves @lacih
Na mégegyszer :)
No, mi történt? Visszadugtátok a konnektorba? :-)
Kedves @lacih
Persze a srácok szĂłltak, hogy a kávĂ©fĹ‘zĹ‘ volt eddig bedugva, most visszatettĂ©k a teavĂz forralĂłt :)
De félre a tréfával, a probléma az, hogy a host header érték amit küldesz nem jó, hiába van az SNI belőve nálad, mégis 127.0.0.1:8008-at kapunk és ez hibás működés sajnos.
Azért tudtál eddig működni, mert eddig ezt a hibát nem vettük figyelembe az átállás óta viszont már erre is figyelünk.
Ideiglenesen ezt a szabályt most mĂłdosĂtottuk, hogy jĂł legyen a bekĂĽldĂ©sed.
KĂ©rlek, hogy ezen dolgozzatok, mert ezt a vizsgálatot neked most az EDU-n kikapcsoltuk, de az Ă©lesen a decemberi átállásnál vagy azt követĹ‘en nagy valĂłszĂnűsĂ©ggel be lesz kapcsolva.
Köszi a sok tesztet ezzel valĂłszĂnűleg pár emberen most segĂtettĂĽnk általad illetve mi is tudunk egy plusz vizsgálnivalĂłt mondani.
Kedves @lacih
Persze a srácok szĂłltak, hogy a kávĂ©fĹ‘zĹ‘ volt eddig bedugva, most visszatettĂ©k a teavĂz forralĂłt :)
De félre a tréfával, a probléma az, hogy a host header érték amit küldesz nem jó, hiába van az SNI belőve nálad, mégis 127.0.0.1:8008-at kapunk és ez hibás működés sajnos.
Azért tudtál eddig működni, mert eddig ezt a hibát nem vettük figyelembe az átállás óta viszont már erre is figyelünk.
Ideiglenesen ezt a szabályt most mĂłdosĂtottuk, hogy jĂł legyen a bekĂĽldĂ©sed.
KĂ©rlek, hogy ezen dolgozzatok, mert ezt a vizsgálatot neked most az EDU-n kikapcsoltuk, de az Ă©lesen a decemberi átállásnál vagy azt követĹ‘en nagy valĂłszĂnűsĂ©ggel be lesz kapcsolva.
Köszi a sok tesztet ezzel valĂłszĂnűleg pár emberen most segĂtettĂĽnk általad illetve mi is tudunk egy plusz vizsgálnivalĂłt mondani.
Kedves @renced42 !
Mit kell kĂĽldenem, hogy elfogadja a szerveretek?
Mit kell kĂĽldenem, hogy elfogadja a szerveretek?
api-test.onlineszamla.nav.gov.hu a teszten
api.onlineszamla.nav.gov.hu az élesen
api.onlineszamla.nav.gov.hu
Kedves @renced42!
Jelezz majd kérlek a holnapi nap folyamán, ha rá tudtok nézni megint egy konkrét request-re valamikor, amit beküldök.
PrĂłbáltam mĂłdosĂtani a headert, hogy mĂ©g az stunnel elĹ‘tt belekerĂĽljön a host.
api.onlineszamla.nav.gov.hu
Kedves @renced42!
Jelezz majd kérlek a holnapi nap folyamán, ha rá tudtok nézni megint egy konkrét request-re valamikor, amit beküldök.
PrĂłbáltam mĂłdosĂtani a headert, hogy mĂ©g az stunnel elĹ‘tt belekerĂĽljön a host.
Kedves @renced42!
Én készen állok egy esetleges vizsgálatra most.
ĂĽdv
Kedves @lacih
Akkor próbálj meg egyet :)
Kedves @lacih
Akkor próbálj meg egyet :)
Friss prĂłba ment 11:48-kor (queryTaxpayer)
Friss prĂłba ment 11:48-kor (queryTaxpayer)
Szia sajnos nem sikerĂĽlt :(
Friss prĂłba ment 11:48-kor (queryTaxpayer)
Szia sajnos nem sikerĂĽlt :(
El tudnád küldeni az egész struktúrát, amit láttok?
[email protected]
Kedves @lacih
Sajnos nem sok mindent tudok kĂĽldeni.
A lényeg hogy a post header-ben van egy host nevű mező (ez most 127.0.0.1:8008) pl mint a content type oda kell bevarázsolni az aip-test.nav.gov.hu értéket.
content-type: text/xml
host: 127.0.0.1:8008
Friss prĂłba ment 11:48-kor (queryTaxpayer)
Szia sajnos nem sikerĂĽlt :(
12:58-kor ment egy Ăşjabb prĂłba (queryTaxpayer)
Kedves @lacih
Ez szemmel láthatóan jobb lett:
host: api-test.onlineszamla.nav.gov.hu
Kedves @lacih
Ez szemmel láthatóan jobb lett:
host: api-test.onlineszamla.nav.gov.hu
Akkor esetleg kiprĂłbálhatnánk, hogy ideiglenesen visszakapcsoljátok a szigorĂtást Ă©s Ăşgy prĂłbálok kiadni egy request-et, ha nem nagy gebasz.
Kedves @lacih
Visszakapcsoltuk a V2-n, próbáld meg.
Kedves @lacih
Visszakapcsoltuk a V2-n, próbáld meg.
Kedves @renced42!
KiprĂłbáltam, működik a dolog a megszorĂtással is. Hálás köszönet a segĂtsĂ©gĂ©rt Ă©s a kitartĂł tĂĽrelemĂ©rt! :-D
ĂĽdv
Kedves @lacih
Nincs mit, szĂvesen 👍
A megoldást megosztanád velünk ha nem titkos? :)
Kedves @lacih
Nincs mit, szĂvesen 👍
A megoldást megosztanád velünk ha nem titkos? :)
Persze.
A szerverĂĽnkben a HTTP request-et előállĂtĂł metĂłdus az eredeti URL-bĹ‘l határozta meg a host-ot, ezĂ©rt láttátok azt, amit.
Ide kellett egy config lehetőség, hogy azzal megmondjuk, mi a valódi host. Ha ez meg van adva, akkor kicseréli az első lépésben meghatározott host-ot a valódira.
Maga az stunnel és az SNI megadása nem játszott szerepet a problémában.
Kedves @renced42!
Tettem egy próbát a teszten a V3 csatornán is, ott most Internal Server Error (500) üzenet jön. Erről tudsz esetleg valamit?
Kedves @lacih
Igen nem jó a passwordhash crypto a kérésben. Még az SHA2-512-t kell megadni.
Kedves @lacih
Igen nem jó a passwordhash crypto a kérésben. Még az SHA2-512-t kell megadni.
Kedves @renced42!
Oh, értem. Esetleg van hozzávetőleges infó, hogy mikor lépnek életbe a friss sémaváltozások?
Oh, értem. Esetleg van hozzávetőleges infó, hogy mikor lépnek életbe a friss sémaváltozások?
Reményeim szerint a hétvége felé.
Oh, értem. Esetleg van hozzávetőleges infó, hogy mikor lépnek életbe a friss sémaváltozások?
Reményeim szerint a hétvége felé.
Rendben, köszönöm szépen!
ĂĽdv
Sziasztok!
Itt van még kérdés? A séma elérhető teszt környezeten.
Ăśdv
Most helpful comment
Érdemes lenne kitenni Ă©rtesĂtĂ©st a webre, mert tegnap több Ăłrán át kerestem, hogy mit rontottam el - feleselegesen.