Utajene POST data – PHP – Fórum – Programujte.com

Zdravim,

potreboval by simulovat odoslanie formularu zo stranky ktory obsahuje niekolko hidden inputov, ktorych obsahy by som potreboval pred uzivatelom skryt. Konkretne ide o platbu cez paypal (paypay a dalsie....) a musim skryt pole ktore bude obsahovat navratovu adresu s overovacim klucom priradenim ku konkretnej veci, ktoru bude uzivatel platit, pomocou ktoreho sa potvrdi zaplatenie pri navrate na stranku. Cez API (resp. ich system notofikacie) to nemozem urobit, pretoze aj prijemcou bude viac a ty nemusia mat bussines ucet, cize takto je asi jedina moznost overit uspesnost platby.

Poslanim dat cez curl sa mi nezmeni v adresnom riadku adresa, cize system nepusti platiaceho k prihlaseniu. Musi proste clovek prejst aj na stranku danej sluzby.

tu je taka mala ukazka ktora otvori stranku na ktorej sa prevedie platba (cize to iste potrebujem, ale tak aby uzivatel nevedel obsah formulara)

<form method="post" action="https://www.sandbox.paypal.com/cgi-bin/webscr">

<input value="email@predajcu.sk" type="hidden" name="business" />

<input value="_xclick" type="hidden" name="cmd" />

<input type="hidden" name="item_number" value="51465145">

<input value="Nazov polozky" type="hidden" name="item_name" />

<input value="41.50" type="hidden" name="amount" />

<input name="quantity" value="5" type="hidden">  

<input value="EUR" type="hidden" name="currency_code" />

<input type="hidden" name="return" value="http://example.com/?stav=ok&kluc=d4f54wef4we64ewfwef5>

<input type="hidden" name="cancel_return" value="http://example.com/?stav=neuspesna_platba">

<input type="image" name="submit" /> 

</form>

pff, imho to nejde. kdyz predavas data uzivateli, vzdycky jdou nejak odchytit.
osetreni bych hlavne provadel az na samotnem ?stav=ok; primarne kontrolovat HTTP_REFERER, jestli je PayPal.

I ten HTTP_REFERER se da podvrhnout, takze nejlepsi je to neposilat vubec a ulozit si to nekam (treba do Session) nebo kdyz uz poslat, tak zasifrovat a pri postu desifrovat a zpracovat.

:) , v tomto pripade praveze neposielam udaje uzivatelovi, ten len otvori stranku ktora odosle prislusne data cez cURL metodou POST, cize obsah dat uzivatel nemoze vediet, kedze ich posiela server a nie uzivatelov prehladac. Problem je v tom ze sa mi pri tomto ukone nezmeni adresa , ostane adresa stranky ktora odosiela tie data....

Platbu paypalem sem už několikrát implementoval, vždy to probíhalo tak, že jsem vytvořil form, například s tlačítky a hiddeny, kde jsou potřebné parametry. Údaje, které potřebuju já, pro své zpracování, například informace o uživateli, ceně, produktu atd. si zakóduju, pošlu, přijde odpoveď, rozkóduju a pracuju s tím. Ale hidden samotné skrýt nejde.

To wise : predpokladam ale ze pracujes z notify_url a nasledne s IPN. Len u mna je problem, ze to potrebujem urobit tak ze predavajuci si moze ulozit svoj paypal ucet a kupujuci mu to moze okamzite uhradit po kupe zo svojho uctu... a dobre by bolo keby slo potvrdit uspesnu platbu aj na stranke, teda nielen u predavajuceho a kupujuceho (teda to iste ako je napr. na ebayi), a potrebujem nieco univerzalne aby to slo aj na inych platobnych systemoch pracujucich na pricipe formu... zaujimalo by ma ako teda si potvrdzujes uspesnost platby, ak nie cez ipn.... pretoze return_url nie je problem zistit a len ju okopirovat do prehliadaca...

To marioff : vždy když jsem s tím pracoval, tak to bylo pro někoho. Ten si objednal implementační data. Když to bylo muzo od csob, vytvořil jsem soukromý a veřejný klíč, vygeneroval digest a vše poslal ve formu zašifrovaně na GP webpay. Veškeré zabezpečí a autorizace a autentifikace probíhala tam, já jsem v parametrech poslal také url, kam má gp webpay odeslat data v případě odpovědi a na základě get parametrů jsem s tím pracoval.

pokud to byl například paysec, tak taky data, resp. ilustrační form, opět data do hiddenu, tentokrát jednodušeji poslat a opět k nim na https. Takto to dělám já.

To wise : no ja som vcera urobil univerzalny script pre platbu pomocou paypal-u,paypay-u,moneybookers,alertpay-u a google checkout-u. Vsetko je to postavene na formoch, cize nikde nevyuzivam API. Ide mi hlavne o univerzalnost, teda aby kazdemu fungovala moznost takejto uhrady (ako kupujucim, tak aj predajcom, kedze nie kazdy ma obchodny ucet, nemozu vsetci uzivat napr.niektore ficury API). Teraz to ide bez notifikacii o uspesnosti platby, co je skoda pretoze predajca bude musiet stale potvrdzovat prijatie penazi, comu som sa chcel nejak vyhnut, napr. tym poslanim nejakeho kluca priradeneho ku konkretnej platbe... (ale nakoniec som zistil ze vlastne kupujuci sa ani nemusi vratit naspat na stranku) pri vrateni sa na povodnu stranku pri uspesnej platbe. Takze to asi ani nepojde :(

a poslat to zašifrovaný? Můžes si třeba vytvořit nějaký algoritmus, který ti např. a nahradí za B. B nahradí za C atd. Samozřejmě složitějš (jako u skautů :). to pošleš, ty jedinej budeš vědět ten algoritmus (stačí třeba přes klasický asociativní pole a pak ten přijatej hash rozkoduješ. Takže např. si uděláš:

$muj_kod = array("A" => "%", "B" => "x",....); a mezeru třeba za "A" a samozřejmě, abys to ještě víc udělal složitější,tak třeba mezeru zakoduješ pomocí třeba 4 znaků. Takže mezera bude třeba "A", "3", "x" a "-". A takhle ti to prostě nikdo nemůže zjistit.

a pak druhý pole například, kde to bude opačný (toto řešení mě teď napadá, možná to bude lepšejc jinak).

Ve zdrojáku uživatelé vidí pouze tvůj zašifrovanej text. no a když přijde, opět rozkoduješ a můžeš s tím dělat co potřebuješ.

Co si o tom myslíš?
Například base_encode bych nepoužíval, jelikož je to obousměrné a někdo kdo o tom ví, tak si ten hash zkopíruje do svého fomu někde u něj a rozkoduje. Stejně tak nepoužívat md5, jelikož je jednosměrný. Ale pokud si vytvoříš vlastní šifru. A nemuselo by to být složité, máš vyhráno.

Snad sem to vysvětlil srozumitelně :)

bohuzial je jedno ci bude ten kluc zakodovany alebo "plain"

zober si to takto: v hiddene mas return_url, teda adresu ktora sa nacita po uspesnom ukonceni platby (toto umoznuju vsetky platobne procesory, ktore chcem vyuzivat), teda staci tuto len skopirovat a vlozit do prehliadaca ako adresu... a tymto potvrdi zaplatenie, aj ked nezaplatil vobec....

pravdepodobne neexistuje univerzalne riesenie, ak tak, budem sa musiet pohrat zo vsetkymi APIckami vsetkych sluzieb (problem je ze nemusia fungovat vsetkym userom, kedze script musi byt univerzalny pre vela predajcov), alebo nechat predajcov potvrdzovat vsetky platby po ich prijati ... inak to asi fakt nepojde...

ak tak ma niekto este nejaky napad, ako to aspon zjednodusit, sem s nim :)

To marioff : ale ty data posíláš třeba postem ne? Tak když ale si tu adresu zkopíruje a vloží ji, tak má potrvzeno, ale chyběj mu tam nějaký údaje ne? tak podmínka? Možná sem to špatně pochopil vycházím z toho, jak to mám řešený já :)

na stranke zo zahajenim platby mas formular s udajmi ako nazov polozky, cena, pocet atd a medzi nimi taketo nieco:

<input type="hidden" name="return" value="http://example.com/?id_polozky=5&kod=f5g456a4g56a4g56ga46">

je to adresa na ktoru sa uzivatel vrati po uspesnom vykonani platby. premenna kod je napr. nahodne vygenerovany string ku kazdej platbe. Ked platobny procesor vrati uzivatela na tuto stranku, sa tam overi spravnost kodu a tym padom uzna platbu ako uspesnu....

Lenze samozrejme je mozne tuto adresu opisat a vlozit ako adresu do prehliadaca a tym padom si potvrdis platbu bez skutocneho zaplatenia.

