JavaScript: Weblap letöltés

Internet: PHP, CGI, stb.

Üdv!

Szeretnék egy olyan megoldást az egyik weblapomra, hogy egy gombnyomásra egy JS megnyit egy php filet, de HTTP queryvel, mivel a php kimenetelére lenne szükségem, amit utána beolvasok egy változóba, úgy, hogy eközben a weblap ugye nem töltődik újra, és nem lép át másik lapra, etc... Az a baj, hogy nem tudom, hogy hogyan is kereshetnék erre, mi ennek a neve... Gondolom valami AJAXos izébizét keresek. Akinek van valami megoldása, vagy tippje az ne fogja vissza magát :)

köszi ;]

  • 3719 megtekintés

Fura a dolog, mert ennél a sornál elakad:

http_request.open('GET', 'http://sinuslink.hu/?oldal=stat', false);

és a webszerver logjában sem látom, hogy próbálkozna... :\ Ötlet?

szerk.: Error: uncaught exception: [Exception... "Access to restricted URI denied" code: "1012" nsresult: "0x805303f4 (NS_ERROR_DOM_BAD_URI)" location: "http://ittmegitt Line: 29"]

A probléma az lesz, hogy másik szerverhez nemigazán lehetséges konnektelni így, szerintem, de még googlezok...

korlátozottan jó megoldás:
a javascripteket bárhonnan be lehet tölteni. Ergó az idegen szervertől ilyen formában kell neked az adat:
callback_fuggveny(a_php_által_küldött_adat)

aztán beleinjektálsz a másik oldalon lévő kódodba kódodba egy ilyent:

ekkor meghívódik a callback_fuggveny, ami pedig lekezeli neked a kapott adatot. Persze ehhez az kell, hogy mindkét szerveren legyen némi dúlási jogod :)
Azt hiszem, yahoo pipes-szal bizonyos adatok valamilyen módon átalakíthatóak jsonp-vé, de még nem tudom, hogy hogyan is :)

egyszóval a kulcsszó: jsonp, allback 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

az ilyesmit biztonsági okokból tűzzel-vassal meg akarják akadályozni. Gondolj csak bele, egy ilyen módszerrel bizonyos körülmények közt pl. session id-t lehetne lopni.
Van a w3c előtt egy draft a cross-site http requestekről, miszerint akkor lehetne engedélyezni, ha a válaszheader tartalmaz egy paramétert – ez lehetővé tenné, hogy a szerver a kényes adatok letölthetőségét megakadályozza.

Ebből kifolyólag ha nincs hozzáférésed a másik szerverhez, javascriptből biztosan akadályba fogsz ütközni, ha a kliens böngészőjét és ip-jét kell használnod. Flash-t lehet, hogy tudsz proxyként használni.

Cuzammenfásszung:
- biztonsági okokból amit szeretnél, minden értelmes böngésző megakadályozza.
- a távoli szerver API-n keresztül szolgáltathat adatot
- vannak más szép jövőbeni kilátások is, de mindegyik azon alapul, hogy a távoli szerver teszi explicite hozzáférhetővé az adatokat
- ha nem olyan fontos a böngésző és IP, akkor megoldható: saját php proxyval, Yahoo pipes-szal. Utóbbira itt látsz egy példát, amit az ezen a linken látható módon lehet paraméterezni, hogy bele-dom-manipulálva a weboldaladba meghívja a neked tetsző callback függvényt, ami lekezeli az adatokat…

Az eredeti elképzelésedet okkal akadályozza meg mindenki. 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( Yorirou | 2009. 07. 17., p – 22:38 )

jQuery-ben ez nagyon szépen és egyszerűen megoldható

Vagy iframe-et raksz be, ha nem maga a tartalom erdekel, mert az megy.

http://prototype-window.xilinus.com/samples.html

(Open a window with an URL inside)

De ha mindenkeppen fel akarod dolgozni, akkor

<?php
echo file_get_contents("http://sinuslink.hu/?oldal=stat");
?>

Amit jo lenne, ha nem egyszerusitenel tul - nagyon szep ha parameterkent kapja az URL-t, csak azt open proxynak hivjak, es egy aranyos kis biztonsagi lyuk lesz belole.

Nem igazan erzem, ha valamin megy a curl_exec($url), de nem megy a fopen($url), az mi a franctol biztonsagosabb... Az, hogy mitol lassabb, azt tudom, meg hogy mitol erthetetlenebb, es elsosorban ez szamit.

"jajj majd ha feltorik a programodat" -> ha valaki olyan URL-t tud adni a fopennek, vagy ad absurdum require-nek/include-nak, amit nem kene, valszeg mas bajok is lesznek a szoftverrel. Egy olyan script, ami egy konstans URL-rol ker le valamit, nem ez a kategoria.

Hasonloan, remelem erzed, a srac se a nemzeti banknak ir epp intranet programot (legalabbis remelem). Ilyen esetekben meg a funkcinalitas a lenyeg, az egyszeru valaszok. Mint ahogy a programozas se arrol szol - jo, kivetel: security engineer - hogy hogy tudod a leheto legbiztonsagosabban megfogalmazni a kerdest: Arrol szol, hogy tudom a leheto legkifejezobben megfogni az adott funkcionalitast. A security egy jarulekos dolog. Egyebkent 15 sor curl alapon stream-drivert fejleszteni kb, es maris ismet van fopen-ed, amit pl. lekorlatozhatsz csak adott domainekre (a legnagyobb baj, hogy ezt a mostani beepitett http driver nem tamogatja, nem az, hogy meg lehet nyitni kenyelmesen is tavoli eroforrasokat, mert az jo es hasznos).

