1) Origin header Will be sent by browser when making a request to domain different from the one the page was served from.
2) Magic yes, exactly. On Sat, Apr 9, 2011 at 7:01 PM, Henry Minsky <[email protected]> wrote: > So I'm not quite clear on the usage here; is the Origin header appended > automatically > by the browser or do we need to add it when we make a request (from a laszlo > app)? > Is there anything special we need to do on the laszlo DHTML client app side? > > Will this just magically work now with an existing SOLO app if you just > config the server > to send back the Access-control-origin response header? > > On Sat, Apr 9, 2011 at 12:04 PM, Raju Bitter > <[email protected]> wrote: >> >> Yes, it works. For a cross-domain request, the browser sends a >> >> Origin: <SomeURL>, e.g. Origin: http://localhost:8080 >> >> header, and the server would respond with an >> >> Access-Control-Allow-Origin: http://localhost:8080 >> >> That's all, and it's so easy to configure for Apache, and other solutions: >> http://enable-cors.org/ >> >> You should really drop support for the proxied mode. The OL proxy >> server made a lot of sense back in 2005/2006, but now - with much >> better media support in Flash and cross-origin resource support in >> Firefox, Safari, Chrome, Webkit, ... - you don't need proxied mode. >> There's always so much confusion around the proxied/non-proxied apps. >> And at the same Laszlo recommends to not use the OL server in >> production mode. That means, we can only use the proxy server when >> testing on development machines. I've had enough situations where I >> had different behavior in apps in SOLO mode compared to proxied mode. >> >> On Mon, Sep 20, 2010 at 6:40 PM, Henry Minsky <[email protected]> >> wrote: >> > I think it will work if the server responds with the right headers to >> > give >> > permission. It looks like more of a pain in the >> > ass than the Flash security protocol, where you only need to put a >> > crossdomain.xml file someplace on the server. With the Cross-Origin >> > Resource Sharing protocol you have to deal with a new request type, >> > "OPTIONS", and supply extra headers in the response. Seems kind of >> > kludgy >> > compared to the Flash solution. >> > >> > >> > On Mon, Sep 20, 2010 at 12:29 PM, P T Withington <[email protected]> wrote: >> >> >> >> So, this would work automagically if the server said it was ok? Or do >> >> we >> >> need to do something more on the client side to take advantage of this? >> >> >> >> On 2010-09-19, at 09:27, Henry Minsky wrote: >> >> >> >> > I was trying to figure out why I was seeing POST requests converted >> >> > to >> >> > OPTIONS requests in Firefox and Safari when >> >> > the XMLHTTPRequest was being sent to a "foreign" domain (i.e., a >> >> > security >> >> > violation) >> >> > >> >> > I searched for "OPTIONS" and "POST" and "Firefox" and found this. So >> >> > it >> >> > looks like there's a way to configure a server >> >> > to permit cross-domain access (like Flash's crossdomain.xml), to >> >> > compliant >> >> > browsers (which it appears Safari and >> >> > Firefox are, dunno about Opera or IE). >> >> > >> >> > >> >> > https://developer.mozilla.org/en/http_access_control >> >> > >> >> > Overview >> >> > >> >> > The Cross-Origin Resource Sharing standard works by adding new HTTP >> >> > headers >> >> > that allow servers to describe the set of origins that are permitted >> >> > to >> >> > read >> >> > that information using a web browser. Firefox supports these headers >> >> > and >> >> > enforces the restrictions they establish. Additionally, for HTTP >> >> > request >> >> > methods that can cause side-effects on user data (in particular, for >> >> > HTTP methods other than GET, or for POST usage with certain MIME >> >> > types), >> >> > the >> >> > specification mandates that browsers "preflight" the request, >> >> > soliciting >> >> > supported methods from the server with an HTTP OPTIONS request >> >> > header, >> >> > and >> >> > then, upon "approval" from the server, sending the actual request >> >> > with >> >> > the >> >> > actual HTTP request method. Servers can also notify clients whether >> >> > "credentials" (including Cookies and HTTP Authentication data) should >> >> > be >> >> > sent with requests. >> >> > >> >> > Subsequent sections discuss scenarios, as well as a breakdown of the >> >> > HTTP >> >> > headers used. >> >> > >> >> > >> >> > -- >> >> > Henry Minsky >> >> > Software Architect >> >> > [email protected] >> >> >> > >> > >> > >> > -- >> > Henry Minsky >> > Software Architect >> > [email protected] >> > >> > >> > > > > > -- > Henry Minsky > Software Architect > [email protected] > > >
