[Megoldva] Webes form mezőinek az azonosítása

Internet: PHP, CGI, stb.

Adott egy belső céges oldal, rajta egy webform, Smartsheet-ben lett elkészítve. Ezt nem akarom kézzel töltögetni, mert sok egyforma adatot kell bevinni, ezért automatizálnám. Viszont nem találok rajta fogást. Hiába néztem a form kódját, a HTML kód semmit nem mond, csak egy js-re hivatkozik, azt megnyitva meg egy sorba obfuszkált szar kód, nem látom át, nem értem mit csinál. A kódot csak holnap tudom csatolni, ma elfelejtettem kimenteni. Próbáltam a böngésző inspection funkcióját, de az se írja. Nekem csak a mezők neve/id-je kéne. Hogy lehetne megnézni?

Egyelőre AutoHotKey scripttel automatizálom a bevitelt, működik, de elég amatőr és lassúcska, jobb lenne, ha inkább közvetlenül ?név1=érték&név2=érték formában küldeném el a weben. Gondolom, hogy a form nem GET-et használ, mivel nem látom küldéskor, hogy elküldene URL-t, de elvileg az URL átmókolása működhet POST-os feldolgozás esetén is.

Megoldás: a Smartsheet oldalán lévő leírásban foglaltak működtek. Mégis csak megy a form?label1=value&label2=blahblah módszerrel. Igaz nem küldi el automatán, de előre kitölti így a mezőket a böngésző, AutoHotKey szkripttel meg én nyomok rá az elküldés gombra. Sajnos azt a Smartsheet szándékosan nem tudja, hogy az elküldés is automatizált legyen, csak az előkitöltést támogatják.

  • 1417 megtekintés

( locsemege v | 2025. 03. 11., k – 22:24 )

Nincs az inputnak id-je? Persze, ha js, akkor gondolom, az generálhat id-t, akármit. Szerintem a HTML Document Object Modelből JS-sel hozzá tudsz férni. Már, ha megértettem, de nem biztos. Ha automatizálsz, mi van a böngésző helyén? Egy wget vagy curl?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azt még nem tudom, hogy curl vagy wget, valami ilyesmire gondoltam. Pont ez az, hogy nincs a HTML és JS kódban klasszik input tag-es mező, ami írná a name, id adatokat.

Ehhez a DOM-hoz JS-tel hogy férek hozzá, valami példát tudnál írni rá vagy linkelni?

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Csináltam műszerhez részleges webes felületet, de ott ugye én írom a szerver oldali php kódot is, és a kliens oldali html, css, js kódot is. Hirtelen ebben gondolkodtam, de itt a js-t nem te írod, azt a szervertől kapod. Tehát, ha jól értem, egy böngészőt akarsz emulálni, de ahhoz magadnál kell futtatni a szervertől kapott js-t is, meg ez egész DOM-ot emulálni kellene, gondolom, ellenkező esetben szerintem elhasal a szerver által küldött, kliensen futtatandó js. Vigasztalj meg, hogy nem egy fél délután akarsz megírni valamilyen scriptnyelven egy GUI nélküli böngészőt! :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( x-daemon | 2025. 03. 11., k – 22:25 )

irj be teszt adatokat, es nezd meg a firefox webtools (f12) halozati fulen, hogy mit kuldott. ugyanabban a formaban te is el tudod kuldeni az adatot.

neked aztan fura humorod van...

Ú, kösz, ez eszembe se jutott, hogy nem csak az inspector-ral, de a network részen is lehetne detektálni, hogy mit küld el a form. Kipróbálom holnap.

Szerk.: sajnos nem jött össze, a network részen se hozott a böngésző használhatót.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( locsemege v | 2025. 03. 11., k – 22:51 )

Az elinks valahogy nem scriptelhető? Mindenesetre külső editor megadható neki az EDITOR környezeti változóval, ami ígéretes.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kösz szépen a tippeket, az Auto Fill Form plugineken kívül kipróbálom ezt a Selenium-ot, Robot framework-öt.

Szerk.: közben nyálazom a Smartsheet doksit, és az azt írja, hogy ha nincs bejelentkezés kényszerítve a formon (már pedig az esetemben nincs), akkor mégis csak működik az formURL?field1=value&field2=blahblah módszer. Csak ki kéne derítenem a címkéket, ezek alapértelmezetten a Smartsheet adott táblázatának az oszlopnevei, majd meglátjuk. Még itthonról írok, majd csak a melóban tudom kipróbálni. Mondjuk hátránya ennek a módszernek, hogy ez csak kitölti a formot, de nem küldi el feldolgozásra a szerverre, nekem kell a beküldés gombot nyomni, de ezt ki fogom tudni hekkelni AutoHotKey-vel. Persze szerettem volna elegánsabban megoldani, curl vagy wget segítségével, hogy csak előre preparált URL-eket küldözgetek, minimális közbeiktatott várakozási időkkel, az platformfüggetlen is lett volna, meg gyorsabb.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Hát, akkor ezt érdemes lenne a webet annó csináló tudományos munkatársakkal megbeszélni, hogy az egyik kezükkel miért írták le, hogy a GET idempotens, a másikkal meg, hogy a form default actionja a GET, ami meg url encodeolva felküldi az adatokat.

De nem kell, mert ez valójában egy közleletű féreértés, az idempotencia nem azt jelenti, hogy nem okozhat változást, hanem azt, hogy:

 

A request method is considered "idempotent" if the intended effect on
   the server of multiple identical requests with that method is the
   same as the effect for a single such request.  Of the request methods
   defined by this specification, PUT, DELETE, and safe request methods
   are idempotent.

   Like the definition of safe, the idempotent property only applies to
   what has been requested by the user; a server is free to log each
   request separately, retain a revision control history, or implement
   other non-idempotent side effects for each idempotent request.

   Idempotent methods are distinguished because the request can be
   repeated automatically if a communication failure occurs before the
   client is able to read the server's response.  For example, if a
   client sends a PUT request and the underlying connection is closed
   before any response is received, then the client can establish a new
   connection and retry the idempotent request.  It knows that repeating
   the request will have the same intended effect, even if the original
   request succeeded, though the response might differ.

 

