-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ffi-napi on browser #162
Comments
Hey buddy, I'm not sure how to require a native module in browser side, but I think you can call it by |
Browsers run in an isolated context that cannot run native code, unless it's compiled to WebAssembly. But even then, the code cannot escape the webpage, for security reasons. The reason your Electron application can use node-ffi-napi is because it runs on unsandboxed Node, which can use native modules and interact with the system. But browser webpages cannot do that. |
@LoganDark correction they can do that see npm had the browser based versions of all the node builtins modules that will run in the browser but for reasons that would be considered malicous they took those packages away just cause they took it away doesnt mean its not possible all we have to do is resolve the node builtins which is again possible experimental module loading etc |
What you're saying makes no sense. In a normal web browser, like if you were to just start up Firefox or Chrome, there is no way for you to escape the sandbox. You can only execute sandboxed JavaScript and WebAssembly. In Electron, the sandbox deliberately provides some escape hatches that trusted code can use to interact with the native system, such as requiring native Node modules. So it is possible to use ffi-napi on Electron. But still not in a normal browser. |
You can make them emulate the module once again it is possible to spawn a
subprocess in the browser or even the filesystem the creater of node says
95 percent of node can be used in the browser
…On Sat, Nov 5, 2022, 9:31 AM LoganDark ***@***.***> wrote:
@LoganDark <https://github.com/LoganDark> correction they can do that see
npm had the browser based versions of all the node builtins modules that
will run in the browser but for reasons that would be considered malicous
they took those packages away just cause they took it away doesnt mean its
not possible all we have to do is resolve the node builtins which is again
possible experimental module loading etc
What you're saying makes no sense. In a normal web browser, like if you
were to just start up Firefox or Chrome, there is no way for you to escape
the sandbox. You can only execute sandboxed JavaScript and WebAssembly.
In Electron, the sandbox deliberately provides some escape hatches that
trusted code can use to interact with the native system, such as requiring
native Node modules. So it is possible to use ffi-napi on Electron. But
still not in a normal browser.
—
Reply to this email directly, view it on GitHub
<#162 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AN4RQ43Z7ILHJTN474WUIR3WGZ4UXANCNFSM46ZDJDHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
You need to learn about module loading or module bundling g
…On Sat, Nov 5, 2022, 9:33 AM The One ***@***.***> wrote:
You can make them emulate the module once again it is possible to spawn a
subprocess in the browser or even the filesystem the creater of node says
95 percent of node can be used in the browser
On Sat, Nov 5, 2022, 9:31 AM LoganDark ***@***.***> wrote:
> @LoganDark <https://github.com/LoganDark> correction they can do that
> see npm had the browser based versions of all the node builtins modules
> that will run in the browser but for reasons that would be considered
> malicous they took those packages away just cause they took it away doesnt
> mean its not possible all we have to do is resolve the node builtins which
> is again possible experimental module loading etc
>
> What you're saying makes no sense. In a normal web browser, like if you
> were to just start up Firefox or Chrome, there is no way for you to escape
> the sandbox. You can only execute sandboxed JavaScript and WebAssembly.
>
> In Electron, the sandbox deliberately provides some escape hatches that
> trusted code can use to interact with the native system, such as requiring
> native Node modules. So it is possible to use ffi-napi on Electron. But
> still not in a normal browser.
>
> —
> Reply to this email directly, view it on GitHub
> <#162 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AN4RQ43Z7ILHJTN474WUIR3WGZ4UXANCNFSM46ZDJDHA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
For reasons that doesnt really make sense they dont want us spawning
subprocess's in the browser so in order to do it we have to ourselves
…On Sat, Nov 5, 2022, 9:33 AM The One ***@***.***> wrote:
You need to learn about module loading or module bundling g
On Sat, Nov 5, 2022, 9:33 AM The One ***@***.***> wrote:
> You can make them emulate the module once again it is possible to spawn a
> subprocess in the browser or even the filesystem the creater of node says
> 95 percent of node can be used in the browser
>
> On Sat, Nov 5, 2022, 9:31 AM LoganDark ***@***.***> wrote:
>
>> @LoganDark <https://github.com/LoganDark> correction they can do that
>> see npm had the browser based versions of all the node builtins modules
>> that will run in the browser but for reasons that would be considered
>> malicous they took those packages away just cause they took it away doesnt
>> mean its not possible all we have to do is resolve the node builtins which
>> is again possible experimental module loading etc
>>
>> What you're saying makes no sense. In a normal web browser, like if you
>> were to just start up Firefox or Chrome, there is no way for you to escape
>> the sandbox. You can only execute sandboxed JavaScript and WebAssembly.
>>
>> In Electron, the sandbox deliberately provides some escape hatches that
>> trusted code can use to interact with the native system, such as requiring
>> native Node modules. So it is possible to use ffi-napi on Electron. But
>> still not in a normal browser.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#162 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AN4RQ43Z7ILHJTN474WUIR3WGZ4UXANCNFSM46ZDJDHA>
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
|
I already know a fair bit about it, but what you're saying makes little to no sense. Yes, you can run Linux in the browser, which can spawn subprocesses and run Node and whatever. Is this what you mean? Please note that these are not real subprocesses or native code, it is simply emulation. |
You know that u can resolve node builtins to umd then? You would also u can
use such modules as fs net dgram and etc and more with resolving through
module commonjs loading and resolving etc its all about turning the code in
the way that the browser understands
…On Sat, Nov 5, 2022, 9:39 AM LoganDark ***@***.***> wrote:
You need to learn about module loading or module bundling g
I already know a fair bit about it, but what you're saying makes little to
no sense.
Yes, you can run Linux in the browser, which can spawn subprocesses and
run Node and whatever
<https://bellard.org/jslinux/vm.html?url=alpine-x86.cfg&mem=192>. Is this
what you mean?
—
Reply to this email directly, view it on GitHub
<#162 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AN4RQ47Q3SPBRZI7EURUOKLWGZ5U3ANCNFSM46ZDJDHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Here I will show |
To avoid malicious use ^^ meaning it is possible to spawn the process in such a way that they wont release the orig package for the browser |
All of this doesn't mean what you think it does @Kali95739 child_process is a package that comes with node, but if it was also a npm package then someone might install a replacement thinking it was needed to be installed and if it was controlled by some random person then it is a good target to be malicious. It isn't that they are withholding packages to not run processes in a browser. They are holding that npm package name so someone doesn't make a malicious package and people install it with npm even though you do not need to install it (it comes with node). There is javascript that runs in a browser. It is very locked down. You can NOT load up native libraries, you can NOT run system executable in it. It is locked down there is no full node environment. You can make packages that are limited that act like node modules, but it is not the same. These pretend or browser node modules only allow you to do what the browser lets you. They can be handy for compatibility between browser and node in some situations, but they are not full functioning like the original node module. For example 'fs' replacement module for browsers often use a virtual file system, you can not access just any file on the computer like the real node version. Only a virtual file system for your web page. This can be handy to preload some files in this virtual file system then have some other module use that file to do processes. This other module then could work both in a browser or node, but it doesn't have full access to the computers file system in the browser, only a virtual files. There may exist something like a limited child_process somewhere for browsers than can run js code in a webworker. But it won't run just any executable on that persons machine. |
Yes
…On Sat, Nov 5, 2022, 12:42 PM Russell Valentine ***@***.***> wrote:
All of this doesn't mean what you think it does @Kali95739
<https://github.com/Kali95739>
child_process is a package that comes with node, but if it was also a npm
package then someone might install a replacement thinking it was needed to
be installed and if it was controlled by some random person then it is a
good target to be malicious. It isn't that they are withholding packages to
not run processes in a browser. They are holding that npm package name so
someone doesn't make a malicious package and people install it with npm
even though you do not need to install it (it comes with node).
There is javascript that runs in a browser. It is very locked down. You
can NOT load up native libraries, you can NOT run system executable in it.
It is locked down there is no full node environment. You can make packages
that are limited that act like node modules, but it is not the same. These
pretend or browser node modules only allow you to do what the browser lets
you. They can be handy for compatibility between browser and node in some
situations, but they are not full functioning like the original node module.
For example 'fs' replacement module for browsers often use a virtual file
system, you can not access just any file on the computer like the real node
version. Only a virtual file system for your web page. This can be handy to
preload some files in this virtual file system then have some other module
use that file to do processes. This other module then could work both in a
browser or node, but it doesn't have full access to the computers file
system in the browser, only a virtual files.
There may exist something like a limited child_process somewhere for
browsers than can run js code in a webworker. But it won't run just any
executable on that persons machine.
—
Reply to this email directly, view it on GitHub
<#162 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AN4RQ46SGWYQUUF454E7UYTWG2TCBANCNFSM46ZDJDHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I am trying to get this to work in the browser myself atm so if I have luck
I will report back here
…On Sat, Nov 5, 2022, 12:43 PM The One ***@***.***> wrote:
Yes
On Sat, Nov 5, 2022, 12:42 PM Russell Valentine ***@***.***>
wrote:
> All of this doesn't mean what you think it does @Kali95739
> <https://github.com/Kali95739>
>
> child_process is a package that comes with node, but if it was also a npm
> package then someone might install a replacement thinking it was needed to
> be installed and if it was controlled by some random person then it is a
> good target to be malicious. It isn't that they are withholding packages to
> not run processes in a browser. They are holding that npm package name so
> someone doesn't make a malicious package and people install it with npm
> even though you do not need to install it (it comes with node).
>
> There is javascript that runs in a browser. It is very locked down. You
> can NOT load up native libraries, you can NOT run system executable in it.
> It is locked down there is no full node environment. You can make packages
> that are limited that act like node modules, but it is not the same. These
> pretend or browser node modules only allow you to do what the browser lets
> you. They can be handy for compatibility between browser and node in some
> situations, but they are not full functioning like the original node module.
>
> For example 'fs' replacement module for browsers often use a virtual file
> system, you can not access just any file on the computer like the real node
> version. Only a virtual file system for your web page. This can be handy to
> preload some files in this virtual file system then have some other module
> use that file to do processes. This other module then could work both in a
> browser or node, but it doesn't have full access to the computers file
> system in the browser, only a virtual files.
>
> There may exist something like a limited child_process somewhere for
> browsers than can run js code in a webworker. But it won't run just any
> executable on that persons machine.
>
> —
> Reply to this email directly, view it on GitHub
> <#162 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AN4RQ46SGWYQUUF454E7UYTWG2TCBANCNFSM46ZDJDHA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
Almost there up until |
no native build was found for platform=win32 arch=x64 runtime=node abi=undefinded uv= libc=glibc node=undefined |
imported from /node_modules/@inigolabs/ref-napi |
You can't do it. It isn't just about making a umd bundle. Just think if the browser let you run any native library. A website can just take over your whole computer. That's called a browser vulnerability. You can probably get $100k from google bug bounty or something. Anyway, this is the last comment I'll do, you are not listening. |
I actually believe I may have been able to I replaced all of the modules in the browser including FS physical access thanks to promise its just that we need to bundle over es2015 because the modules are commonjs and es2015 mixed in so it related by bundling path must be a string atm if I can get past that and have the funcs yet in browser I will add another comment although placing browser based funcs I can still experiment module it in my node so maybe possible actually |
Nvmd u are correct u cannot use this unless if u maybe somehow grepped the instance of the node installation seems to not work without the execPath func |
No way to use it without a node install |
I am trying to create a local browser-based application (no server, will not be hosted on a domain - usage is purely local).
I need to have access to some dlls so I need to use
ffi-napi
:Example (what I need to use is not specifically the
libm
module, just simplifying the example):This works fine when on I am running on Electron. But when I compile it for use with the browser, I am getting this error message (which is being thrown by
Webpack
/node-gyp-build
:I understand that
require
is not native on the browser mode, but the framework I am using, I believe, already hasbrowserify
integrated (I am usingQuasar framework
). I think so because the other local modules I can userequire()
on the browser just fine.Is there any way I can use
ffi-napi
on the browser?Help!
The text was updated successfully, but these errors were encountered: