I agree.  It is the cross-domain _login_ that is prevented by Safari's default 
behavior, not the credentialed cross-domain XHR request.

The solution would seem to be for the login to verify that the cookies were 
accepted, and if not, you have two choices:

  1) Take the user to the remote server and have them log in there

  2) Ask the user to update their security preferences to permit the remote 
server to store cookies.

(As a side point, I think you only have to knock IE's 'safety' knob up one 
notch to have the same behavior as Safari's default.)

On 2011-04-28, at 12:03, Raju Bitter 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]
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> 
>> 
> 


Reply via email to