(Korábban kevesebb szóval az volt leírva, hogy ugyanannak a requestnek sokszor ugyanaz lesz a sideeffektje). Annyiról szól, hogy ha azt hiszed, hogy baj van, akkor elküldheted újra. Tehát egy ugyanolyan GET nem szabadna, hogy duplikátumot okozzon véletlen (ez egyébként nem szokott sikerülni)

az egyik kezükkel miért írták le, hogy a GET idempotens, a másikkal meg, hogy a form default actionja a GET, ami meg url encodeolva felküldi az adatokat

Pl. search form vagy egyéb adatbázislekérdező műveletek? Gondolom, nem véltelenül hívják az URL-ben átadott értékeket sem "query paramétereknek".

Amúgy szerintem ezt így nem tudták leírni egyik és másik kezükkel, mert a GET a HTTP része, a FORM meg HTML része. :)

De nem kell, mert ez valójában egy közleletű féreértés, az idempotencia nem azt jelenti, hogy nem okozhat változást, hanem azt, hogy

Az idempotenciában igazad van, csak itt pont nem az az érdekes tulajdonság, ezt zeller kolléga rosszul írta (láttam hasonlóan rossz megfogalmazást HTML RFC-ben is), hanem a "safe". Idézet ugyanonnan:

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource.

[...]

Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.

Erről lemaradtam :)

Pl. search form vagy egyéb adatbázislekérdező műveletek? Gondolom, nem véltelenül hívják az URL-ben átadott értékeket sem "query paramétereknek".

Szóval nyilván ezért :)

Az idempotenciában igazad van, csak itt pont nem az az érdekes tulajdonság, ezt zeller kolléga rosszul írta (láttam hasonlóan rossz megfogalmazást HTML RFC-ben is), hanem a "safe". Idézet ugyanonnan:

Jep, valóban a safeség a fontos, csak hát pedáns zeller kolléga nem arra hivatkozott :)

Igen, GET-tel, de nem kerül feldolgozásra az adat, csak mező-előkitöltésre van használva, beküldened neked kell kézzel, JS-es gombbal. Tehát amolyan GET is, meg nem is. Elég kókányolt egy rendszer ez a Smartsheet, én is csak pár hete dolgozok vele, előtte nem is hallottam róla. Ez valami webes táblázatkezelő, de nem tud adatbázist, viszont ilyen form-gyártást, Gantt-nézetet tud kiegészítőleg.

Persze, én is szeretném, ha valami normálisabbal dolgoznának, mondjuk egy FOSS adatbázissal, az nem érdekel, hogy MariaDB, MySQL, Postgress, SQLite, csak értsen valami dokumentált SQL parancskészletet, és azzal nyomathatnám tömeges INSERT-tel, nem kéne URL-ekkel meg formokkal szórakozni, mint az őskorban.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Igen, pont ez az. Az adatokat bevihetném simán táblázatszerűen, tömeges beillesztésként Smartsheet-ben, de a főnök lezárt egyes oszlopokat, hogy közvetlenül nem lehet a táblázathoz semmit adni, csak a formon keresztül, ezt szerintem azért csinálta, hogy validálja a bekerülő adatokat.

Sajnos a Smartsheet API-t meg az új form létrehozását nem használhatom, mert nincs meg hozzá az admin jogom a Smartsheet felületén.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

vannak form auto fill böngésző pluginek. Régen használtam már valamire őket, és így konkrét névre nem emlékszem, h melyiket. De kb az volt, h egy kitöltöttem az inputmezőket és akkor azt el lehetett menteni, és akkor mindig amikor bejött az url akkor az inputokat automatikusan kitöltötte a mentett adattal. Keress rá! 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

( kroozo v | 2025. 03. 11., k – 23:09 )

Próbáltam a böngésző inspection funkcióját, de az se írja

Pedig valamit ott elnéztél. Az lehet, hogy a konkrét oldal forrásában kb csak egy scriptként behivatkozott JS van (az meg nyilván minified, embernek olvashatatlan), de ha megjelenik a browserban, akkor bizony ott html lesz*, a DOMban látszani kell azoknak a mezőknek. Jobb click valami elemen, inspect, és ott lesz az.

?név1=érték&név2=érték

Az más kérdés, hogy szinte biztosan nem egy simán formként felpostolt cucc lesz jó eséllyel. A legtöbb ilyen keretrendszer valami AJAX hívást csinál hátul jsből, nem a főoldallal postol általában, szóval tényleg a legjobb azt nézni, hogy mit küld hátul a netwörkön.

Vagy hát, ha erről a smarsheetről van szó, akkor annak van apija, leírással: https://smartsheet.redoc.ly/#section/Introduction , meg van vagy 5 féle sdk hozzá.

* Jó, persze, lehetne valami webassembly, ami csak egy canvasra rajzolgat, de kétlem :)

Nem, nem néztem be. De rájöttem az okára, ez nem form. Úgy néz ki, mintha form lenne, de ez egy teljesen JS-es mókolás, ide feltöltöttem 7-zip-pel csomagolva, mivel Windowson készült. A HTML-t nem mentettem el, mert abban tényleg nincs semmi, szokásos header, body, meg erre a JS-re hivatkozás, semmilyen értelmes tartalmi tag nincs benne, se input, se semmi más.

