[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