Anyway to circumvent browser's crossdomain policy?

[gedion]

I am using epLite in my app via iframes. I'd like to be able to use some of the pad's javascript functions. But the mentioned policy is not allowing me to do so. Etherpad lite will be hosted in a different domain than my main app.

Any ideas?

[Pita]

Its possible to allow that, start reading here https://developer.mozilla.org/en/document.domain

[nsfmc]

if you control the server, you can also send back the Access-Control-Allow-Origin: * and Access-Control-Allow-Credentials: true headers to get past the crossdomain issues. You don't have to use * for the origin, obviously, you can whitelist a set of domains and it should have the same effect and usually works in most modern browsers.

More info here, but https://developer.mozilla.org/En/HTTP_access_control

[Pita]

It probably makes sense to set the Access-Control-Allow-Origin:* by default. Or is this a huge security issue?

[nsfmc]

i don't know what the security implications are (in particular, since etherpad has philosophically very few access control issues and also because i don't know much about how etherpad-lite deals with auth), but i would assume in most cases it's not particularly dangerous.

where i work, we decorate methods that we think should be cross-domain friendly, so we don't do it for all endpoints by default, just for ones which are harmless enough (i.e. most GETs are probably ok)

[jhollinger]

As you know, setting Access-Control-Allow-Origin:* for eplite on domain A means ajax from domain B can access it. However, group pads, private group pads, password-protected pads, http auth, the api key, etc. would still be enforced. Given the strong emphasis on embedability, IMHO this seems like a good idea, at least for the http api. Imagine a mashup web app using eplite via an ajax api client.

Some people, it seems, want their installations to be less accessible. The Access-Control-Allow-Origin value could be configurable. But the aforementioned security measures should be sufficient - even though the http connection would be allowed, eplite itself would block access.

My understanding is that Access-Control-Allow-* only effects ajax requests, not iframes or document.domain (correct me if I'm wrong). So these may be two distinct issues.

[gedion]

Yes I believe jhollinger is correct that there are two issues here. To overcome the Ajax request issue(to use the API methods for example), my partner created a proxy server. That is sufficient for us.

But now we are trying to make epLite and our app interact through plain client side javascript. For example. we have an image loader in our app. Once the image has been loaded, I'd like to pass the source to the pad with something like this.

frames['epLite'].pad.editbarClick('http:www.myserver.com/images/smile.png');

Pita's idea in which to try modifying(document.domain) only works locally.

[jhollinger]

I don't believe that kind of interaction is supposed to be possible. However, assuming you are in control of both your eplite instance and your other app, here are some ideas I've run across:

1. http://pipwerks.com/2008/11/30/iframes-and-cross-domain-security-part-2/
2. Serve your eplite from a suburl of the same domain as your app (e.g. yourapp.com/eplite). That way, I think you would be able to access it even from within an iframe. (I think the wiki has docs about configuring the required server-side url rewrites.)

[JohnMcLear]

Use reverse proxying.

See the wiki

-----Original Message----- From: gedion [mailto:reply@reply.github.com] Sent: 10 February 2012 16:01 To: John McLear Subject: [etherpad-lite] Anyway to circumvent browser's crossdomain policy? (#439)

I am using epLite in my app via iframes. I'd like to be able to use some of the pad's javascript functions. But the mentioned policy is not allowing me to do so. Etherpad lite will be hosted in a different domain than my main app.

Any ideas?

---

Reply to this email directly or view it on GitHub: https://github.com/Pita/etherpad-lite/issues/439 This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of the organisation from which this email originated. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. This email was sent by School Email - Safe Webmail and Hosted Email for Schools

[gedion]

jhollinger's link(http://pipwerks.com/2008/11/30/iframes-and-cross-domain-security-part-2/) led me to solve my problem.

In the link someone mentions this, which works for me. Thank you all for your effort.

Documents are allowed to change from their subdomain to main domain. ex. from yyy.zzz.com you could set your document domain to zzz.com. Now as both iframes have same domain, they can share/communicate easily.

[JohnMcLear]

Afaik that method allows for XSS on the server that is proxying. I could be wrong tho

-----Original Message----- From: gedion [mailto:reply@reply.github.com] Sent: 10 February 2012 22:35 To: John McLear Subject: Re: [etherpad-lite] Anyway to circumvent browser's crossdomain policy? (#439)

jhollinger's link(http://pipwerks.com/2008/11/30/iframes-and-cross-domain-security-part-2/) led me to solve my problem.

In the link someone mentions this, which works for me. Thank you all for your effort.

Documents are allowed to change from their subdomain to main domain. ex. from yyy.zzz.com you could set your document domain to zzz.com. Now as both iframes have same domain, they can share/communicate easily.

---

Reply to this email directly or view it on GitHub: https://github.com/Pita/etherpad-lite/issues/439#issuecomment-3915625 This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of the organisation from which this email originated. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. This email was sent by School Email - Safe Webmail and Hosted Email for Schools

[cweider]

@johnyma22, yes, it would expose the frame to other frames in a parent domain – that is probably safe, but it is something that an implementer would need to be cautious of. The best solution would really be to expose a cross-frame interface (probably with easyXDM) or to make the iframe unnecessary (but that requires sessions and tokens and lots of other things).

[JohnMcLear]

Chad, I'm curious, how is using a cross-frame interface the best way when compared to setting up reverse proxy? I'm completely ignorant to cross-frame interfaces..

I just deployed PrimaryWall for a client using the reverse proxy technique and found for me it worked well using a relative path on the domain so the call comes from failtoso.com but any request to failtoso.com/wall/ goes to wall.failtoso.com -- I'm sure you get how it works.. I don't have to provide any extra client payload which imho is what we all are striving towards?

Also it would be interesting to find out if we can leverage the API the functionality the OP desires.

-----Original Message----- From: Chad Weider [mailto:reply@reply.github.com] Sent: 10 February 2012 23:15 To: John McLear Subject: Re: [etherpad-lite] Anyway to circumvent browser's crossdomain policy? (#439)

@johnyma22, yes, it would expose the frame to other frames in a parent domain – that is probably safe, but it is something that an implementer would need to be cautious of. The best solution would really be to expose a cross-frame interface (probably with easyXDM) or to make the iframe unnecessary (but that requires sessions and tokens and lots of other things).

---

Reply to this email directly or view it on GitHub: https://github.com/Pita/etherpad-lite/issues/439#issuecomment-3916270 This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of the organisation from which this email originated. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. This email was sent by School Email - Safe Webmail and Hosted Email for Schools

[cweider]

Oh, proxying the server is perfectly fine. I’d just say that it’s more of a workaround – Etherpad is no longer running on a different domain at that point – than something that allows a page to integrate with Etherpad despite its being isolated on its own domain, but the later is a feature more than anything.

Using postMessage instead of adjusting document.domain is only better in that it allows a larger class of domains (like 'http://www.example.com', 'https://example.com', 'http://example.com:8080' (roughly)) to communicate with 'http://pad.example.com'.