CrossSite scripting

Du kan ikke scripte på tværs af domæner (længere).

Ok. Svar.

Hvis det er et must, og også et must, at de skal ligge på forskellige domæner, kan du kun komme omkring det, ved virtuelt at lægge dem på samme domæne som hovedsiden ...

Det lyder interessant! Jeg er dog ikke sikker på hvad du mener helt præcist. Gider du uddybe hvad det vil sige at lægge dem virtuelt på samme domæne?

Hvis du henter koden til siden, som ikke ligger på samme domæne som hovedsiden vha. xmlhttprequest (et activeX-object), kan du så skrive den ind i iframen, og det vil så for browseren fremstå som om al koden stammer fra samme domæne ...

-- der er selvfølgelig den hage, at man under alle omstændigheder får sikkerheds-alerten, samt at det såvidt jeg ved kun virker i IE og Gecko-browserne (Mozilla, Netscape m.m.) på windows ...

-- og de har så forskellig syntaks !-)

du kan have en 3. frame der ikke ses, men som klarer kommunikationen:

Det er kreativitet! :-)

ldanielsen ... hvilket domæne skulle den 3. frame så være på? og hvad skulle man kunne opnå?

roenving, jeg kan godt se din løsning virker ... meget imponerende :)

Men det går bare ikke med den sikkerheds-alert. Det lyder som noget der ikke virker længere om 2 uger, næste gang Microsoft udgiver et security patch.

Uden en promt er der ingen løsning - derfor jeg skrev ingen løsning :)

Nej, det er ikke problemet, for activeX-komponentetn er i pricippet den samme, man i andre sammenhænge bruger til almindelig xml-requesting ...

-- og jeg kan ik' li'e se, at det at have en tredje frame fjerner problemet med at cross-domæne scripting bare er forbudt !-)

-- og mit nej var selvfølgelig til niels' kommentar om M$-patching ...

Jeg kan ellers godt lide løsningen - jeg bruger den sikkert en anden gang. Jeg kan bare ikke bruge den her, fordi systemet skal være langtidsholdbart.

frame1: domain1/side.htm
frame2: domain2/side.htm
frame3: <tom>

Hvis du så har en variabel, strNavn i frame1 som du vil have over i frame2, så siger du fx:

frame3.location = "domain2/transport.html?strNavn=" + strNavn;

og domain2/transport.html har noget i denne stil
var strNavn = "" + window.location;
strNavn = strNavn.split("?")[1];
strNavn = strNavn.split("=")[1];

frame2.document.forms[0].textfield.value = strNavn;

Så har strNavn bevæget sig fra frame1 til frame2

Tænk så på detteher:

i frame1
frame3.location = "domain2/transport.html?document.forms[0].submit();

og i frame3:
eval("frame2." + window.location.split("?")[1]);

du kan altså fra frame1 submitte formen i frame2

ldanielsen - det lyder faktisk ikke helt idiotisk efter femte gennemlæsning. Jeg kigger lige lidt på om det kan lade sig gøre.

Jamen det kan det skam, har selv brugt det. Jeg har dog ikke lige testet mine eksempler, så der er måske lidt typo's

Der er selvfølgelig nogle risici ved det. I mit sidste eks bliver den kode der sendes med i url'en eksekveret ukritisk. Det er nok ikke en god ide.

Men ved at kode det sammen, så transport.html forventer at få tingene på en bestemt måde, så kan du opsætte næsten en hvilken somhelst kommunikation. De tre filer skal jo "kende hinanden" rimelig godt.

-- og fire, hvis man skal kommunikere begge veje ...

Tak skal I have gutter. Skal vi få lukket spørgsmålet?

<ole>

nielsbrinck >> Er du interesseret i fremtidsikring, bør du helt klart vælge XMLHttpRequests. Dét er fremtid!  ;o)
Du kan være ret sikker på, at ved IE's næste opdatering, bliver denne feature udviddet væsentligt - ligesom den formodentlig bliver implementeret i de få browsere, der endnu ikke understøtter XML ordentligt. Der er ingen, der gider blive ved med at skrive specialkode til gammelt skrammel (... ta' dén Opera *Hehe*).
Det skulle undre mig, om ikke iframe'en forsvinder fra WWW længe før XMLHttpRequests  ;o)

/mvh
</bole>

Hvem synes du skal ha' point?

ldanielsen og roenving

ok

Jamen, så velbekomme '-)

Tak skal I ha' gutter! :)

-- og tak for point ;~}

og good luck med det