On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen <
hallvord@opera.com> 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
>
>
>
>
>
>