A Smartsheet terén nem a hozzáértésemmel van baj, mert elboldogulnék vele, hanem hogy nincs az adott táblázatokhoz admin jogom, így se az API-t nem tudom használni, se új formot létrehozni, se semmit. Admin joga csak a főnöknek van.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ja, én is így vagyok vele, de mivel új vagyok, nem pofázhatok. Egyébként én értem, validálni akarja a bekerülő adatokat, és csak ezen a formon keresztül tudja megoldani. Gondolom korábban a sok normi balfék érvénytelen adatokat vitt be állandóan.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Kösz, ez is nagy segítség volt. Így normális formában átnézve a JS kódot, ez egy nagyon általános generic kód, nincs benne az adott form-ra vonatkozó specialitás. De legalább ezt a lehetőséget is szépen kizártuk. Azért halad előre a projekt, még ha lassan, mm-enként is.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem, nem néztem be

őő, hát két lehetőség van:

  • ez a smarsheets a kb egyetlen olyan webes alkalmazás, ami html dom nélkül rajzol beviteli mezőket egy weboldalra, és aztán oldalt galambpostával küldi el az adatokat a backendnek
  • benézted

:) Szóval de. Vagyis hát, nem érted, hogy mit nézel. Persze, hogy abban a jsben semmi form specifikus nincs, az az kód, ami az egész oldalt összerakja, elemről elemre, aztán mikor kattogtatsz rajta, akkor felküldi. Ha megnézed inspectorra a lerenderelt oldalt (és nem a html forrást), akkor látni fogod, hogy bizony ott van a domban a dinamikusan összeraktott html.

rájöttem az okára, ez nem form. Úgy néz ki, mintha form lenne, de ez egy teljesen JS-es mókolás

Igen, pont ezt mondtam, hogy ma már elég ritka (ilyen bonyolultabb interaktívabb vackoknál meg gyak nem létező), amikor úgy megy fel egy form, hogy elnavigálja a usert egy POSTttal valami x-form-url-encoded formában (pláne egy urlbe írt GETtel). Ehelyett a user által nézett oldal nem megy sehova, hanem mikor megnyomja a save gombot, akkor a javascript először is jól ellenőrizget egy sort általában, aztán tipik összerak a beviteli adatokból valami jsont, és azt hátul egy ajaxxal fel fogja küldeni, a válasz alapján meg updateli a domot hogy a user lássa pl a veri széved popupot. És ezeket a requesteket 100%, hogy fogod látni azon a netwörk tabon (és nagyobb tételben mernék fogadni, hogy rohadtul hasonlítani fognak arra, ami az api leírásban van ;)

 

A Smartsheet terén nem a hozzáértésemmel van baj

Nem, azzal a webes technológiák körül van baj, láthatólag le vagy maradva úgy nagyvonalúan 15 évvel. :)

Egyébként én meg ezt nem értem, minek ez a cowboy baszakodás? Ha ez szopás, akkor oda kell menni a főnökhöz, hogy figyumán, fel kéne rögzíteni 42 ezer ilyen fost, nem fog menni a formon. Aztán vagy hagyja, hogy csináld direktben, vagy apit hozzáférést, (elmondva, hogy valójában miért van a form, és a lock). Vagy közli, hogy márpedig leülsz, azt bepötyögöd. Mi a tökért vakarózol két napja hátulról?

 

Annyira élethűen HTML input tag-es formnak tűnik megjelenésre ez a spreadsheet-es szar, hogy tényleg nem gondoltam volna, hogy ez egy JS-es barmolás, ami csak szimulálja a form-os működést. Ez nem lemaradás, ilyet nem láttam még, hogy így oldják meg az egészet. Láttam már HTML form + AJAX-os megoldást, de olyat nem, ami így teljesen HTML input tag nélkül old meg mindent. Az is igaz, hogy nem vagyok webdev. Plusz védelmemre legyen mondva, hogy az illető JS egy 50 ezer soros szösszenet, egy sorba obfuszkálva, jó, hogy elsőre nem vágtam le belőle a poént.

Végül egyébként jó volt a gyanúm, formurl?parameter1=ertek&parameter2=bizbasz lett a megoldás. Nem küldi el automatán, de eleve kitöltve tölti be a „formot” így a böngésző. Automatán küldeni nem lehet, de azt AutoHotKey-vel oldom meg. Elvileg lehetne powershellben, a böngészőnek küldött JS-es üzengetéssel, de az AHK-t amúgy is kell használnom a folyamat során másra is, így végül is nem baj.

Volt egy kis nehézség, hogy mik a paraméternevek, de végül vagy a Spreadsheet tábla oszlopának a címe volt, vagy az form mező fölötti kiírás, így egy kis próbálkozás kellett hozzá, de megoldottam. Egyelőre ma csak leteszteltem, nem kellett még semmire, majd holnaptól nyomatom be a tételeket automatizáltan, lesz egy csomó, kb. 500 formkitöltés, ami gépírva is igénybe venne egy teljes napi munkaidőt, de így csak kevesebb, mint egy óra lesz, mivel tesztképpen még kézzel nyomkodom az elküldés gombot, ha jól vizsgázik, legközelebb már nagy tételnél is automatikus lesz az egész, akkor meg töredéke idő. Azért semmiképp nem egy pillanat egy kitöltés, mert a böngésző komotósan tölti be a formot, meg utána küldésnél is időzik, megnézi, hogy a szerver elfogadta-e az adatokat. Így kb. 5-10 mp. mindenképp rámegy egy beküldésre. Mondjuk ha teljesen URL-ben küldeném az egészet, külön böngészőrender nélkül, akkor is várni kéne két beküldés között, hogy ne tűnjön DoS/spam támadásnak.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Annyira élethűen HTML input tag-es formnak tűnik megjelenésre ez a spreadsheet-es szar, hogy tényleg nem gondoltam volna, hogy ez egy JS-es barmolás, ami csak szimulálja a form-os működést. Ez nem lemaradás, ilyet nem láttam még, hogy így oldják meg az egészet. Láttam már HTML form + AJAX-os megoldást, de olyat nem, ami így teljesen HTML input tag nélkül old meg mindent.

