0

2つのプラグインタイプを含むNPAPIプラグインを作成しています。

  • カメラからビデオをキャプチャするために使用されるx-capture
  • x -captureオブジェクトによってキャプチャされた画像を表示するために使用されるx-display

プラグインを使用する次のHTML/JavaScriptコードがあります。

<html>
  <embed id="display" type="application/x-display" width=640 height=480 /></td>
  <embed id="capture" type="application/x-capture" width=0 height=0 /><br> <!-- windowless plugin -->

  <script>
    var capture = document.getElementById('capture');
    var display = document.getElementById('display');
    capture.addDisplay(display);  
  </script>
</html>

私の問題は、ライブラリ内のaddDisplayの呼び出しが、提供されたx-displayのインスタンスに関連付けられたものとは異なるNPObjectポインターを呼び出し引数として受け取ることです。また、受け取ったNPObject構造の_classメンバーは、x-displayスクリプト可能オブジェクトを作成したときに提供したものとは異なります。

受信したオブジェクトのメソッドを（handleAddDisplay関数から）列挙して、受信した引数のタイプについて詳しく調べた後、nsJSObjWrapperを含む呼び出しスタックを取得しました（Firefox / Windowsでテストしています）。私のライブラリはnpCaptureDemoPlugin.dllです。最後に、ラッパーは表示オブジェクトの列挙を呼び出しています。

npCaptureDemoPlugin.dll!RendererPlugin::hasMethod(void * name=0x06311d00)  Line 84    C++
npCaptureDemoPlugin.dll!ScriptableObject<RendererPlugin>::Class::hasMethod(NPObject* object=0x191fd0b4, void * name=0x06311d00)  Line 382 + 0x43 bytes    C++
xul.dll!NPObjWrapper_NewResolve(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4c0, int id=0x06311d00, unsigned int flags=0x00000001, JSObject * * objp=0x003cb838)  Line 1659    C++
mozjs.dll!CallResolveOp(JSContext * cx=0x13bf8f60, JSObject * start=0x0650c4a0, JS::Handle<JSObject *> obj={...}, JS::Handle<int> id={...}, unsigned int flags=0x00000000, JSObject * * objp=0x003cb8dc, JSProperty * * propp=0x003cb8d4, bool * recursedp=0x003cb883)  Line 4637 + 0x1b bytes    C++
mozjs.dll!js_LookupProperty(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, int id=0x06311d00, JSObject * * objp=0x003cb8dc, JSProperty * * propp=0x003cb8d4)  Line 4745 + 0x7a bytes    C++
mozjs.dll!JS_LookupPropertyById(JSContext * cx=0x00000000, JSObject * obj=0x0650c4a0, int id=0x06311d00, JS::Value * vp=0x003cb8e4) Line 3502 + 0x49 bytes    C++
xul.dll!xpc_ForcePropertyResolve(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, int id=0x06311d00)  Line 652 + 0x13 bytes    C++
xul.dll!XPC_WN_Shared_Enumerate(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0)  Line 605 + 0xe bytes    C++
xul.dll!XPC_WN_JSOp_Enumerate(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, JSIterateOp enum_op=JSENUMERATE_INIT, JS::Value * statep=0x003cbaf4, int * idp=0x00000000)  Line 1275 + 0x1b bytes  C++
mozjs.dll!Snapshot(JSContext * cx=0x00000000, JSObject * obj=0x00000000, unsigned int flags=0x00000008, JS::AutoIdVector * props=0x003cbb78)  Line 364 + 0x25 bytes    C++
mozjs.dll!js::GetPropertyNames(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0, unsigned int flags=0x00000008, JS::AutoIdVector * props=0x003cbb78)  Line 440 + 0x1a bytes    C++
mozjs.dll!JS_Enumerate(JSContext * cx=0x13bf8f60, JSObject * obj=0x0650c4a0)  Line 4241 + 0x34 bytes    C++
xul.dll!nsJSObjWrapper::NP_Enumerate(NPObject * npobj=0x089cbd90, void * * * idarray=0x003cbf74, unsigned int * count=0x003cbf68) Line 968 + 0xe bytes    C++
xul.dll!mozilla::plugins::parent::_enumerate(_NPP * npp=0x10eff7c8, NPObject * npobj=0x089cbd90, void * * * identifier=0x003cbf74, unsigned int * count=0x003cbf68)  Line 1900 + 0xc bytes    C++
npCaptureDemoPlugin.dll!NPN_Enumerate(_NPP * npp=0x10eff7c8, NPObject * obj=0x089cbd90, void * * * identifier=0x003cbf74, unsigned int * count=0x003cbf68)  Line 254 + 0x18 bytes    C++
npCaptureDemoPlugin.dll!CapturePlugin::handleAddDisplay(NPObject * object=0x089cbd90)  Line 382 + 0x18 bytes    C++
npCaptureDemoPlugin.dll!CapturePlugin::invoke(void * name=0x13855280, const _NPVariant * args=0x003cc270, unsigned int argCount=0x00000001, _NPVariant * result=0x003cc248)  Line 142 + 0xf bytes    C++
npCaptureDemoPlugin.dll!ScriptableObject<CapturePlugin>::Class::invoke(NPObject * object=0x191feb04, void * name=0x13855280, const _NPVariant * args=0x003cc270, unsigned int argCount=0x00000001, _NPVariant * result=0x003cc248)  Line 414 + 0x4f bytes    C++
xul.dll!CallNPMethodInternal(JSContext * cx=0x13bf8f60, JSObject *  obj=0x0650c3a0, unsigned int argc=0x00000001, JS::Value * argv=0x05cd0070, JS::Value * rval=0x05cd0060, bool ctorCall=false) Line 1482 + 0x11 bytes    C++

つまり、Firefoxは私のNPObjectを、タイプを処理できない別のNPObjectにラップし、このNPObjectをプロキシとして使用してオブジェクトを呼び出すように見えます。

私の質問：プラグインインスタンスに関連付けたものと同じNPObjectを関数呼び出しに渡す方法はありますか？または、Invoke呼び出しの引数として受信したオブジェクトをチェックして、それが以前に作成した予期されたタイプであることを確認する別の方法はありますか？または、JSに渡されてネイティブコードに戻されるある種のネイティブIDを使用して、オブジェクト間の関連付けを行うことが唯一の方法ですか？

4

1 に答える 1

1

ブラウザは、多くの場合、あるプラグインからNPObjectをラップしてから、別のプラグインに渡します。これはセキュリティ上の予防策であり、事実上、やりたいことができないことを意味していると思います。ただし、できることは、各NPObjectに何らかの形式の一意のIDを与え、オブジェクトにgetIDメソッドを設定できることです。次に、NPObjectインターフェイスを介してgetIDをクエリした後、必要な実際のオブジェクトを取得するために使用できるマップまたは同様の内部的なものが必要です。

于 2012-09-04T20:50:31.143 に答える