A není možné tento kód vygenerovat až na plat. serveru?

Měla by tam být nějaká ta reakce, že je to zaplaceno. Nějaká odpověď serveru.

Teď mě možná něco napadlo.

Co to udělat takto:

Před generováním formuláře předcházelo koupení/objednání něčeho, díky čemuž se dostal na ten formulář že ano?

Takže když ten uživatel přistoupí na tuhle stránku s placením, kde je uložen ten form a právě i ten hidden s kodem. Tak ten kod pomocí nějakýho šifrování zašifrovat, jak jsem uvedl výše.


Takže:
1 uživatel přijde na stránku s formem.
2. vygeneruje se kód například 123456
3. tento kod si převedeš na nějaký svůj hash. Takže např. zašifrovaný kód bude: asd4584ad54a8d47asda
4. ten původní kód (123456) si uložíš do databáze a taky to ID té položky
5. do inputu vypíšeš ten zašifrovaný, takže ten uživatel uvidí:
<input type="hidden" name="return" value="http://example.com/?id_polozky=5&kod=asd4584ad54a8d47asda">

no..a teď sem si uvědomil, že když to bude na tý stránce a rozkoduje to...tak to může tak i tak...:D takže není možný nějak dostat něco pouze od serveru?

To wise : ano, je mozne pouzit API, resp. IPN (instant payment notification), cize po uspesnej platbe sa pripoji napr. paypal na tvoj server, ktory nasledne uspesnost overi...

lenze je tam lenze.... nechcem api ani ipn.... vsadzal som na cURL, teda ze odoslem POST data (cize uzivatel nebude vidiet co "postol" server) z mojho stroja a uzivatel bude vykonavat platbu... len ani to asi neni mozne (ale nie som si isty), kedze data dostane platobny procesor z ineho stroja a pokracovanie bude prebiehat z ineho (teda uzivatelovho)...

Celou dobu přesně vím, o čem mluvíš, ale přesné řešení taky nevím. Vždycky jsem to jednoduše řešil přes REFERER v landing page, plus jestli chceš, můžeš nějak nenápadně skrýt obsah inputů JavaScriptem (vkládat to přes innerHTML). Najisto to nejde udělat ani POSTováním na PayPal, protože

1) Pokud přesměruješ uživatele, pak na to uživatel může kliknout a zkontrolovat POST hlavičky, které odeslal (přes pluginy)
2) Pokud postuješ PHP scriptem přímo na PayPal, tak se to k uživateli ani nedostane a stejně máš smůlu.

Teď mě napadla jedna věc, možná blbost, ale uvidíme...

proč na tý stránce, která zpracovává platbu (myslím tím teď return url) nepoužiješ SERVER['Http_Referer'] a nezjistíš, odkud ten uživatel přišel? A na základě toho ověříš, jestli ten požadavek přišel od serveru nebo od uživatele.

To wise : ano da sa to riesit aj takto, ale zase nie je problem referera zfalsovat, napr. uz cez zmieneny cURL (curl_setopt($ch, CURLOPT_REFERER, "http://paypal.com/platba.......php");)

ja som este uvazoval o tom ze by som javascriptom kontroloval novo otvorene okno (otvoril by som nove na platbu), teda pracu v nom a jeho zatvorenie, ale to je uz na hranici z bezpecnostou.... :(

wise: Hehehehe... O refereru tu píšu od prvního příspěvku, je to primární ochrana, ale ne vždy dostačující:)
Stejně pokud budeš dělat něco důležitějšího, IPN se nevyhneš. Jen z mouky se špatně dělá ovocný dort:)

To w3m : jj to som ja.... ja by som chcel vsetko jednoducho (nie ze by som nevedel aj "zlozito", ale v jednoduchosti je krasa - toho sa drzim cely svoj zivot) a zaroven z velkou efektivitou (ale niekedy sa to da), v tomto pripade vsak budem musiet pre kazdu jednu branu nakodit konekty na ich API... jaaaj mam co robit zase :)

Ve světě platí, že API nejsou pro srandu. Kdyby sis všechno mohl udělat sám, velké služby by se na API velmi rády vykašlaly.:)
To nic nemění na tom, že u menších projektů vystačuje kontrola REFERER a následně manuální kontrola (Accept x Cancel&Ban) na základě přijatých plateb. Pokud děláš něco většího, tak ti API přinesou větší pohodlí a bezpečí:)

To w3m : tak to pardon, nevšim sem si :)