Closed
Bug 369239
Opened 18 years ago
Closed 13 years ago
Imagelib APIs do not give access to the channels being used
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bzbarsky, Unassigned)
References
Details
In particular, it is not possible to either set or get the owner of the channel for an image request. This means that it's not really possible to have javascript: URIs execute in a reasonable way for images, if we decide we want to do so. It also means that it's impossible to track trust labels through image loads.
Flags: blocking1.9?
Comment 1•18 years ago
|
||
given the title of this bug and the fact that imagelib is designed to not give access to the channel I'd say WONTFIX, but we may want to expose some of the things you ask for. We've talked about other ways to do security stuff in numerous other bugs so we could dup this...
![]() |
Reporter | |
Comment 2•18 years ago
|
||
I need the following things, more or less: 1) The ability to specify a particular originating principal for an image load. Image loads with different originating principals should probably not be coalesced (at the moment they can be, at least once we start tracking originating principals better). The principal would be set on the channel under certain conditions (yay frozen necko APIs). 2) The ability to set certain parameters on the channel -- see bug 369244. At least if we ever want to execute <img src="javascript:....">. I question whether we do, actually. I do realize the design of imagelib is to not give access to the channel, and I considered doing bug 369244 by flagging URIs instead, but that involves throwing URI cloning all over the place and is very very error-prone. If you expose a way to accomplish #1 and #2 above that doesn't involve handing back the channel, that's fine by me. ;) I'm also fine with dupping if you transfer the blocking request and the dependency.
![]() |
Reporter | |
Comment 3•18 years ago
|
||
Of course another option is to give up on all this for Mozilla 1.x, and redesign Necko to be more security-aware for Mozilla 2....
Updated•18 years ago
|
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
![]() |
Reporter | |
Comment 4•18 years ago
|
||
Filed bug 377092 on another approach that I'll take for 1.9.
Updated•17 years ago
|
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Comment 5•13 years ago
|
||
Boris, is this still needed?
![]() |
Reporter | |
Comment 6•13 years ago
|
||
Not as long as we're willing to add arguments to loadImage as needed, as we've done recently. This bug was filed back when imagelib API changes were ... resisted.
Comment 7•13 years ago
|
||
OK, then I'm marking this WONTFIX :).
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•