[JS/AJAX] Cross-site XMLHttpRequest niet mogelijk?

[BlueAce]

Via een <script>-tag include ik een AJAX structuur in mijn HTML. Die HTML pagina staat alleen niet op hetzelfde domein, maar op een compleet andere site. Dit is het gedeelte van mijn code waarin de XMLHttpRequest zich voordoet:

code:

var isWorking = false;

function loadIt() {
    if (!isWorking && http) {
        http.open("GET", "http://www.domain.com/action.php?do=load&url="+window.location.href, true);
        http.onreadystatechange = function() {
            if (http.readyState == 4 && http.responseText.indexOf("invalid") == -1) {
                var xmlDocument = http.responseXML;
                
                            // Hier doe ik dus van alles en nog wat met de XML, en print het...

            }
        }
        isWorking = true;
        http.send(null);
    }
}

function getHTTPObject() {
    var xmlhttp; /*@cc_on
    @if (@_jscript_version >= 5)
        try {
            xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
        } catch (e) {
            try {
                xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
            } catch (E) {
                xmlhttp = false;
            }
        }
    @else
        xmlhttp = false;
    @end @*/
    if (!xmlhttp && typeof XMLHttpRequest != "undefined") {
        try {
            xmlhttp = new XMLHttpRequest();
        } catch (e) {
            xmlhttp = false;
        }
    }
    return xmlhttp;
}
var http = getHTTPObject();

Wanneer ik de pagina met de <script> include probeer te laden en dus de functie loadIt() gebruik dan krijg ik de volgende foutmelding in Firefox:

code:

Fout: uncaught exception: Toestemming om methode XMLHttpRequest aan te roepen geweigerd.open

Als ik wat rondzoek op Google kom ik toch een tegenvallende conclusie: cross-site AJAX kan niet. Is dit ook werkelijk zo? Of kan ik de permission misschien wijzigen of iets dergelijks? Even niet kijken naar het doel van dit script, het gaat hier puur om het technische: kan het of niet?

Mocht iemand dit dus zijn tegen gekomen of de oplossing weten: mijn eeuwige dankbaarheid en wellicht meer

[ Voor 13% gewijzigd door BlueAce op 23-05-2005 09:58 ]

[Bluestorm]

Het kan in iedergeval door op het eigen domein een perl/php/... scriptje te draaien wat de requests gewoon doorstuurt. Voor het wijzigen van permissies ben je volgens mij altijd afhankelijk van client instellingen en daarmee dus niet erg betrouwbaar.

[BlueAce]

Bluestorm schreef op maandag 23 mei 2005 @ 10:16:
Het kan in iedergeval door op het eigen domein een perl/php/... scriptje te draaien wat de requests gewoon doorstuurt. Voor het wijzigen van permissies ben je volgens mij altijd afhankelijk van client instellingen en daarmee dus niet erg betrouwbaar.

Precies, en ik wil ook niet dat de client iets anders moet doen dan simpelweg het scriptje includen.

[semicolon]

Ik heb zelf ook een scriptje gemaakt met XMLHttpRequest, en getest in OSX: Safari, Camino, Firefox, en op Windows: IE6 en Firefox.

Kijk ook overigens eens naar http://www.mozilla.org/xmlextras/ en dan XMLHttpRequest.open.

file:// documents can access http:// documents but you need to enable UniversalBrowserRead privilege in your scripts - see the JavaScript Security: Signed Scripts document for more details. Normally your files should reside on a webserver so this shouldn't pose a problem (there you do not need that line either). Additionally, "foo.com:80" and "foo.com:313" are considered different hosts for security purposes. You cannot open a connection to a different host.

Dit bovenstaande was een probleem dat ik eerst had bij Firefox, omdat ik met file:// het html bestand teste en http://localhost stond de pagina die aangeroepen werd. Dat werkt dus niet.

Als ik het goed begrijp is dat ook wat jij probeert te doen, van http://www.a.com/ iets opvragen van http://www.b.com/. Nou is wat hierboven gezegt wordt door BlueStorm het beste dan, een tussen script die de echte remote request doet.

Een stukje code wat ik gebruik bij mijn systeem:

JavaScript:

var http = null;

try{
  http = new ActiveXObject( "Msxml2.XMLHTTP" );
}catch(e){
  try{
    http = new ActiveXObject( "Microsoft.XMLHTTP" );
  }catch(e){
    try{
      http = new XMLHttpRequest( );
    }catch(e){
      http = false;
    };
  };
};