Persze, hogy annak tűnik, mert az. Hidd el, hogy ha egy weboldalon egy beviteli mezőt látsz, az az esetek 99.99%-ban egy <input>. Általában benne is van egy <form>-ban. Csak nem a backend rendereli ki a htmlt, mint régen, hanem a frontenden a js. Te bekvered a fejedben a form actiont meg a submit típusú inputot bele, az nincs, de attól az még egy form. Csak nem felpostoljuk/geteljük, hanem a JS csinál vele valamit.

Ma már szinte minden minden komplexebb web alkalmazás u.n. single page web app, a browser egyszer betölti, aztán az ő szempontjából többet nem történik navigáció, elindul a js, és az csinál mindent. Összerakja a html elemeket valahonnan beszedett adatokból, kezeli a gombnyomásokat, amik hatására visszaküld adatokat, meg amiket kap, azokkal on the fly updateli a renderelt htmlt (Egy átlagos angular oldal html forrása kb annyi, hogy "<body><app-root/></body>"). A backend meg olyat nem csinál, ő jellemzően json adatokat lát, és csoki. Mert valójában a klasszikus webes ide-oda navigálgatunk, az rohadt alkalmatlan komplex, interaktív feladatokra, mikor nulláról kéne újratölteni a mindenséget is egy gomnyomásra. Szóval csinálja a JS, még mikor azt hiszed, hogy navigáltál, mert változik az url, akkor is. Még ami nem SPA, és a nagyobb darabok között klasszikusan navigál, az is ezt csinálja legalább valamennyire mindenféle kicsit is komplexebb formon. És ma már ez az alap, kb bárminél, ami nem faék egyszerű. Szóval de, le vagy maradva :)

Nem kell form meg submit gomb. Igen röviden:

van egy ilyen meződ aminek az ID je data1


<div id="data1" contenteditable="true">Ezt  lehet editálni</div>

Ha valami esemény , akéemi elindit egy javascriptet, a javascript megkeresi a data1 értékét és elküldi a mgfelelő helyre..... 
Semmi submit, semmi form, a küldést intézi a js: (de már ezt az oldalt is a js-sel egy js állította elő, )

document.getElementById('data1').addEventListener('input', function() { sendData('data1'); });

senddata meg intézi. 

https://blog.claryel.hu

Erre ránézek, mert ilyet még nem láttam.

Egyelőre működik a módszerem, URL?parameter1=érték1&parameter2=blabla... módszerrel előre kitöltöm a formot, ezt is már AutoHotKey2 szkripttel küldöm a böngésző címsorába, majd elküldöm, szintén ugyanaz az AHK szkript, lemegy az oldal aljára, ott megnyomja nekem a JS-es gombot, és elküldődik a form, én csak egy dedikált gyorsbillentyűt nyomok, a többi része automata.

Sajnos kicsit lassú, 6-7 másodpercnek el kell telnie két beküldés között (erről is gondoskodik a szkript), mert ha gyorsabban csinálom, a Smartsheet szerver egyre jobban lemarad, utána meg sokáig nem is veszi be a beviteleket, csak látszólag, gondolom valami spam/DoS filterbe futok bele. Így alig gyorsabb, mint gépírva meg Ctrl+C/Ctrl+V vagy Ctrl+C/Win+V-vel töltögetni, de kevesebb mentális munka, kényelmesebb. Azért van, hogy 500 formot is elküldök egy nap, ennél mindegyiknél 11 mezőt kitölteni azért nagy munka, ehelyett könnyebb csak 500 darab gyorsbillentyűt nyomni. Majd nagyobb fokban automatizálom még, de teljesen nem lehet, mert azért van pár tétel, ami más, meg nem csak a termék sorozatszám változik, hanem más adat is, de abból is van pár ugyanolyan. Olyan sokszor van, hogy 200-300 tételnél minden megegyezik, csak a sorozatszám tér el, ennél a legnagyobb segítség a minél nagyobb fokú automatizáció.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Get: 

Ai csinált egy js+GET metódusos küldést, xx.hu szerver persze nem válaszol majd:

irj egy htmloldalt ami egy bevitrli mezöt tartalmaz, ha ez a mezo a focusból kikerül egy javascript induljon el és get metódussal küldje el az xx.hu serverre a mezőben lévő szöveget

 

debuggolás, léptetés: F12 - sources -event lisener -> control ->blur- pipa. 
F12 - network fülön ott lesz a get a megszokott formában 

Request URL:

https://xx.hu/?input=aaaa

 

<!DOCTYPE html>
<html lang="hu">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Beviteli mező</title>
    <script>
        function handleBlur(event) {
            const value = encodeURIComponent(event.target.value);
            const url = `https://xx.hu?input=${value}`;
            
            // Egy GET kérést küldünk a szerver felé.
            fetch(url)
                .then(response => {
                    if (!response.ok) {
                        throw new Error('Hiba történt a kérés során!');
                    }
                    return response.text();
                })
                .then(data => console.log('Szerver válasza:', data))
                .catch(error => console.error('Hiba:', error));
        }
    </script>
</head>
<body>
    <h1>Beviteli mező példa</h1>
    <label for="inputField">Írj be valamit:</label>
    <input type="text" id="inputField" onblur="handleBlur(event)">
</body>
</html>

https://blog.claryel.hu

F12, source, -> event listener ->mouse, keyboard. A debugger pl. ha egérlenyomást észlel elkezdi lépésenként futtatni a scriptet. 
Figyeled , tovább léptetsz és szép csendben megőszülsz...  :-)

Beállításokban source map ne legyen kipipálva.

https://blog.claryel.hu

Ezt azért kipróbálom holnap, kíváncsiságból. Ilyen event listening-es léptetést nem csináltam még, annyira kíváncsivá tettél, hogy már csak érdekességképp is kipróbálom.

