Den 1. juni 2013 kl. 10:14 skrev Anne van Kesteren :
> On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
> wrote:
>> So creating a new tri-state property in the XHR spec should also simplify
>> integration with the Fetch spec.
>
> Agreed. The question is, if we take it as a given
On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
wrote:
> So creating a new tri-state property in the XHR spec should also simplify
> integration with the Fetch spec.
Agreed. The question is, if we take it as a given that we're going to
get a new API (that uses futures, deals wit
> > OK then - Anne and others, what do you think about creating a new tri-state
> > xhr.credentialsPolicy property and discouraging usage of
> > xhr.withCredentials ?
>
> I think I'd prefer removing the constructor flag and leaving new
> features to the API for Fetch.
Sorry, I don't understan
On Thu, May 30, 2013 at 12:16 PM, Hallvord Reiar Michaelsen Steen
wrote:
> OK then - Anne and others, what do you think about creating a new tri-state
> xhr.credentialsPolicy property and discouraging usage of xhr.withCredentials ?
I think I'd prefer removing the constructor flag and leaving new
> > Now, if you are still not convinced this is a good change my plan B is to
> > suggest a "credentialsPolicy" property so we'll find an agreement anyway.
> > :-) But maybe explaining that no quirky getter magic is required helps you
> > see the proposal in a new light?
>
> Whatever we're doi
On Wed, May 29, 2013 at 1:19 PM, Hallvord Reiar Michaelsen Steen
wrote:
> I proposed that we
>>> modify withCredentials to take three values: "samedomain" (default),
>>> "always" and "never". For backwards compatibility with earlier versions of
>>> the spec, setting withCredentials=true maps to
I proposed that we
>> modify withCredentials to take three values: "samedomain" (default),
>> "always" and "never". For backwards compatibility with earlier versions of
>> the spec, setting withCredentials=true maps to "always" and
>> withCredentials=false maps to "samedomain".
But Jonas repli
On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen
wrote:
> I wrote:
>
>> I would like to see some real code evidence that omitting Origin:
>> and Referer: is necessary too. In theory sites might use them as
>> "credentials" as you say, but in practise I don't see how that can
>> wor
I wrote:
> I would like to see some real code evidence that omitting Origin:
> and Referer: is necessary too. In theory sites might use them as
> "credentials" as you say, but in practise I don't see how that can
> work and be safe on the web.
>
> If we ship XHR with an "anonymous" flag removi
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen <
hallv...@opera.com> wrote:
> 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".
Can
On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen <
hallv...@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 tristat
[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
> w
features of CORS.
>> Is that true? If not, I'd like to see how close to that we can come.
>>
>>
>> -- Forwarded message --
>> From: Hallvord Reiar Michaelsen Steen
>> Date: Tue, May 21, 2013 at 1:41 PM
>> Subject: Re: Re: [XHR] anonymous flag
>>
d to use the UMP-enabling features of CORS.
> Is that true? If not, I'd like to see how close to that we can come.
>
>
> -- Forwarded message --
> From: Hallvord Reiar Michaelsen Steen
> Date: Tue, May 21, 2013 at 1:41 PM
> Subject: Re: Re: [XHR] anonymous
Anne wrote:
> I don't really feel it's responsible to remove this feature at this
> point without anyone involved in the original discussion speaking up.
Hi all,
you were involved in a discussion [1] regarding UMP and CORS back in 2010. I
know, it's a while ago, and apparently you had already be
> >> Making a boolean a tri-state with a
> >> default depending on an external variable is also super confusing.
> >
> > To whom?
> It seems confusing to anyone who reads the value.
Good point.
> What would it return
> in the various situations? I.e. before and after .open() has been
> call
On Sat, May 18, 2013 at 1:43 PM, Hallvord Reiar Michaelsen Steen
wrote:
>
>> > BTW - have you considered allowing setting withCredentials to "false" for
>> > same-origin resources?
>>
>
>> I suspect that would break sites.
>
>
> Possibly, but I find it unlikely - if it's set, it's most likely usu
> > BTW - have you considered allowing setting withCredentials to "false" for
> > same-origin resources?
>
> I suspect that would break sites.
Possibly, but I find it unlikely - if it's set, it's most likely usually set to
"true", not "false", and it's also most likely rarely set for same-or
On Sat, May 18, 2013 at 8:41 AM, Hallvord Reiar Michaelsen Steen
wrote:
> BTW - have you considered allowing setting withCredentials to "false" for
> same-origin resources?
I suspect that would break sites. Making a boolean a tri-state with a
default depending on an external variable is also sup
BTW - have you considered allowing setting withCredentials to "false" for
same-origin resources?
As-is, the author may not expect what happens if she sets withCredentials to
false, makes a cross-origin request, and the remote server redirects to a
same-origin URL. Now cookies will be sent to th
Den 17. mai 2013 kl. 11:53 skrev Anne van Kesteren :
> On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen
> wrote:
>> Anonymous mode still seems like useless complexity to me, so I'm still in
>> favour of dropping it.
>
> Right. I don't really get the feeling you're considering t
On Fri, May 17, 2013 at 11:24 AM, Charles McCathie Nevile
wrote:
> With respect to your use case for keeping anonymous I agree with Hallvord. I
> cannot think of a real use case for a browser-like thing that accepts
> arbitrary URLs. Could you please provide some more explanation of the real
> sce
Hi Anne,
Please stick to the technical discussion without making assertions about
people's motives or actions for which you don't have concrete evidence.
On Fri, 17 May 2013 13:53:08 +0400, Anne van Kesteren
wrote:
On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen
wro
On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen
wrote:
> Anonymous mode still seems like useless complexity to me, so I'm still in
> favour of dropping it.
Right. I don't really get the feeling you're considering the arguments
carefully and since nobody else seems to be partici
Den 16. mai 2013 kl. 18:45 skrev Anne van Kesteren :
> On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen
> wrote:
>> Say, for example, OpenID is a setup where the user might provide an
>> "untrusted" URL to a third-party web site ("Here's the service that can
>> authenticate me"
On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen
wrote:
> Say, for example, OpenID is a setup where the user might provide an
> "untrusted" URL to a third-party web site ("Here's the service that can
> authenticate me"), and XHR might be involved - but the Open ID *provider*
>
>>> Does anyone have real, non-contrived use cases for the anonymous flag?
>> The basic idea was preventing confused deputy attacks by not exposing
>> any information that could be used as such. So no credentials and no
>> data about where the request originated from, forcing the architecture
>
On Mon, May 13, 2013 at 2:28 PM, Anne van Kesteren wrote:
> On Mon, May 13, 2013 at 10:57 AM, Hallvord Reiar Michaelsen Steen
> wrote:
>> Does anyone have real, non-contrived use cases for the anonymous flag?
>
> The basic idea was preventing confused deputy attacks by not exposing
> any informat
On Mon, May 13, 2013 at 10:57 AM, Hallvord Reiar Michaelsen Steen
wrote:
> Does anyone have real, non-contrived use cases for the anonymous flag?
The basic idea was preventing confused deputy attacks by not exposing
any information that could be used as such. So no credentials and no
data about w
>>> Yes. It was added to address: http://www.w3.org/TR/UMP/
> We could revisit
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg171
> I suppose. Apparently at least Jonas changed his mind since then.
I didn't know the UMP spec. Reading it, it seems to me that the fund
On Wed, May 8, 2013 at 1:07 PM, Hallvord Reiar Michaelsen Steen
wrote:
> Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren :
>> Yes. It was added to address: http://www.w3.org/TR/UMP/
>
> I'm not sure what use cases having this feature in XHR solves.. So I would
> support removing it, unless we c
Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren :
> On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
> wrote:
>> If create an anonymous XHR request, rig it to GET a same-origin resource and
>> set a custom header, it will trigger a preflight and the same-origin
>> resource will
On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
wrote:
> If create an anonymous XHR request, rig it to GET a same-origin resource and
> set a custom header, it will trigger a preflight and the same-origin resource
> will have to opt in to receiving that custom header? Expected?
If create an anonymous XHR request, rig it to GET a same-origin resource and
set a custom header, it will trigger a preflight and the same-origin resource
will have to opt in to receiving that custom header? Expected?
var xhr=new XMLHttpRequest({anonymous:true})
xhr.open('GET', '/')
xhr.setReq
34 matches
Mail list logo
