Den 1. juni 2013 kl. 10:14 skrev Anne van Kesteren ann...@annevk.nl:
On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
So creating a new tri-state property in the XHR spec should also simplify
integration with the Fetch spec.
Agreed. The question
On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
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 doing here is
On Thu, May 30, 2013 at 12:16 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
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 understand what
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 replied:
I'm opposed
On Wed, May 29, 2013 at 1:19 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
On Tue, May 28, 2013 at 7:07 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
[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
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 tristate
flag
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 you
: Hallvord Reiar Michaelsen Steen hallv...@opera.com
Date: Tue, May 21, 2013 at 1:41 PM
Subject: Re: Re: [XHR] anonymous flag
To: Charles McCathie Nevile cha...@yandex-team.ru, public-webapps
public-webapps@w3.org, Jonas Sicking jo...@sicking.cc,
tyler.cl...@gmail.com, m...@apple.com, dpra
-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 hallv...@opera.com
Date: Tue, May 21, 2013 at 1:41 PM
Subject: Re: Re: [XHR] anonymous flag
To: Charles McCathie Nevile cha
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
On Sat, May 18, 2013 at 8:41 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
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-origin
On Sat, May 18, 2013 at 1:43 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
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
called, and if
On Thu, May 16, 2013 at 10:35 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
Hi Anne,
chair hat on
Please stick to the technical discussion without making assertions about
people's motives or actions for which you don't have concrete evidence.
chair hat off
On Fri, 17 May 2013 13:53:08 +0400, Anne van Kesteren ann...@annevk.nl
wrote:
On Thu, May 16, 2013 at
On Fri, May 17, 2013 at 11:24 AM, Charles McCathie Nevile
cha...@yandex-team.ru 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
On Tue, May 14, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
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
to be
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
On Mon, May 13, 2013 at 10:57 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
On Mon, May 13, 2013 at 2:28 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Mon, May 13, 2013 at 10:57 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Does anyone have real, non-contrived use cases for the anonymous flag?
The basic idea was preventing confused deputy attacks
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', '/')
On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl:
On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com 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
On Wed, May 8, 2013 at 1:07 PM, Hallvord Reiar Michaelsen Steen
hallv...@opera.com wrote:
Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl:
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
30 matches
Mail list logo