Szerk.: a fenébe, ezt elfelejtettem megnézni, majd csak hétfőn tudom pótolni.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Na, kipróbáltam. Úgy néz ki, hogy ezzel előrébb lettem. Kiderült, hogy a smartsheet.com/b/form/hosszu_formazonosito formátumban behozott formot a smartsheet.com/api/submit/hosszu_formazonosito formában küldi el, és ezt a json-t csatolja hozzá valahogy, talán POST átadással:

------WebKitFormBoundaryXYNdzNkBmW9NzjBC
Content-Disposition: form-data; name="data"; filename="blob"
Content-Type: application/json

{
	 "6wzDdn1jr" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo1_tartalma" 
	},
	 "QD0PL5q10" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo2_tartalma" 
	},
	 "wN0ER7XOk" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo3_tartalma" 
	},
	 "zAlM7vPOl" : {
		 "type" :  "STRING" ,
		 "value" :  "" 
	},
	 "9yXenQ0Ak" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo4_tartalma" 
	},
	 "31zQgoLRg" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo5_tartalma" 
	},
	 "grk5KwE9j" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo6_tartalma" 
	},
	 "GYwdmRy7Q" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo7_tartalma" 
	},
	 "Ol1K6lJXm" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo8_tartalma" 
	},
	 "lXkARJRP1" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo9_tartalma" 
	},
	 "grkw7o2PE" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo10_tartalma" 
	},
	 "KypnER6bM" : {
		 "type" :  "STRING" ,
		 "value" :  "mezo11_tartalma" 
	},
	 "EMAIL_RECEIPT" : {
		 "type" :  "STRING" ,
		 "value" :  "" 
	}
}
------WebKitFormBoundaryXYNdzNkBmW9NzjBC--

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Kikapcsolt javascript esetén lehet h normál html formot generálna, nem? 

Úgy tűnik az inputok azonosítóit random generálja, valószínüleg minden alkalommal más azonosítót kapnak és szerver oldalon tárolja, h melyik azonosító melyik inputot jelzi. Ilyesmit azért szoktak csinálni, h nehezítve legyen az automatikus küldés ill. h rejtve legyenek az inputok valódi nevei - amik gyakran utalnak az adatbázis mezőienk neveire.  Ha ez így van, akkor minden alkalommal előzetesen parsolnod kell, h mik az aktulális input azonosítók és az alapján kell aztán beküldened az adatokat egy sessionon belül. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Kikapcsolt javascript esetén lehet h normál html formot generálna, nem? 

Kétlem, akkor szerintem semmi nincs. (Illetve továbbra is, az egy teljesen normális html form, csak nem a backend generálja, hanem a frontend)

valószínüleg minden alkalommal más azonosítót kapnak és szerver oldalon tárolja, h melyik azonosító melyik inputot jelzi. Ilyesmit azért szoktak csinálni, h nehezítve legyen az automatikus küldés ill. h rejtve legyenek az inputok valódi nevei - amik gyakran utalnak az adatbázis mezőienk neveire.  Ha ez így van, akkor minden alkalommal előzetesen parsolnod kell, h mik az aktulális input azonosítók és az alapján kell aztán beküldened az adatokat egy sessionon belül. 

Szintén kétlem, szerintem itt pusztán arról van szó, hogy mivel ebben szakmány tudják összekattogtani a userek a formokat, ezért kell nekik egy azonosító, és nem szopnak a user input baszkurálásával, hanem generálnak neki egy egyedit, azt kész. Szóval ebben az esetben imho azok épp az adatbázis mező nevei lesznek ;) és szerintem nem fognak változni, amíg a form definíciót nem baszogtatja valaki.

Egyébként se nagyon látni olyat szerintem, hogy sessionhöz kötögetve van ilyen csakazért is id váltás, minimál gain, ha egyáltalán, hosszas önszopatásért cserébe.

 

Simán küldeni kell, amit kell, azt jól van (bár az a webkitformboundary adhat még némi fájdalomra okot.)

Ez eszembe se jutott, letesztelem kikapcsolt JS-tel.

Amúgy nem random generálja, a mezők azonosítói mindig ugyanazok, ezt ellenőriztem több napon át. A token-t generálja random, de azt a form-ból ki lehet szedni, a HTML kódjából. Viszont valami ID-t meg egy a Boundary-hosszúkódot mindig másként generálja, gondolom valami titkosítással, szóval itt elakadtam egyelőre.

Pedig már félig működik, curl-lel etetem POST küldéssel, Json adatokat, de egy kis rágódás után észreveszi, hogy nincsenek validálva.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A boundary mindegy, szabadon választhatod. A külső content-type headerben van valószínűleg valami ilyesmi:

Content-Type: multipart/form-data; boundary=ExampleBoundaryString

És akkor simán csinálhatod, hogy

--ExampleBoundaryString
Content-disposition: ...
Content-type: application/json

{"valami": "json"}

--ExampleBoundaryString
Content-disposition: ...
Content-type: application/json

{"valamimás": "json"}
--ExampleBoundaryString--

Azt kész (note a legvégén a plusz két minuszt). De egyébként a curl -F segítségével kezeli ezt a man alapján.

A valami ID-t ha megmutatod, arra is adunk tippet. :)

Így van, pont ilyen multipart formdata Content-disposition baflaszsággal működik, egyelőre csak ennyit mentettem ki:

------WebKitFormBoundaryXYNdzNkBmW9NzjBC
Content-Disposition: form-data; name="data"; filename="blob"
Content-Type: application/json

