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] >>>> >>>> >>>> >>> >> >
