AJaX en cross-domain subdomeinen

[plofkip]

Hey mensen!

Ik zit met een probleempje. Ik heb een site 'sub.domain.com'. Hierin worden een paar AJaX calls gedaan, maar om dit iets sneller te maken (je kunt er maar 2 tegelijk doen) wil ik calls doen naar subdomeinen.
Eerst wilde ik iets als cache1.sub.domain.com, maar dit is dus niet mogelijk door de same-origin policy.
Nu heb ik dit artikel gelezen en let dan vooral op deze tekst:

There is one exception to the same origin rule. A script can set the value of document.domain to a suffix of the current domain. If it does so, the shorter domain is used for subsequent origin checks. For example, assume a script in the document at http://store.company.com/dir/other.html executes this statement:

document.domain = "company.com";
After execution of that statement, the page would pass the origin check with http://company.com/dir/page.html.
However, using the same reasoning, company.com could NOT set document.domain to othercompany.com.

Dit zegt dus dat ik van sub.domain.com een AJaX request kan uitvoeren naar een suffix, dus naar domain.com door 'document.domain = "domain.com";' uit te voeren. Deze variabele wordt geset (gechecked d.m.v. een alert), maar toch krijg ik de volgende exception:

code:

uncaught exception: Geen toestemming om methode XMLHttpRequest.open op te roepen

Iemand enig idee wat ik fout doe, hoe ik dit op kan lossen, of dat er een andere manier is om dit te doen?

[Verwijderd]

mja, zonder code wordt het toch glazen bol kijken en daar ben ik wat minder goed in

[crisp]

Voor zover ik weet heeft document.domain in de meeste browsers geen effect op de same domain check voor XHR...

[rogierslag]

Ik wil quoten: plan: Afbeeldingen voortaan geserveerd via Tweakimg.net (tweede thread) dat een subdomein dit niet oplost, hiervoor dien je een volledig losstaand domein te gebruiken...

[plofkip]

crisp schreef op maandag 04 februari 2008 @ 21:40:
Voor zover ik weet heeft document.domain in de meeste browsers geen effect op de same domain check voor XHR...

Die bron die ik erbij heb staan is van de mozilla site, dan zou dit toch op z'n minst in Firefox moeten werken? En er wordt op internet veel gesproken over deze manier als 'the way to go'... NOFI

rogierslag schreef op maandag 04 februari 2008 @ 22:12:
Ik wil quoten: plan: Afbeeldingen voortaan geserveerd via Tweakimg.net (tweede thread) dat een subdomein dit niet oplost, hiervoor dien je een volledig losstaand domein te gebruiken...

Verwijderd in 'plan: Afbeeldingen voortaan geserveerd via Tweakimg.net'

Daar staat dat het wel per subdomein gaat, iemand die dit kan bevestigen?

[ Voor 27% gewijzigd door plofkip op 04-02-2008 23:24 ]

[crisp]

FaNtJuH schreef op maandag 04 februari 2008 @ 23:23:
[...]

Die bron die ik erbij heb staan is van de mozilla site, dan zou dit toch op z'n minst in Firefox moeten werken? En er wordt op internet veel gesproken over deze manier als 'the way to go'... NOFI

Er staat daar nergens dat dat ook zou gelden voor interface extensions, en mijn eigen ervaringen zijn ook dat dat niet werkt. Er wordt wel gewerkt aan cross-(sub)domain XHR door verschillende browservendors maar dat is nog toekomstmuziek... (en dan heb je nog IE waar XHR helemaal niet native is).

[Niemand_Anders]

Waarschijnlijk zullen cross domain scripts nooit meer mogelijk zijn omdat in het verleden een aantal eikels zo nodig javascript moesten misbruiken. Daarom is in de javascript specificaties opgenomen dat javascript alleen op het 'eigen' domein werkt. Je kunt bijvoorbeeld ook niet in een frame een pagina vanaf een ander domein inlezen en verolgens daarvan via javascript de cookies lezen.

Om te voorkomen dat ajax calls in de toekomst misbruikt gaan worden om 'onderwater' gegevens door te geven aan andere partijen, zal XmlHttpRequest alleen op hetzelfde domein blijven werken.

Alleen al om de gevolgen van een HTML/javascript injection te beperken. Nog steeds kom ik websites tegen waarin ik HTML tags in mijn username kan gebruiken en die worden daarna niet geescaped.

Overigens is de limiet van twee concurrent requests bij mij nog nooit een probleem geweest. Misschien kun je ook meerdere calls combineren en via een json array de responses daarvan terug geven. Ik gebruik daarvoor een dispatcher url.

JavaScript:

Object dispArgs = new Object();
dispArgs.getUserState = "";  // <-- call a server side method 'GetUserState' 
dispArgs.getMessages = "userid=" & getCookie("userid") & "&limit=3";

Ajax ajax = new Ajax();
ajax.Url = "http://ww.website.nl/dispatcher.ashx";
ajax.Send(dispArgs, processUserData);

De argumenten worden op dezelfde manier verwerkt als query string argumenten. Mijn dispatcher returned een json string welke een array vormt van functie naam en de response. Onze daadwerkelijk implementatie is iets anders, maar ik denk dat het idee wel is overgekomen.

[dawuss]

Niemand_Anders schreef op dinsdag 05 februari 2008 @ 09:04:
Waarschijnlijk zullen cross domain scripts nooit meer mogelijk zijn ...

offtopic:
Nou ja, dat is wel heel erg doemdenken. Er zijn echt wel andere oplossingen denkbaar hoor. Om een voorbeeld te noemen: Flash is standaard ook sandboxed tot het domein vanwaar het geladen wordt, maar dat is aan te passen door op die zelfde server een crossdomain policy file neer te zetten, die Flash vervolgens respecteert. Niet om te zeggen dat dit de "way to go" is, maar er zijn echt wel oplossingen denkbaar die niet gevoelig zijn voor cross site scripting attacks e.d.

[plofkip]

Het probleem is dat ik RSS feeds inlaad d.m.v. AJaX. Dit duurt nogal eens behoorlijk lang, als je dan 8 feeds inlaadt duurt het al onwijs lang. Daar zoek ik een oplossing voor