{"6wzDdn1jr":{"type":"STRING","value":"TBC"},"QD0PL5q10":{"type":"STRING","value":"bla"},"wN0ER7XOk":{"type":"STRING","value":"bla"},"zAlM7vPOl":{"type":"STRING","value":"bla"},"9yXenQ0Ak":{"type":"STRING","value":"bla"},"31zQgoLRg":{"type":"STRING","value":"bla"},"grk5KwE9j":{"type":"STRING","value":"bla"},"GYwdmRy7Q":{"type":"STRING","value":"bla"},"Ol1K6lJXm":{"type":"STRING","value":"bla"},"lXkARJRP1":{"type":"STRING","value":"bla"},"grkw7o2PE":{"type":"STRING","value":"bla"},"KypnER6bM":{"type":"STRING","value":"bla"},"EMAIL_RECEIPT":{"type":"STRING","value":""}}
------WebKitFormBoundaryXYNdzNkBmW9NzjBC--

Az egészet a https://forms.smartsheet.com/api/submit/384a5e05869b4bacb52c21aa4016214e címre küldözgeti, ez utóbbi egy állandó, de hosszú azonosítója a form-nak (az 50 ezer soros JS kód ezt form-key-nek nevezi)i, ez nem változik soha. A boundary, meg egy másik ID valami, az viszont minden formlekérésnél, beküldésnél változik. A token is, de azt ki lehet szedni a form HTML kódjából, az nem gond, csak a boundary, meg az ID fütyiség zavar be. A teljes multipart fejlécet majd holnap tudom csak betenni ide, ahol a token meg a másik kód is látszik.

Ennek kapcsán lenne egy kérdésem is. F12 Source, Event, stb. ablakban a Chrome szétszedi grafikusan a webszerverre menő és onnan jövő üzeneteket, azt hogy tudnám elérni, hogy magát a nyers plain text kommunikációt lássam, és ne legyen szétszedve GUI elemekre? Ilyen opciót nem találtam.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Igen, látom ott, de szétszedi GUI elemekre. Nekem úgy kéne, hogy az egész forgalmat, összes kérést, választ lássam plain text-ben. Ne legyen különböző GUI fülekre szétdarabolva soronként. Úgy, mintha logfile lenne.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Mert a GUI-ból még a json/.har bullshitből nem látom, hogy mi volt az eredeti HTTP request. GUI-t, egérkattintasokat, meg Json-t nem tudok a curl-lel megetetni. A curl-nek tényleg szabályos HTTP request kell, ahol megfelelő helyen vannak törve a sorok, stb..

Próbáltam, hátha Wireshark-kal látom a HTTP kéréseket, de az nem működik a munkahelyi gépen, nincs rendszergazdai jogom a npcap capture-höz.

Szerintem az lesz, hogy otthon beregisztrálok magánemberként a Smartsheet-ben, és ott csinálok formot, és otthon tesztelem Wireshark-kal.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Komolyan nem értem, mit szerencsétlenkedsz :) Milyen egérkattintás meg mittomén? De, a network tabon a konkrét requesteket látod, amik kimennek. Ez ugyan róka, de látod, requestek:

https://imgur.com/a/iUbJSRr

kiválasztasz egyet, pl a htmlt, ami lejött:

https://imgur.com/a/7935zCZ

Aztán látod bodyt, meg a headereket, meg az anyámat is. Van mindenhol egy raw gombocska, aztán kimásolod, ha nagyon kell. De hogy kb a headerek azok bizony Name:<space>value sorok, aztán jön egy üres, meg a body. A jsonnak mindegy a sortörés.

A harban meg szintén konkrétan benne van text formátumban.

Túlmisztifikálod ezt, nem kell neked kézzel bithelyes http requestet rajzolni (nem mintha nagyon bonyi lenne), a curlt vagy a httpie-t vagy valamit kell felparaméterezned rendesen multipart form dataval, aztán csoki. Vagy megírni 10 perc alatt mondjuk python requests-szel.

De pont ez az, hogy én nem ilyet látok. Elég hosszú, mezőkre bontott felsorolást, mivel nem HTML-t kérek le, hanem POST requestet küldök a szerver felé. Ezt a POST küldést elemzem, és nekem nincs Response, csak Header meg külön fülön Payload (benne az a json, amit már betettem), de pl. Raw gomb sincs sehol. Én kb. ezt látom a böngészőben a requestet megnyitva:

