* Jonas Sicking wrote:
I'm not quite following what you are asking here. My proposal is about
giving a site the ability to enable two modes of Access-Control:
1. Allow a third-party site to read the data on this resource, and/or
perform unsafe methods in HTTP requests to this resource. When
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
I'm not quite following what you are asking here. My proposal is about
giving a site the ability to enable two modes of Access-Control:
1. Allow a third-party site to read the data on this resource, and/or
perform unsafe methods in HTTP
Bjoern Hoehrmann wrote:
* Jonas Sicking wrote:
First off, as before, when I talk about cookies in this mail I really
mean cookies + digest auth headers + any other headers that carry the
users credentials to a site.
I don't quite see why you would mix these. Is there anywhere where I can
* Jonas Sicking wrote:
First off, as before, when I talk about cookies in this mail I really
mean cookies + digest auth headers + any other headers that carry the
users credentials to a site.
I don't quite see why you would mix these. Is there anywhere where I can
read up on the use cases for an
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
That is, your solution only works so long as the site doesn't ever opt in to
cookies. Which seems uncommon.
This is not true. You can opt in to cookies on just a subset of the URIs
where you opt in to Access-Control with my
Ian Hickson wrote:
On Fri, 20 Jun 2008, Jonas Sicking wrote:
Under the current spec the operator must check each individual PHP
script in the part of the site that is shared to make sure that none of
them use $_SESSION, $_COOKIE, $HTTP_SESSION_VARS, $_ENV['HTTP_COOKIE'],
On Thu, 19 Jun 2008 11:42:57 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
This has one side-effect, which is that it doesn't work well with XBL
or VBWG in environments where the XBL file (or VXML file) is
customised to the user but accessed cross-site.
Maciej Stachowiak wrote:
On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote:
I must say though, this is starting to sound complex and I am not
totally convinced of the need to make servers opt in to getting
cookies. Is it really a likely mistake that someone would take
affirmative steps
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
And it's useful for pages that contain private information only when
cookies are sent, but when no cookies are sent they only provide public
information. I've given two examples of this in other threads:
1. A news site serving
Maciej Stachowiak wrote:
On Jun 14, 2008, at 4:23 AM, Jonas Sicking wrote:
...snip...
I mean, I guess
it's possible people will do this, but people could add
Access-Control-Allow-Credentials site-wide too. And if we add
Access-Control-Allow-Credentials-I-Really-Mean-It,
On Thu, 19 Jun 2008, Jonas Sicking wrote:
This only helps with servers that have same-domain pages that accept
cookies, but have no cross-domain pages that accept cookies, ever
(since if any of the cross-domain pages accept cookies, then our
initial assumption -- that the site
On Jun 19, 2008, at 1:48 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
After reviewing your comments, I am much more inclined to favor
Microsoft's proposal on this: rename the relevant headers. I think
you argued that this doesn't scale, but I think only two headers
have to be
Maciej Stachowiak wrote:
On Jun 19, 2008, at 1:48 PM, Jonas Sicking wrote:
Maciej Stachowiak wrote:
After reviewing your comments, I am much more inclined to favor
Microsoft's proposal on this: rename the relevant headers. I think
you argued that this doesn't scale, but I think only two
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
This only helps with servers that have same-domain pages that accept
cookies, but have no cross-domain pages that accept cookies, ever
(since if any of the cross-domain pages accept cookies, then our
initial assumption -- that the
On Thu, 19 Jun 2008, Jonas Sicking wrote:
The site is as always responsible for asking the user before allowing
third-party access to private data, and yes, if they fail to do so
properly they will be vulnerable.
So I guess I don't really understand what your proposal solves, then. It
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
The site is as always responsible for asking the user before allowing
third-party access to private data, and yes, if they fail to do so
properly they will be vulnerable.
So I guess I don't really understand what your proposal
Ian Hickson wrote:
On Thu, 19 Jun 2008, Jonas Sicking wrote:
So I guess I don't really understand what your proposal solves, then.
It seems like a lot of complexity for only a very minimal gain in only
one very specific scenario (the site doesn't ever return cookie-based
data cross-site).
On Sat, 14 Jun 2008 10:38:44 +0200, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
The downsides of inventing a URI scheme include:
1) URIs using this scheme will not parse into components properly (the
feed: scheme has this problem)
2) The scheme really should be registered through IANA,
18 matches
Mail list logo
