Beste cross domain access methode

[Xandrios]

Hoi,

Ik ben bezig met het uitwerken van een idee voor een website. In dit geval heeft deze website een belangrijke requirement: ik moet cross domain communicatie doen.

Voor diegenen die niet weten wat dit inhoud, ik wil het volgende: De webapplicatie draaiende in de browser van een gebruiker, opgestart via www.test.com, maakt een socket connectie naar een poort of andere webservice op domain www.blaat.com. Dit wordt afgeblocked door browsers om te voorkomen dat een webapplicatie bijvoorbeeld www.gmail.com inlaadt en zodoende toegang heeft tot informatie die niet publiekelijk is.

In mijn geval wil ik oftewel een raw socket, oftewel http requests kunnen versturen, maar ik wil geen toegang hebben tot bijvoorbeeld de browsers cookies. Dus daarmee wijkt het gevaar dat ik andere websites inlaadt en daarna content kan zien dat niet toegestaan is.

Mijn vraag is wat hiervoor een juiste aanpak is. Ik weet dat met Java applets (signed) ik dit in feite allemaal kan doen. Echter daarvoor moet de bezoeker de Java JRE geïnstalleerd hebben, en applets zijn van nature tráág, zeker bij de eerste keer opstarten. Daarnaast is signen duur, enkele honderden euro's per jaar.

Flash draaiende in de browser kan ook sockets opzetten naar een ander domain, echter deze vraagt dan als eerste een policy file op.. Aangezien ik geen controle heb over het target domain zal dat niet werken.

Zijn er ook mensen hier die wel eens succesvol een applicatie hebben geschreven dat crossdomain communicatie doet? Welke methode heb je gebruikt?

Bedankt :-)

[ieperlingetje]

als ik cross domain wil gaan en geen problemen wil, maak ik een simpel server side scriptje die de inhoud ophaalt van de url die je oproept. Iets simpels als

PHP:

<?php
echo file_get_contents($_GET["url"]);
?>

volstaat al.

[Grijze Vos]

Voor cross domain access van webservices kun je jsonp prima gebruiken.

[Xandrios]

Thanks beide. Server-Side werken is inderdaad een makkelijke oplossing, maar kan in dit geval niet gebruikt worden. Het is belangrijk dat het IP van de bezoeker van de website als origin geldt bi het fetchen van data van een remote website.

Grijze Vos, jsonp werk toch enkel als ik json data wil ophalen? Het geeft me niet de mogelijkheid om vrije get/post operaties te doen op een remote website? (vanuit de browser van de bezoeker)

Helaas heb ik geen controle over de remote server, die valt niet onder mijn beheer.

[ Voor 9% gewijzigd door Xandrios op 10-10-2011 13:25 ]

[crisp]

CORS is misschien (deels) bruikbaar; grootste nadelen zijn:

- geen support in Opera
- voor IE moet je XDomainRequest gebruiken welke nog wel wat limitaties heeft

[Xandrios]

Thanks :-) Cors vereist de remote webserver nog wel om een speciale header te sturen; die zal er vaak niet zijn.

Flash heb ik eigenlijk al een beetje opgegeven; deze vereist een policy file of speciale policy server op het IP van de remote webserver. Het lijkt erop dat enkel een Java applet de mogelijkheid biedt om echt sockets te openen vanuit de browser en te connecten naar een andere host.

Vind het toch vreemd dat er zoveel security aanwezig is hiervoor. Indien er geen toegang is tot cookies ed, waarom worden ditq soort dingen nog zo veel afgeblokt in JS en Flash?

[RobIII]

Xandrios schreef op maandag 10 oktober 2011 @ 13:24:
Het is belangrijk dat het IP van de bezoeker van de website als origin geldt bi het fetchen van data van een remote website.

Daar kun je, als je server-side werkt, X-Forwarded-For voor gebruiken, gewoon even met een header('...') toevoegen et voila. Afhankelijk van of de andere kant daar mee overweg kan is dat de beste oplossing IMHO.

Xandrios schreef op maandag 10 oktober 2011 @ 14:17:
Vind het toch vreemd dat er zoveel security aanwezig is hiervoor. Indien er geen toegang is tot cookies ed, waarom worden ditq soort dingen nog zo veel afgeblokt in JS en Flash?

Safety as default; er zijn zat webdevelopers die, bijvoorbeeld, geen HTTPOnly op hun cookies zullen zetten e.d. en daar ga je dan als je geen SOP hebt.

Verder move ik je topic even naar WEB; daar staat 't beter dan in SEA.

[ Voor 47% gewijzigd door RobIII op 10-10-2011 14:39 ]

[Xandrios]

Thanks :-)

X-forwarded-for wordt door bijna elke webapplicatie genegeerd, de waarde ervan is namelijk vrij in te vullen. Voor bijv. Webserver access logs wordt eigenlijk altijd het originating IP gebruikt.

Wat ik wil doen is een dienst opzetten die bepaalde taken op 3rd party websites makkelijker maakt. Een random voorbeeld (niet realistisch, maar puur als technisch voorbeeld) is het bestellen van ns tickets vanuit een portaal. Deze portaal kan dan natuurlijk serverside ns.nl contacten dmv verschillende get/post commando's, maar er is een kans dat de website van de ns dat afblokt indien er veel verkeer is. Door dit vanuit de browser van de bezoeker te doen, is het (voor de ns) 'normaal' verkeer.

[Vircos]

Ik ben er niet geheel in thuis, maar binnen Java bestaat de "commons-httpclient" library. Je kan je op die manier als een client (browser voordoen) en de normaal in de browser getoonde content parsen. Verder ben je volgens mij ook in staat om met deze library aan de hand van scripting het ns bestelformulier in te vullen. Maar ook dit gebeurt allemaal op de server zelf. Misschien dat je middels ajax vervolgens één of andere oplossing kunt realiseren waardoor de communicatie tussen je server en de daadwerkelijk client mogelijk wordt..

Nogmaals ik ben er niet geheel en thuis en misschien kraam ik wel volledig onzin uit.

[martin149]

Je kunt natuurlijk ook een server-side een ip laten meesturen via een simpele POST/GET. Je kunt deze dan zo uitleven in PHP oid

[RobIII]

martin149 schreef op dinsdag 11 oktober 2011 @ 19:40:
Je kunt natuurlijk ook een server-side een ip laten meesturen via een simpele POST/GET. Je kunt deze dan zo uitleven in PHP oid

Moet de andere kant dus wel actief die waarde uitlezen (= meewerken)

Xandrios schreef op maandag 10 oktober 2011 @ 11:40:
Aangezien ik geen controle heb over het target domain zal dat niet werken.

[ Voor 23% gewijzigd door RobIII op 11-10-2011 21:49 ]

[Xandrios]

Dat is inderdaad het grootste probleem. In dat geval zal ns.nl mijn IP in hun access logs zien - en het zal me niets verwonderen als ze dit blokkeren omdat ze niet snappen waarom ik zoveel verkeer op hun website genereer.

[ieperlingetje]

Ik weet niet waarvoor je de ns site wil gebruiken, maar kun je de update frequentie dat je naar ns.nl niet verlagen naar een aanvaardbaar niveau (éénmaal per dag of uur) en dan de data cachen of moet je de data echt real time hebben? Als je het dataverkeer binnen de perken houdt merken ze het meestal niet op.

[ Voor 3% gewijzigd door ieperlingetje op 13-10-2011 18:10 ]