On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen < [email protected]> wrote:
> > [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? > Given that many services do (mistakenly or not) use Origin and/or Referer to make security choices, all these headers along with the cookie header ought to be considered "credentials". Caja itself is a pure html, css and js rewriter and isn't always in a position to suppress headers without either awesome browser APIs like the one under discussion or with the help of a header stripping proxy. > * 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.. > +1. I do not have a strong opinion on what the API ought to be -- just that the feature is a necessary one. That said using two boolean flags (withCredentials and anon) to represent what is at least currently a tri-state value does (as you point out) run the risk of confusing developers who set the flags to conflicting values. > > -- > Hallvord R. M. Steen > Core tester, Opera Software > > > > > >
