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]
