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

Reply via email to