With the latest version of changeset http://svn.openlaszlo.org/openlaszlo/patches/raju-20110502-REe.tar LPP-9922,LPP-9923, and LPP-9917 should be fixed. I still have some extra debug output for testing, mainly in LzHTTPLoader.prototype.checkIfCORS, e.g. INFO: isHttps=false INFO: secure=false INFO: targedomain=localhost INFO: port=9000 INFO: iscors=true INFO: credentialled XHR
I'd be very thankful if someone could review these changes. Raju <corsCredDS><communication><cors>CORS worked!</cors><client-request><cookies><cookie>corscookie = CORS cookie is set at 5/3/11 8:44 PM</cookie><cookie>JSESSIONID = tykf7h09oexc1on2gk7bg0vl3</cookie></cookies><headers><header>Host: localhost:9000</header><header>Connection: keep-alive</header><header>Referer: http://localhost:8080/cors/test/data/dhtml-cross-origin-dataset.lzx?lzoptions=usemastersprite(false)%2Cruntime(mobile)%2Cproxied(false)</header><header>Content-Length: 23</header><header>Origin: http://localhost:8080</header><header>User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.57 Safari/534.24</header><header>Content-Type: application/x-www-form-urlencoded</header><header>Accept: */*</header><header>Accept-Encoding: gzip,deflate,sdch</header><header>Accept-Language: en-US,en;q=0.8</header><header>Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3</header></headers></client-request></communication></corsCredDS> On Mon, May 2, 2011 at 11:15 AM, Raju Bitter <[email protected]> wrote: > I've created a simple test application for the CORS functionality > using Maven and Jetty. The code can be found here: > https://github.com/raju-bitter/openlaszlo-cors-test > > I'll send in a changeset for review a bit later, which uses this web > application for testing. For CORS testing you need at least a server > running on an different port than LPS. Since Maven will download all > dependencies, it should be enough to get the source code or the > ZIP/Tar file and just do a > mvn jetty:run > > to have the test application running at http://localhost:9000/cors > > On Sat, Apr 30, 2011 at 7:23 PM, Raju Bitter > <[email protected]> wrote: >> For the SWF10 runtime, the value of is set inside >> >> LzHTTPLoader.as#loadXMLDoc >> var secure:Boolean = (url.indexOf("https:") == 0); >> >> >> On Sat, Apr 30, 2011 at 6:57 PM, Raju Bitter >> <[email protected]> wrote: >>> Henry, >>> >>> The "secure" property of the LzHTTPLoader is not set correctly for >>> dataset requests using https. I saw the comments you've added to I've >>> created a JIRA issue, and will see if I can fix that as par of the >>> CORS support feature: >>> http://jira.openlaszlo.org/jira/browse/LPP-9923 >>> >>> On Thu, Apr 28, 2011 at 7:00 PM, Raju Bitter >>> <[email protected]> wrote: >>>> Thanks, Henry. >>>> >>>> On Thu, Apr 28, 2011 at 6:42 PM, Henry Minsky <[email protected]> >>>> wrote: >>>>> I think it will not need anything to be touched in the compiler, just add >>>>> the attribute to the LzDataset class in the lfc, with proper js2doc >>>>> comment, >>>>> and it will get added to the schema. >>>>> >>>>> The compiler only treats top-level dataset as a special case when it >>>>> thinks >>>>> it is a constant (non-HTTP or constraint for src or type). If there is a >>>>> type='http' or a url in the >>>>> src, it compiles it with the node compiler, and will include all >>>>> attributes. >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Apr 28, 2011 at 12:23 PM, Raju Bitter >>>>> <[email protected]> wrote: >>>>>> >>>>>> > Datasets are special forms, so to implement this new attribute, you'd >>>>>> > have to muck with the dataset compiler. >>>>>> That doesn't sound like fun, how can I do that? >>>>>> >>>>>> On Thu, Apr 28, 2011 at 6:20 PM, P T Withington <[email protected]> wrote: >>>>>> > I guess add an attribute? Stylistically, our attributes are normally >>>>>> > all lower case, so maybe >>>>>> > >>>>>> > <attribute name="credentialled" type="boolean" /> >>>>>> > >>>>>> > Datasets are special forms, so to implement this new attribute, you'd >>>>>> > have to muck with the dataset compiler. >>>>>> > >>>>>> > On 2011-04-28, at 12:15, Raju Bitter wrote: >>>>>> > >>>>>> >> But do you have any comment on how to add the "withCredentials" >>>>>> >> setting to datasets? >>>>>> >> >>>>>> >> On Thu, Apr 28, 2011 at 6:03 PM, Raju Bitter >>>>>> >> <[email protected]> wrote: >>>>>> >>> The scenario I have is: I'm developing an OpenLaszlo app on >>>>>> >>> localhost:8080. I'm logging into the app, but the web service I'm >>>>>> >>> using is running on remote server connected to the Internet. When the >>>>>> >>> correct login credentials are sent to that server, the server >>>>>> >>> response >>>>>> >>> will contain a set-cookie header. Any following request to the remote >>>>>> >>> server relies on the presence of that cookie value - or I'll get a >>>>>> >>> 401 >>>>>> >>> not authorized response. >>>>>> >>> >>>>>> >>> The scenario you are describing with Paypal is based on iFrame >>>>>> >>> behavior: When you load content in an iFrame, Safari will not accept >>>>>> >>> any cookies from the webserver serving the iFrame HTML content until >>>>>> >>> the user interacts with that frame (clicks into that frame). >>>>>> >>> >>>>>> >>> For the CORS scenario I have, check this example: Click on the button >>>>>> >>> to set a cookie in your browser following an XHR request to >>>>>> >>> aruner.net >>>>>> >>> from arunranga.com. That works in Firefox and Chrome, but not in >>>>>> >>> Safari with the default settings >>>>>> >>> http://arunranga.com/examples/access-control/credentialedRequest.html >>>>>> >>> HTTP headers exchanged: >>>>>> >>> http://arunranga.com/examples/access-control/SimpleXSInvocation.txt >>>>>> >>> >>>>>> >>> >>>>>> >>> On Thu, Apr 28, 2011 at 3:16 PM, P T Withington <[email protected]> >>>>>> >>> wrote: >>>>>> >>>> If I am reading this right, Safari's policy is to not _accept_ >>>>>> >>>> cookies from a domain other than the one you are visiting. In the >>>>>> >>>> case of a >>>>>> >>>> credentialed request, the request is _sending_ a cookie to the >>>>>> >>>> foreign >>>>>> >>>> domain, which is not going to be affected by Safari's default >>>>>> >>>> policy[*]. >>>>>> >>>> When you make the XHR request and set 'withCredentials' any >>>>>> >>>> cookies the >>>>>> >>>> browser has for that domain will be sent with the request. If the >>>>>> >>>> foreign >>>>>> >>>> server accepts the request (and cookies) from your domain, it >>>>>> >>>> responds with >>>>>> >>>> Allow-Origin and Allow-Credentials set appropriately and you get >>>>>> >>>> the data. >>>>>> >>>> >>>>>> >>>> I think the scenario here is that you have previously logged in >>>>>> >>>> directly to the foreign site and this variation on the XHR request >>>>>> >>>> is >>>>>> >>>> allowing your (cross-origin) app to make requests including those >>>>>> >>>> credentials, while still letting the foreign server decide what >>>>>> >>>> (other) >>>>>> >>>> sites it will permit access for. >>>>>> >>>> >>>>>> >>>> --- >>>>>> >>>> [*] The purpose of Safari's default policy is to limit tracking by >>>>>> >>>> not _accepting_ 3rd-party cookies from embedded ads. But as you >>>>>> >>>> can see if >>>>>> >>>> you go to a site that accepts paypal, it still _sends_ 3rd-party >>>>>> >>>> cookies >>>>>> >>>> that it may have acquired with a direct connection, which is how the >>>>>> >>>> embedded paypal button knows who you are. >>>>>> >>>> >>>>>> >>>> On 2011-04-28, at 07:12, Raju Bitter wrote: >>>>>> >>>> >>>>>> >>>>> I would say that most scenarios where CORS is really useful are >>>>>> >>>>> 1) Accessing data on remote sites through XHR for mashups. >>>>>> >>>>> 2) Localhost / server backend test scenarios: Running a local >>>>>> >>>>> installation of OpenLaszlo for development, and accessing resources >>>>>> >>>>> on >>>>>> >>>>> a remote server backend. >>>>>> >>>>> >>>>>> >>>>> For 2), the Safari cookie settings can be changed by the developer, >>>>>> >>>>> for 1) that would only be necessary when you have a cross-domain >>>>>> >>>>> request with credentials. >>>>>> >>>>> >>>>>> >>>>> On Thu, Apr 28, 2011 at 1:05 PM, Raju Bitter >>>>>> >>>>> <[email protected]> wrote: >>>>>> >>>>>> That's a browser setting: Safari -> Preferences -> Security >>>>>> >>>>>> >>>>>> >>>>>> http://grack.com/blog/2010/01/06/3rd-party-cookies-dom-storage-and-privacy/ >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 28, 2011 at 12:56 PM, Henry Minsky >>>>>> >>>>>> <[email protected]> wrote: >>>>>> >>>>>>> One problem is, that >>>>>> >>>>>>>> >>>>>> >>>>>>>> Safari's default cookie settings are set to "Accept cookies: >>>>>> >>>>>>>> Only >>>>>> >>>>>>>> from >>>>>> >>>>>>>> sites I visit". That means, even with CORS/withCredentials >>>>>> >>>>>>>> support, >>>>>> >>>>>>>> without the user chaning the accept cookies settings to >>>>>> >>>>>>>> "always", >>>>>> >>>>>>>> the >>>>>> >>>>>>>> browser will not accept cookies for CORS requests. >>>>>> >>>>>>> >>>>>> >>>>>>> Is there any way to set that automatically from the LFC , or is >>>>>> >>>>>>> that >>>>>> >>>>>>> something the user >>>>>> >>>>>>> has to manually change in their browser settings? >>>>>> >>>>>>> >>>>>> >>>>>>> -- >>>>>> >>>>>>> Henry Minsky >>>>>> >>>>>>> Software Architect >>>>>> >>>>>>> [email protected] >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>> >>>>>> > >>>>>> > >>>>> >>>>> >>>>> >>>>> -- >>>>> Henry Minsky >>>>> Software Architect >>>>> [email protected] >>>>> >>>>> >>>>> >>>> >>> >> >
