11145 - Creator information: in URIs or channels?

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Norris Boyd]

In 4.x the URL_Struct had two members associated with security: "referer" (sic)
and "origin_url", used to original referrer of javascript: URL.

For Mozilla I'd like to have GetCreator and SetCreator methods either on the
nsIURI interface or on some interface we could QI various URL objects to. This
information would be used to track the creator of an URL for two purposes.
First, for javascript: URLs we need to track the creator in order to execute the
script under the appropriate principals. Also, I'd like to track chrome: URLs as
they are transformed into other URLs and accord them special privileges.

However it is implemented we need to be very careful that URLs created by
JavaScript scripts from the web cannot create chrome URLs and that origins of
javascript: URLs are tracked carefully.

Comment 1

[Warren Harris]

I'm going to look at this shortly, but I'm setting the target milestone to m10
because we need to get things that were working before working again first.

Comment 2

[Warren Harris]

Can you deal with a Get/SetCreator on nsIChannel? That seems like the right
place for the functionality.

Comment 3

[Norris Boyd]

Vidur, Joki, we currently derive the security information from the window by
calling GetDocumentURL on a nsIDocument. I notice that StartDocumentLoad is
called with an nsIChannel. Would it work to have a GetDocumentChannel method on
nsIDocument?

Alternatively, warren, could we define a new interface that defines a creator
getter and setter, and then have some concrete class implementing nsIURI that we
could QI to get the creator? Most objects implementing nsIURI wouldn't need to
support these methods then.

Comment 4

[Norris Boyd]

Over the weekend I added an nsIPrincipal to nsIChannel. So far it appears to be
meeting my needs, so closing this bug.

Comment 5

[Paul MacQuiddy]

marking verified since reporter resolved it

Comment 6

[Warren Harris]

Norris,

I was going to make this an nsISupports so that there wasn't a dependency from
necko to caps.  Reopening.

Warren

Comment 7

[leger]

Clearing Fixed resolution due to reopen.

Comment 8

[Warren Harris]

I removed all references to nsIPrincipal from necko in favor of a generic
attribute nsISupports Owner.

Comment 9

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.