Re: Re: Re: [XHR] anonymous flag

[Minor edit: fixed your true/false typo]
 
> * If we had a better way of controlling the option to deny sending credentials
> in a way that kept compatibility with legacy webpages (eg. a tristate flag like
> you suggest in [6]), I agree it would be better than to have two different flags
> which may be confusing to developers and which may disagree with each other. 

I agree (naturally) - now, just to be very clear: your needs are met if the API lets you control *credentials* - right? Does Caja currently attempt to suppress Referer: and/or Origin: headers? Do you consider it a requirement to be able to do so?

> * In Google AppScript and on Google Sites, we execute a code on the same domain
> sandboxed using Caja.  In this case, Caja  relies on withCredentials defaulting to
> false and prevents sandboxed guest code from setting it to true.  In this way,
> we're able to work around the difficulties posed by the API that you point out.
> We are nevertheless forced to either proxy or deny requests to the same origin since
> the CORS anon flag appears not be reliably supported on all browsers (and 
> withCredentials does not apply to same-origin).  


It sounds like making withCredentials a tri-state thing (i.e. with values 'samedomain', 'always', 'never') would work better for you :) - depending of course on how you respond to the above question, that is..

-- 
Hallvord R. M. Steen
Core tester, Opera Software

Received on Thursday, 23 May 2013 08:56:43 UTC