if( !http ){
  // Foutje bedankt.
}

Natuurlijk moet je dan nog de rest doen.

[ Voor 15% gewijzigd door semicolon op 23-05-2005 13:30 ]

[BlueAce]

Max v W schreef op maandag 23 mei 2005 @ 13:25:
Als ik het goed begrijp is dat ook wat jij probeert te doen, van http://www.a.com/ iets opvragen van http://www.b.com/. Nou is wat hierboven gezegt wordt door BlueStorm het beste dan, een tussen script die de echte remote request doet.

Tja helaas is dat dus geen optie. De dienst die ik opzet, daar hoort geen PHP interventie bij.

[semicolon]

BlueAce schreef op maandag 23 mei 2005 @ 14:48:
[...]


Tja helaas is dat dus geen optie. De dienst die ik opzet, daar hoort geen PHP interventie bij.

Dan zou je enige optie -naar mijn kennis- zijn om het met Firefox en externe sites te laten werken, dus het Signen van je scripts zijn. Op die link die ik meestuurde staat ook hoe je dat kan doen.

[BlueAce]

Max v W schreef op maandag 23 mei 2005 @ 14:53:
[...]

Dan zou je enige optie -naar mijn kennis- zijn om het met Firefox en externe sites te laten werken, dus het Signen van je scripts zijn. Op die link die ik meestuurde staat ook hoe je dat kan doen.

Ik ben er nu mee aan het kloten, thx.

Overigens: ik krijg in Explorer ook een "permission denied".

[Anoniem: 97824]

Komt omdat het niet echt goed is voor security. Ook in IE zul je het eerst moeten toelaten als eindgebruiker.

[BlueAce]

Anoniem: 97824 schreef op dinsdag 24 mei 2005 @ 18:28:
Komt omdat het niet echt goed is voor security.

Tja daar valt over te discussieren. In mijn geval zie ik totaal niks fouts aan cross-site XMLHttpRequest eigenlijk. Ik vraag informatie op die ik net zo goed voorgeschoteld kan krijgen via een directe request.

Maar goed, kennelijk zijn browserdevelopers het daar niet met me over eens. Jammer, daar gaat m'n idee

offtopic:
Leuk trouwens om hier Anne van Kesteren tegen te komen, ik check je blog regelmatig

[ Voor 4% gewijzigd door BlueAce op 25-05-2005 09:24 ]

[Anoniem: 143036]

Misschien dat je hier wat mee kan ik heb niet getest op cross browser maar het werkt met POST dus het misschien kunnen.

http://twilightuniverse.com/2005/05/sack-of-ajax/

Een lokaal php script die de pagina ophaalt dan ben je natuurlijk echt zo klaar. maar dat is geen optie

p.s. wat is je idee dan eigenlijk

[BlueAce]

Anoniem: 143036 schreef op woensdag 25 mei 2005 @ 09:56:
Misschien dat je hier wat mee kan ik heb niet getest op cross browser maar het werkt met POST dus het misschien kunnen.

http://twilightuniverse.com/2005/05/sack-of-ajax/

Een lokaal php script die de pagina ophaalt dan ben je natuurlijk echt zo klaar. maar dat is geen optie

p.s. wat is je idee dan eigenlijk

Uhm... waarom zou ik een standaard AJAX code-pack nodig hebben als ik het zelf al heb geschreven? GET of POST: het maakt niets uit.

Dat idee ga ik hier btw niet vertellen. Niet dat het 't ei van Columbus is, maar ik wil het wel uniek houden.

[ Voor 9% gewijzigd door BlueAce op 25-05-2005 16:40 ]

[AkaXakA]

Get of Post: Maakt wél uit.

Leest het volgende voor meer informatie: http://www.jasonlefkowitz.net/blog1archive/001667.html

[Anoniem: 97824]

Get of Post: Maakt wél uit.

Niet voor cross domain scripting.

[BlueAce]

Anoniem: 97824 schreef op donderdag 26 mei 2005 @ 10:14:
[...]
Niet voor cross domain scripting.

Precies, het komt hier neer op de permission: die wijzigt niet bij GET naar POST.

[BlueAce]

Ik heb een mailtje gestuurd naar Jessy James Garret (kenners kennen hem waarschijnlijk hiervan) met de vraag of het klopt dat cross-site ajax onmogelijk is. Zijn antwoord:

