Sorry, some extra debugger output was attached at the end of my last mail.
On Tue, May 3, 2011 at 8:58 PM, Raju Bitter
<[email protected]> wrote:
> 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]
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