Ha elolvasod a threadnek az elejet, ott vilagosan kifejtettem szerintem, hogy ezt a fopen-t csak ugy csinalja, ha KONSTANS url-sztringet ad at neki. Namost ha ugy atcsusszannak a porno oldalak, az csak ugy lehet, ha valaki az URL-en levo oldalt feltorte elozoleg.

A bajom az ilyen tipusu security gondolkodassal, az hogy a programozonak nem az a feladata, hogy biztonsagot csinaljon, a programozonak az a feladata, hogy funkcionalitast biztositson. Ehhez kepest a security masodlagos. Nem nem fontos, nem sokadlagos, de cseszhetem ha van egy szuperbiztonsagos hello worldom, mikozben nekem operacios rendszerre lenne szuksegem.

Ezt fejtettem ki az elobb. Egy szoval nem emlitettem, hogy nem fontos a biztonsag. Azt mondtam, hogy tema szempontjabol mind1.

Bocsánat, de nem mindegy, milyen kulcsot generál?
Számára az IP a te szervered címe lesz, böngésző meg... amit hazudsz neki :)

Nem PHP-zok, de gondolom ahhoz is van olyan osztály, mint a .NET HttpWebRequest-je, amivel akár egy teljes sessiont is "szimulálhatsz".
(Sőt, végső soron nc-vel is meg lehet oldani :)

Mar miert lenne mindegy? A session id fontos valami, ugyanis ezzel lehet megelozni a session lopast. Foleg ha router mogott vagy, egyaltalan nem biztos, hogy az IP a te geped IP cime lesz. Lehet, hogy egyben meg 8 masik gepe is.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( turdus | 2009. 07. 20., h – 23:55 )

Én speciel ezt az egész cross-site scriptinget hülyeségnek tartom, mivel sok hasznos feature-t is elveszítünk vele, és ráadásul egy egyszerű módon megkerülhető: iframe. Mondjuk annyi előnye van, hogy xmlreq esetén nincs csík, a user nem látja, hogy az oldal töltöget a háttérben, míg iframe-nél látja.

Egyébként a menet a következő:
1. iframe loader id-val és name-el
2. document.getElementById('loader').src=URL
3. vársz, míg betöltődik (ez a trükkös rész)
4. eztetdolgozdfel=loader.document.body.innerHTML
csont nélkül működik az ÖSSZES modern, biztonságosnak kikiálltott böngészőn nem-domain alatti url-re (sőt, régebbieken is, a fenti metódust pl IE6-ra csináltam eredetileg, mivel nem támogadta az xmlreq-et, így tettem kompatíbilissé).

furállottam a dolgot, úgyhogy direkt megnéztem, a firebug a következőt dobja:
"Permission denied for <http://127.0.0.1&gt; to get property Window.document from <http://hup.hu&gt;.
testiframe.html()testiframe.html (line 11)
[Break on this error] var x = setTimeout("alert(loader.document.body.innerHTML)", 5000);\n"

akkor az enyém biztonságosabb, mint a többi mai biztonságosnak kikiáltott böngésző ;)
a kód kb. ez volt:


<iframe name="loader" id="loader"></iframe>
<script type="text/javascript">
document.getElementById("loader").src = "http://www.hup.hu";
var x = setTimeout("alert(loader.document.body.innerHTML)", 5000);
</script>
 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

ilyenkor az egyszeri programozó, aki eddig nem tette meg, leül szépen, és újragondolja.
Miért kell neked pl. a kliens ip-je meg a böngészője? Eddigi információink alapján hozzá kell férned valamihez, amihez a kliens is, mégpedig auoimatizáltan.
A legtöbb weboldalnak közömbös a kliens ip-je, ami az azonosítást illeti. Igen, a böngészője is. Azonos kliensről és böngészővel sokszázan is netezhetnek pl. egy NAT mögül. A szolgáltatások sütikkel azonosítják a delikvenseket. No, azt nemigen fogod ám a kliensektől kiimádkozni.

Legegyszerűbb, ha bekéred az azonosítókat, és bejelentkezel a szerveroldali proxyddal. Ha ezt meg lehetne kerülni, már rég a fél internet a mailjeidet olvasná. 

—-—-—
int getRandomNumber() {
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

<?php
$ch = curl_init() or die(curl_error());
//tavoli weboldal, azaz a celpont
curl_setopt($ch, CURLOPT_URL,"http://weboldal-aminek-kell-a-forrasa.php?get-parameterek=ha-kellenek");

//ha szeretnel POST-olni ertekeket
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,"postolni-kivant-param=ertek&kovetkezo=ertek");

//kerjuk vissza az eredmenyt valtozoba bele, jol
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$forras=curl_exec($ch) or die(curl_error());

echo $forras //lemented, megjelenited, azt csinalsz vele amit akarsz

//viszlat
curl_close($ch);
?>

Ennyi. Nem kell frame, javascript, semmi.

X-Forwarded-For?

Ha szerencsed van, akkor transzparens modon azt hiszi IP-nek az alkalmazas, nem pedig azt, amitol tenylegesen jon a keres. Ezt egyes rendszerek elrejtik, masok nem... egy probat meger. A bongeszo adatait meg siman at tudod kopizni, sot, minden request header-t...

http://en.wikipedia.org/wiki/X-Forwarded-For