I have not tried to do it myself, but I have been told that cross-site Ajax is possible in IE with some adjustments to the security settings. Naturally, we usually can't expect users to lower their security settings, so I think your finding about cross-site Ajax is essentially correct.

Case closed dacht ik, totdat me iets te binnen schoot: zou dit misschien WEL kunnen met Flash? Of heb ik dan hetzelfde permission probleem?

[BlueAce]

Ik moet eerlijk bekennen dat ik niet alles van A tot Z weet over Flash, dus zou iemand me wat duidelijkheid kunnen verschaffen?

[Anoniem: 32071]

Ik denk dat dit ook niet mogelijk is met Flash. Wat jij wil kan namelijk ook gebruikt worden om cookies te jatten.

[Anoniem: 97824]

Flash kent geen cookies afaik.

http://www.google.com/search?q=cross+domain+flash

(Lijkt me een logische stap. Eigenlijk, Google is de logische stap op zoek naar een antwoord.)

[Anoniem: 97824]

quote: http://www.macromedia.com...ase/index.cfm?id=tn_14213

For security reasons, a Macromedia Flash movie playing in a web browser is not allowed to access data that resides outside the exact web domain from which the SWF originated.

As an enhancement to Macromedia Flash Player 7, domains must be identical for data to be read. With this change a sub-domain can no longer read data from a parent domain and vice versa.

quote: http://www.macromedia.com...layer_security_print.html

Macromedia has made some changes to the cross-domain security model in Macromedia Flash Player 7. For the most part, the new restrictions apply only to movies made for the new player. However, data loading in older Macromedia Flash movies may stop working as intended when played in Macromedia Flash Player 7. This article explains how to fix this issue for existing movies, how to use policy files (see Security Restrictions for Data Loading for details), and what the other security changes are.

Er zijn diverse anderen nog te vinden. Voor deze gebruikte ik: http://www.google.com/sea...ia.com+cross+domain+flash

[BlueAce]

Ik had het gezien ja, lijkt me duidelijk dus. Bedankt.

[Anoniem: 14124]

Er zitten zowiezo nog wel wat haken en ogen aan het verhaal vast. Een head request naar een ander domein bijvoorbeeld levert in IE ook nog wel eens een permission denied error op, terwijl we hier praten over een simpele head request en daar komt dus nog geen eens scripting aan te pas. Cross domain scripting enablen voorkomt de error, maar wat die permission denied dus triggert weet ik niet precies.

Ik heb hier een voorbeeld staan van een testje wat ik ooit eens had gemaakt voor een linkchecker, maar dat liep dus vast op het permission denied verhaal en ik heb er verder niet meer veel tijd aan besteed

http://www.mschopman.demon.nl/linkchecker.html

Hij voert dus een head request uit via xmlHttpRequest, om de status te controleren van de link.

Onder Mozilla zul je zelf ook nog eens, als klap op de vuurpijl, moeten gaan rommelen met privilege bestanden om vervolgens de privileges te enablen voor cross domain scripting.

PHP:

if (typeof netscape != 'undefined' && typeof netscape.security != 'undefined'){
        netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');
    }

[ Voor 20% gewijzigd door Anoniem: 14124 op 01-06-2005 10:44 ]

[Anoniem: 97824]

Hoe zit zo'n head request precies in elkaar? Als je kunt uitvogelen of die site bijvoorbeeld al bezocht is doordat je een 304 terugkrijgt kan ik me er best iets bij voorstellen. Of je laat die site bepaalde headers teruggeven op informatie die jij meegeeft aan dat domein, et cetera.

[Anoniem: 14124]

Anoniem: 97824 schreef op woensdag 01 juni 2005 @ 11:51:
Hoe zit zo'n head request precies in elkaar? Als je kunt uitvogelen of die site bijvoorbeeld al bezocht is doordat je een 304 terugkrijgt kan ik me er best iets bij voorstellen. Of je laat die site bepaalde headers teruggeven op informatie die jij meegeeft aan dat domein, et cetera.

Ik zou dat even moeten opzoeken in de specs, of met een sniffer (aangezien specs ook maar specs zijn in sommige browsers ) , maar ik verwacht eerlijke gezegd niet meer of minder dan een antwoord terug met encoding, cache, evt. proxy, status, content-length etc. maar de daadwerkelijke scripting niet.

[semicon]

edit sorry ik zie het al laat maar :x

[ Voor 89% gewijzigd door semicon op 01-06-2005 13:14 . Reden: :( ]