I tried to get some folks internally to look at this, and so far nobody has said that they oppose landing the changes as is very strongly so unless there is no strong objections, I am going to ask Michael to submit his work for landing tomorrow.
Cheers, Ehsan On Wed, Jul 1, 2015 at 2:54 AM, Michael Layzell <[email protected]> wrote: > The patches I am working on already use Bobby Holley's OriginAttributes, > in fact we use the origin attribute on the nsIPrincipal, and only expose an > nsIPrincipal from the API. > > Internally, we use the origin attribute for serialization, but to external > consumers of the API, all that is available are APIs for adding and > removing permissions VIA nsIPrincipal, and some convenience methods which > exist for legacy reasons which allow you to add/remove permissions via > nsIURIs, creating NoAppCodebasePrincipals for them. You are right, that if > we decide that double keying is something we want, that it would be > possible to add it to the permission manager by simply modifying > nsIPrincipal's OriginAttributes. > > In terms of a mechanism for DENY being treated differently, it would be > possible (albeit very hacky) to always insert DENY entries for URIs with a > host property at http://HOST, and then, during the lookup, also check > http://HOST, and if it is DENY, expose a DENY for the other origin. I > don't really like this solution, as it creates lots of edge cases and other > complications which I'm not sure if we want to expose to API consumers, as > well as making the semantics of permissions diverge from nsIPrincipals, > (the coherence of the new semantics with nsIPrincipal is something I quite > like). > > On Tue, Jun 30, 2015 at 8:53 PM, Jonas Sicking <[email protected]> wrote: > >> On Tue, Jun 30, 2015 at 3:55 PM, Martin Thomson <[email protected]> wrote: >> > I wonder, has the subject of double-keying been raised in this >> > context? It comes up frequently in this context. And when I say >> > double-keying, I mean forming a key from the tuple of the requesting >> > principal and the top level browsing context principal (though origin >> > may suffice). >> > >> > If there are disruptive changes afoot, then segregating based on what >> > is shown to the user might be sensible. >> >> Bobby Holley has added infrastructure on nsIPrincipal called >> "OriginAttributes" which is intended to be an extension hook to allow >> things like double keying. As long as we use the 'origin' attribute on >> nsIPrincipal, and make sure that all callers pass in an nsIPrincipal >> rather than an nsIURI, then we should be able to relatively easy add >> double keying in the future. >> >> / Jonas >> > > -- Ehsan _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
