fetch - másik domainről (meg úgy egyáltalán... :) )
Valakinek segíteni akartam egy primitív ajax-os problémát megoldani, akkor botlottam a JS fetch funkcióba.
Próbálom megérteni, de nem megy.
A nulladik gond, hogy nodejs interpreterből nem fut. Erre van valami egyszerű (!) workaround, hogy böngészős eszközöket használjak cli alapon?
Az elsődleges gond, hogy a "let resp=fetch("https://example.com/", {method:'GET', mode:'cors'});" következetesen hibára fut az oldal sajátjától eltérő domain miatt.
A másodlagos, hogy számomra borzasztóan idegen a JS szintaxis. Hogyan tudom ebből a Promise nevű ojjektumból kivenni a lekért oldal kódját?
Pythonban mindez nagyon egyszerű, de itt...
■ Próbálom megérteni, de nem megy.
A nulladik gond, hogy nodejs interpreterből nem fut. Erre van valami egyszerű (!) workaround, hogy böngészős eszközöket használjak cli alapon?
Az elsődleges gond, hogy a "let resp=fetch("https://example.com/", {method:'GET', mode:'cors'});" következetesen hibára fut az oldal sajátjától eltérő domain miatt.
A másodlagos, hogy számomra borzasztóan idegen a JS szintaxis. Hogyan tudom ebből a Promise nevű ojjektumból kivenni a lekért oldal kódját?
Pythonban mindez nagyon egyszerű, de itt...
v17.5
Promise-okat legolvashatóbban async/awaittel lehet kezelni.
Persze ha valahol sync kódból kell az async eredménye, akkor jön a hagyomásos callbackes promise kezelés (ahol az egyes callbackek megkapják a vonatkozó visszatérési értéket vagy a dobott kivételt paraméterként):
Meg érdemes elolvasni az MDN fetch() doksiját is, vannak benne hasznos dolgok.
szerk.: Most látom, hogy csak az elsődleges kérdésre nem válaszoltam még. Milyen hibára fut pontosan a cors kérés? Ahonnan fetchelni próbálsz, ott kifejezetten meg kell engedniük fejlécekkel, hogy cross origin el lehessen őket érni.
Köszi!A pythonban
A pythonban mélységesen egyetértek. Sőt... :)
Csak macerás a browseres debug, ezért gondoltam, hogy cli alapon talán egyszerűbb megtalálni a hibákat, amíg csak ismerkedni próbálok a nyelvvel és ennek kapcsán került elő, hogy bizony a node interpreter nem ad mindent ami a browserben van. Létezik valami browser-env npm, most próbálom újra felrakni, mert telihányta a logot deprecated jelzésekkel, épp csak nem tudtam eldönteni, hogy én rontottam el valamit vagy eleve a csomag felejtős.
Sync kód, miután még csak parancssorból indítgatnék ezt-azt, de pont az (volt?) a gondom, hogy a .then() zárójelei közt hogyan férek hozzá a text()-hez, mert minden eddigi próbálkozásom eredménye az volt, hogy "undefined" vagy az, hogy "non existent nemtudommi".
Az MDN-t olvasgattam egyébként, csak nincsenek meg igazán a JS alapok, ami nem kis szívással jár ilyenkor. :D
(pl. még most sem értem teljesen a ... .then( a => ...) működését, mert sehogy sem akarja megtalálni a Response object metódusait, változóit stb. Sajnos töröltem a próbálkozásom nyomait, szóval majd nekiugrok újra, akkor tudok hibás kódot mutatni...
szerk: :) - oops... akkor ezt véletlenül jól értettem, hogy nem a kliens oldalon akad el a kérés, hanem a szerver utasítja el. Mondjuk sok értelmét nem látom, ha jól értem a célját, miszerint illetéktelen kódot injektálva egy oldalba ne lehessen megfertőzni a látogatók gépét. Hiszen ebben az esetben pont a rosszindulatú szerverre van bízva, hogy engedi-e a kérést vagy sem. (vagy mégis félreértek valamit?)
Sync
then()
hívás is egy promise-t ad vissza, ami a callback visszatérési értékével fog teljesülni. És a response.text() is async/promise, azért kell a második then.Ha a saját oldaladba kerül rosszindulatú kód, az már XSS, az ellen a cors fejlécek valóban nem fognak védeni. Ez akkor jó, ha valaki be van jelentkezve a te oldaladon, és ellátogat a rosszindulató oldalra, akkor az ne tudja lekérni a
teoldalad.com/privat-adatok
oldalt, vagy hasonlót. Vagyis ez ugye alapból tiltva van cross-origin kérésként, de a fejlécekkel lazíthatsz ezen a szigoron, ha szeretnéd, hogy egy másik, megbízható origin mégis le tudjon kérni ilyen adatokat, vagy esetleg egy olyan API-t szolgáltatsz, aminél nem baj, ha random oldalakról is meg tudják hívni (stb, stb, elég mély téma, aminek nekem is mindig utána kell néznem, ha hozzá kell nyúlni :) ).És akkor ott van még a CSRF is, amire figyelni kell.
No igen. Itt van az, hogy már
Most futottam neki negyedszer a CORS leírásának, most végre kezdem felfogni, hogy miről szól.
promise?
Mert a csekély angoltudásom és a szótár szerint is az ígéret szó és szinonimái. De az ide nem illik.
pedig de
Nekem is ez jutott eszembe a
Tisztulnak a dolgok
Sokadik nekifutásra és a fentit válaszoddal összerakva sikerült felfognom végre. A fentiek szerint nem én vagyok az egyetlen, aki "kissé" félreértette az egész történetet.
Amit viszont sohasem fogok megérteni: ha valaki olyat mer kérdezni a so-n, ami... hát nem egy triviális dolog, rögtön jönnek a hiénák mínuszolni.
Egyébként nem ártana megjegyeznem, hogy
1. proxy
2. ad- és egyéb block addonok
3. noscript
elég rendesen keresztbe tudnak tenni a tesztelgetésnek. :D
Kezd működni a dolog. A
Folyt. köv. :)
Cors
A szerveroldalon kell elintézni, hogy a kérelmező oldal kéréseit fogadja.