On Sun, May 7, 2017 at 1:12 PM, Patrick McManus <[email protected]> wrote:
> an authenticated connection is the moral equivalent of having credentials > on every request on that conn.. so its non-sensical to have an anonymous > request on a authenticated connection. (so yes, if its anonymous it would > need to be on a non authenticated connection.. I'm not sure fetch needs to > say that - its sufficient to define an anonymous request as lacking > credentials I would think) > > but that doesn't mean we need to ban the mingling of authenticated and non > authenticated on the same connection when we aren't using connection based > auth (which is approximately all the time outside some enterprise cases). Hmm... What about when you have post-handshake auth that retroactively blesses requests that should have been anonymous? -Ekr > > > > On Sun, May 7, 2017 at 3:33 PM, Anne van Kesteren <[email protected]> > wrote: > > > On Sunday, May 7, 2017 at 8:54:54 PM UTC+2, Patrick McManus wrote: > > > Its a good point, but the hash also has some credential info in it for > > the > > > case of ntlm cause you also don't want to mix user a and user b when > you > > > are doing conn based auth. Hopefully that wouldn't need to surface up > at > > > whatwg/w3c level. > > > > So I don't know how these connection-level authentication mechanisms work > > in detail, but they came up in the issue as well, and might well have > been > > the motivator for the credentials flag. If we don't want those to be used > > on connections that also carry requests without credentials, how do we go > > about that? > > > > Can these authentication mechanisms be negotiated after the connection is > > opened? > > > yes.. typically triggered by a subset of resources on the server > > > > Can the client easily refuse? > > > same process as other http based auth. I'm not sure I'd call that 'easy' - > but there ya go > > > > Can the server assert it won't ever start such a negotiation? > > > > no.. (at least not that I know of) > > > > (Having statistics on how often these mechanisms are used would also be > > interesting, though I suspect we can't do much about it given intranet > > deployments and such.) > > > > > very enterprisey. Most of it is actually used to authenticate to proxies, > which isn't a consideration here, but there are a few cases of endpoints > doing windows auth. > > > > > FWIW, I suspect Fetch will need to keep some handle on how to allocate > > connections, just to deal with WebSocket, error handling, the upcoming > > token binding integration, and features like preconnect. > > _______________________________________________ > > dev-tech-network mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-tech-network > > > > > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
