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