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