198117 - AxSecurityPolicy does not allow calling methods on Objects

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: ActiveX Wrapper, defect)

Description

[Ashish Bhatt]

Tested with 20030317

Cannot call methods on objects. Throws up javascript error saying object.method
is not a function.

Looks like a permission issue. I had this problem earlier when I had to edit the
nsAxSecurityPolicy.js file to allow all active-x objects.

Happens only  build after 20030211.

Comment 1

[Ashish Bhatt]

Attachment: Testcase for object.method

Comment 2

[Adam Lock]

Hosting appears to be failing because the call to
nsScriptSecurityManager::CheckXPCPermissions during control creation is
returning NS_ERROR_DOM_XPCONNECT_ACCESS_DENIED which filters up and the plugin
creates nothing.

Either it's getting the wrong security manager or something has recently changed
which is making it fail.

Mini stack trace of the problem

nsScriptSecurityManager::CheckXPCPermissions(nsISupports * 0x00000000, const
char * 0x00000000) line 2504
nsScriptSecurityManager::CanCreateInstance(nsScriptSecurityManager * const
0x00b2c590, JSContext * 0x04b3f040, const nsID & {...}) line 2441 + 12 bytes
nsDispatchSupport::IsClassSafeToHost(nsDispatchSupport * const 0x04a228f8,
JSContext * 0x04b3f040, const nsID & {...}, int 0x00000001, int * 0x0012c4ac,
int * 0x0012c4a4) line 207 + 34 bytes
WillHandleCLSID(const _GUID & {CLSID_Shockwave Flash Object}, PluginInstanceData
* 0x04bbbce8) line 497
CreateControl(const _GUID & {CLSID_Shockwave Flash Object}, PluginInstanceData *
0x04bbbce8, PropertyList & {...}, const unsigned short * 0x00000000) line 546 +
13 bytes
NewControl(const char * 0x04bbbc90, PluginInstanceData * 0x04bbbce8, unsigned
short 0x0001, short 0x0005, char * * 0x04b3ea20, char * * 0x04bbbe08) line 912 +
21 bytes
NPP_New(char * 0x04bbbc90, _NPP * 0x04b0f2e0, unsigned short 0x0001, short
0x0005, char * * 0x04b3ea20, char * * 0x04bbbe08, _NPSavedData * 0x00000000)
line 962 + 31 bytes

Comment 3

[David Bradley]

Is the control listed in the prefs, or is the blacklist mode on?

Comment 4

[Ashish Bhatt]

no it is not listed in prefs, no blacklist or whitelist entry

Comment 5

[David Bradley]

Currently the default behavior is whitelist mode, so it's going to reject any
control that's not listed in the prefs file.

Comment 6

[Adam Lock]

Caps doesn't currently appear to compile in the check that reads the whitelist /
blacklist setting so it takes the default. I think the makefile needs a patch to
define XPC_IDISPATCH_SUPPORT which I'll supply shortly.

Comment 7

[Adam Lock]

Attachment: Patch

Patch adds the -DXPC_IDISPATC_SUPPORT that enables blacklist mode in caps.
Otherwise caps stays in whitelist mode and all controls must be explicitly
enabled.

With the patch it is possible to create a file, e.g. named activex.js in
defaults\prefs with this line and have all controls hosted by default:

pref("security.classID.allowByDefault", true);

Looking for quick reviews on this

Comment 8

[Adam Lock]

Comment on attachment 117749 [details] [diff] [review]
Patch

David, Alec can I have r/sr on this simple patch which ensures caps can be
flipped into blacklist mode? Thanks

Comment 9

[David Bradley]

Comment on attachment 117749 [details] [diff] [review]
Patch

r=dbradley

Comment 10

[Alec Flett]

Comment on attachment 117749 [details] [diff] [review]
Patch

sr=alecf

Comment 11

[Adam Lock]

Fix is checked in.

Ashish, you'll have to add a pref to enable blacklist mode as described
previously unless you wish to explicitly define the controls to allow. If you
prefer you can copy the activex.js which I'm doing for bug 197084 into
bin/default/prefs for the same effect.

I'll attach a copy in case you want to use it pending checkin for that bug.

Comment 12

[Adam Lock]

Attachment: activex.js file

Copy this to defaults\pref to enable blacklist mode

Comment 13

[Ashish Bhatt]

Verified on 2003-03-21 build