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 > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