Request URL:
https://forms.smartsheet.com/api/submit/384a5e05869b4bacb52c21aa4016214e
Request Method:
POST
Status Code:
200 OK
Remote Address:
34.203.47.131:443
Referrer Policy:
strict-origin-when-cross-origin
access-control-allow-origin:
*
content-length:
212
content-type:
application/json
date:
Fri, 21 Mar 2025 08:54:54 GMT
strict-transport-security:
max-age=31536000; includeSubDomains
vary:
Origin
vary:
Access-Control-Request-Method
vary:
Access-Control-Request-Headers
x-smar-forms-version:
1.139.8
x-smar-request-id:
aaaadfnx5glye05niworp7605urhg2hb4
:authority:
forms.smartsheet.com
:method:
POST
:path:
/api/submit/384a5e05869b4bacb52c21aa4016214e
:scheme:
https
accept:
application/json, text/plain, */*
accept-encoding:
gzip, deflate, br, zstd
accept-language:
en-US,en;q=0.9
content-length:
816
content-type:
multipart/form-data; boundary=----WebKitFormBoundary3AZJvBKinEUwMqDC
origin:
https://app.smartsheet.com
priority:
u=1, i
referer:
https://app.smartsheet.com/
sec-ch-ua:
"Chromium";v="134", "Not:A-Brand";v="24", "Google Chrome";v="134"
sec-ch-ua-mobile:
?0
sec-ch-ua-platform:
"Windows"
sec-fetch-dest:
empty
sec-fetch-mode:
cors
sec-fetch-site:
same-site
user-agent:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36
x-smar-forms-version:
1.139.8
x-smar-is-user:
true
x-smar-submission-token:
qx8q4zfiljbyk5j0xf83

Ahogy küldeném curl-lel, a szerver válasza egy json adathalmaz, meg után egy HTML doksi, amiben közli, hogy nem jó a fejléc.

curl -X POST "https://forms.smartsheet.com/api/submit/hosszu_azonosito" -H "Content-Type: application/json" --data-binary @temp

A kiterjesztés nélküli temp fájlban az a json van, amit már linkeltem, próbáltam benne hagyni a formboundary-s és Content-Diposition sorokat, meg azokat elhagyva is, meg próbáltam -H "Content-Type: multiform/data; WebkitformBoundary...blabla" formában is, hogy a böngészőben F12 alatt látom a requestet, de ezt válaszolja vissza a szerver a curl-nek:
{"timestamp":"2025-03-21T17:02:23.230+00:00","message":"Invalid Input Exception","errorType":"INVALID_REQUEST_MISSING_HEADER","messageParams":{}}

Majd ezután még mindjárt utána nyomja egy hibaoldal HTML kódját, amit nem mentettem el, nem releváns.

Azért mondom, hogy a böngésző GUI bullshitje nem segít összerakni, hogy PONTOSAN mit küldjek a szervernek, nekem soronként kéne, a teljes request, ami a szerver felé megy. Hibátlannak kell lennie, de számít a sortörés, hogy mi van egy sorban, mi nem, hol van kettőspont, mikor marad ki üres sor, stb..

Próbáltam úgy is, hogy Chrome-ot egy logolási paraméterrel indítottam, amiben kértem, hogy adott fájlba logolja a requesteket, és logolja is, de az is json-ban van. Nem értem, hogy miért csak json-ban van minden, a HTTP protokoll nem json. Egész más fejlécei vannak, más szintaxis. Épp úgy plain text, mint a json, de nem json.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

De pont ez az, hogy én nem ilyet látok. Elég hosszú, mezőkre bontott felsorolást, mivel nem HTML-t kérek le, hanem POST requestet küldök a szerver felé. Ezt a POST küldést elemzem, és nekem nincs Response, csak Header meg külön fülön Payload (benne az a json, amit már betettem),

Nyilván ecsém, ha jsont küldesz, akkor az lesz benne, csak azt mutattam meg, hogy kb mi a fenét kéne látnod.

de pl. Raw gomb sincs sehol

Mert mint említettem, ez egy róka. Most hadd ne tegyek fel egy chromeot, tuti abban is van ilyen funkció, jobb a debuggere.

Azért mondom, hogy a böngésző GUI bullshitje nem segít összerakni, hogy PONTOSAN mit küldjek a szervernek, nekem soronként kéne, a teljes request, ami a szerver felé megy. Hibátlannak kell lennie, de számít a sortörés, hogy mi van egy sorban, mi nem, hol van kettőspont, mikor marad ki üres sor, stb..

Nem tudnál idetenni egy hart? mert megint idevágtál olvashatatlanul egy rakat headert, és valójában nem érted, mit csinálsz, közben gyanús, hogy egy vödör dolgot összemosol, ami nem egybe tartozik, fingod sincs, hogy abból mi a lényeges, meg mi az, amit egyébként is hozzárakna pl a curl.

De mondom, akkor tegyél fel egy mitmporxyt, standalone binary, bekonfolod proxynak, aztán akkor nézegetheted a pontos requesteket, kimásolhatod, még a curlt is összerakja neked pontosan

Még mindig nem érted. Nekem komplett POST request kell, egy plain text dokumentum, benne fejléccel, mindennel, hiánytalanul, sehol egy sortörés vagy más nem hiányozhat belőle. Egy megszakítás nélküli plain text stream, amit meg tudok etetni a curl-lel, és az úgy el tudja küldeni a szerver felé, hogy az elfogadja. Igen, van benne json, de az csak egy hosszú sor, a request többi, 99%-a json mentes. Json csak abban az egy boundary töredékben lesz, aminek a content-type-ja application/json. De az csak egy kisebb része a lekérésnek, nekem a többi 99%-kal van bajom. Ebben a böngészők meg a websoydevek json tagolásos meg .har kiterjesztéses hülyesége NEM segít.

Este teszek be egy példát, hogy mit értek GUI tagoláson, de csodálkozok, hogy nem érted. Szét van szedve a böngésző F12 Network részén a request, különböző fülekre, füleken belül is ilyen GUI azonosító-érték mezőkre, ez megnehezíti a request pontos rekreációját.

Nekem a NYERS reqest kell, ami a szerver felé megy. Nem json, nem .har, nem GUI, azok nem küldődnek a szerver felé. A HTTP, FTP, meg a mail, IRC, stb. nem véletlen emberi szemmel is olvasható plain text protokoll. Pont azért, hogy egy unixos terminálból is lehessen akár nyomni, head, tail, grep, sed, sort, stb. kombóval, és ne kelljen hozzá se JS, se egy gigás böngésző, se json, se Selenium, se más barmolás.

A proxy viszont nem rossz ötlet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Még mindig nem érted. Nekem komplett POST request kell, egy plain text dokumentum, benne fejléccel, mindennel, hiánytalanul, sehol egy sortörés vagy más nem hiányozhat belőle. Egy megszakítás nélküli plain text stream, amit meg tudok etetni a curl-lel, és az úgy el tudja küldeni a szerver felé, hogy az elfogadja

De, én értem :) Te nem érted, hogy működik a HTTP, ezért rohadtul kalapálni akarsz bruteforce :) Nem lesz jó, vannak benne olyan headerek, amiknek adott esetben változniuk kell, és van egy köbvödör olyan benne, ami nagyjából lényegeteken :)

Este teszek be egy példát, hogy mit értek GUI tagoláson, de csodálkozok, hogy nem érted. Szét van szedve a böngésző F12 Network részén a request, különböző fülekre, füleken belül is ilyen GUI azonosító-érték mezőkre, ez megnehezíti a request pontos rekreációját.

Ja, hogy nem a form elemeire, hanem hogy külön darabban van a headers, meg a body a debuggerben? lol, öcsém :D

A HTTP, FTP, meg a mail, IRC, stb. nem véletlen emberi szemmel is olvasható plain text protokoll.

Kemény szavak ezek valakitől, aki nem tudja összerakni azt a HTTPt. :D :D :D

Mint mondtam, a konkrét boundary értéke mindegy, csak passzoljon a külső content-type-ban a boundaryval. Kizárólag arra való, hogy szét tudja szedni a túloldal a darabokat.

Chrome most nincs előttem, és ezt a gui elemeket nem is értem, de ahogy kolléga is mondja, a network tabot nézd, ott látszik az összes http request, válaszostul, headersetől mindenestől

Ezek a krix-kraxok a json-ban lennének az állandó input nevek? 
Igen, a fapados változat hogy egy hidden input elembe tettek egy mindig változó tokent, és nem az egyes inputok azonosítóit változtatgatták állandóan. Akkor elég volt annak az egy inputnak az értékét kiszedni a forrásból az automatizáláshoz. 
Nem fogod megúszni a javascript debuggolást :-/ 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Más megközelítés: http://www.sikulix.com

Ezzel grafikus felületen tudod automatizálni a dolgot - ingyenes. Képernyőkép (részlet) alapján azonosítja hova kell kattintania, odakattint beirja a kívánt adatot (amiket egy szkriptből olvas fel) pont mintha te ülnél a böngésző elött - a végén elküldi a formot és jöhet a következő iteráció.  Mondjuk ez nem kifejzetten böngészőhöz készült, hanem általánosan működik mindenféle programra. Direkt böngészőre sztem vannak ennél jobbak is ezzel a megközelítéssel.  Illetve vannak ilyenek fizetős változatban azok felhasználó barátabbak. 

Oké h parancssor van megszokva, de ha már túl komplikált a parancssorra faragni a dolgot, mert láthatóan 50.000 soros js-sel szivatják az embert egy nomrál form helyett, akkor lehet h érdemes elengdeni és mást próbálni! Csak ötlet. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Sajnos az a baj ezekkel a GUI-s automatizációkkal, hogy lassú, meg ha nem úgy időzítődik a GUI válasz, véletlen elmozdul az ablak, késik a form renderlése, akkor félrecsúsznak, nem oda kattintanak, lemaradnak. Pont ez a baja az AutoHotKey scripttel is. Ráadásul ha GUI automatizáció van, akkor nem csinálhatok mást a gépen, fókuszban kell lennie a böngészőnek, formnak.

Ha viszont terminálban futó szkript, az sokkal megbízhatóbban automatizálható, hibamentesebben működik, és lerakhatod az ablakát, elmolyol a háttérben, csinálhatsz mást a gépen. Nem marad le, nem kell fókuszban lennie, még böngészőnek se kell hozzá futni. Csak egy szkript, tekeri ki a curl paraméter1 paraméter2 blabla sorokat, meg sleep $whatever_sec sorral felváltva, nekem nem kell látnom, hogy mit csinál.

Pont ez a poén, hogy a GUI nem automatizálni való. Arra a CLI való, nem véletlen, hogy az összes encoder, transcoder, converter, compiler, interpreter, server deamon, stb. CLI-s. Mert ez automatizálható rendesen, hibatűrően. A GUI az egybites usereknek van lámulni, nem akkor, ha komoly munkát kell végezni, meg automatizálni.

Itt pont ez a baj, hogy ezt a kibaszott webes Smartsheet nyomorékságot, meg a hozzá való hülye webes formokat is egybites hülyéknek csinálták taknyolni. Erre rendes adatbázis-szerver lenne való, ami ért sztenderd vagy sztenderd-közeli SQL-t, ott szépen lehetne szintén CLI szkriptből összerakni csak egy nagy INSERT feldolgozást, hogy mit emeljen be az adatbázisba, és ezt elküldeni neki egy autentikáció után, alig lenne pár sor, ott már a szervert se kéne egyenként zargatni, csak egyszer, és tömbösítve berakni a szájába az összes változást. Sokkal kisebb overheadje lenne az egésznek, szerver meg kliensoldalon is, nem kéne hozzá GUI taknyolás, JS, json, egyenként formokat nyomkodni, lófaszozás, tisztára, mint a kisegítőben.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ha a munkaeszköz egybites hülyéknek való, akkor vagy te vagy rossz helyen, vagy ha jó helyen vagy, akkor a munkáltatód tekint egybites hülyének.
Egyébként a gui-s felület is automatizálható, a selenium-ot nagyon sok helyen használják masszív tesztelésre, de van még néhány hasonló tool...

Tetszőleges probléma megoldhatatlanná fejleszthető a megfelelő hozzáállással. 
Az már kiderült h vajon h elküldeni ugyan azt küldi, mint amit beírtál az inputoknak? Ugyanis elég aggasztó az 50.000 sornyi js - h mégis mi a fenét csinálhat? Bőven lehet h megváltoztatja az inputok értékét, titkosítja, valami hash-t számol validáláshoz az inputok értékeiből amit szintén elküld - ezt h fogod majd parancssorból megvalósítani? Biztos megoldható, még ha kapásból nem is tudom h állnék neki - de nem biztos h érdemes vele szívni!

De ha jól értem - javíts ki ha nem - az inputok értékét be tudod adni  "form" urljén keresztül. Akkor automatizálni már csak annyit kéne, h a sikulix rákattintson a "SEND" gombra, nem? 
Világ legjobb melója! Bemész reggel elindítod a géped, azt teszi a dolgát, te meg boldogíthatod a titkárnőket addig! Abszolút fedezve leszel a főnök elött :-D 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

( fezo | 2025. 03. 13., cs – 16:12 )

Python - Selenium - Chrome/Gecko driver?

Minden hulla a Mount Everesten valamikor egy nagyon motivált ember volt.