[Windmill-dev] Facebook X-domain problem

[Adam Christian]

I am really glad to have made this progress, I am going to dive into  
this later tonight and see if I can come up with an OOTB solution on  
the client side. I have a couple ideas, and will report my findings!

Thanks guys for the digging, this was a fun one.

Adam

On Jan 3, 2008, at 9:12 PM, Mikeal Rogers wrote:

> It's great that we've tracked this down.
>
> So, it's a horrible hack, but if anyone wants to write me a regular  
> expression that will strip any javascript that sets document.domain  
> and doesn't break any valid javascript I'll implement it. Short of  
> that, I think we're going to need a client side fix.
>
> In addition, I could add a js snippet to the end of every javascript  
> file that sets the document.domain to the test domain. Another hack,  
> but doable.
>
> I would like to add tho, this is the first time we've meddled with  
> the proxy data at this level. We do a lot of crazy magic with  
> forwards and header re-writes to get everything looking like we stay  
> in the same test domain but we've never removed/added js snippets.  
> The probability of breaking client js in the server will go up with  
> a server side fix and probably result in a lack of confidence in the  
> server end when we have to debug problems like this.
>
> I'd like to hear what you all have to say about possible fixes and  
> their impact on windmill. At the end of the day though, I hope we  
> can make this work OOTB.
>
> Also, any server side fix I write will have an option to disable  
> this kind of meddling with data.
>
> -Mikeal
>
> On Jan 3, 2008, at January 3, 20089:01 PM, Matthew Eernisse wrote:
>
>> How are you gentlemen.
>>
>> I found the culprit, in the very last three lines of base.js:
>>
>> if (navigator && navigator.userAgent &&
>> !(parseInt((/Gecko\/([0-9]+)/.exec(navigator.userAgent)
>> || []).pop()) <= 20060508)) {
>>  document.domain='facebook.com';
>> }
>>
>> Probably doing it so it can see cookies set by pages from all the  
>> various subdomains. They're doing some kind of interesting user- 
>> agent sniffing in that conditional, weeding out Gecko-based  
>> browsers older than 2006-05-08. Not sure what the significance of  
>> that is.
>>
>> Naturally enough, if I reset the domain for the IDE to the same  
>> thing, I can load the IDE with no errors, and do recording/playback  
>> on the FB home page. I was resetting it in windmill.Start, right  
>> after the two windmill.service calls.
>>
>> This is going to be pretty annoying, because they're changing the  
>> domain *as* the JavaScript is loading and executing.
>>
>> Once they change the domain in the opener window out from under us,  
>> there's of course no way to get a handle on it with script to look  
>> up what it changed to. So I guess we need a way to pass a  
>> designated domain name from the backend to set the IDE window to  
>> before trying to grab the reference to the testWindow.
>>
>> It's kind of ugly, but anyone who wants to test their FB apps will  
>> need to do it.
>>
>>
>> Matthew
>>
>> _______________________________________________
>> Windmill-dev mailing list
>> Windmill-dev at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/windmill-dev
>
> _______________________________________________
> Windmill-dev mailing list
> Windmill-dev at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/windmill-dev