Is your feature request related to a problem? Please describe.
Currently, local CEF browsers cannot directly access remote content, even when the domain has been explicitly allowed through requestBrowserDomains.
I recently ran into this while integrating an R2 bucket. Since CEF could not load assets directly from it, I had to do something like:
CEF -> Lua -> external service -> Lua -> CEF
It works, but effectively turns Lua into a proxy for something browsers already handle natively.
This also affects common use cases such as CDNs, external APIs, pagination, dashboards, media and dynamically loaded assets, which makes everything MUCH more verbose and complex.
What I don't fully understand is why remote network access and access to Lua/MTA are tied together this way.
I understand that local CEF is privileged because it can communicate with Lua, and arbitrary remote pages should obviously not gain access to that. But network access itself seems like a separate capability.
Since CEF can already reach external services indirectly through Lua, the current restriction often seems to move the network boundary to Lua rather than prevent the interaction.
I'm also not familiar with the original reasoning behind this restriction, so I'd be interested to know whether it exists because of a specific security concern or simply because local browsers were originally designed around local content.
Describe the solution you'd like
Allow local CEF browsers to access remote resources from domains explicitly approved through requestBrowserDomains, while keeping access to Lua/MTA as a separate privileged capability.
For example, a local UI should be able to use normal browser functionality such as fetch, XMLHttpRequest, remote images, fonts, media or WebSockets against approved domains.
Loading or requesting content from a remote domain should not automatically give that remote content access to the MTA/Lua interface.
This is closer to how systems like FiveM handle NUI: normal web functionality is available, while communication with the game happens through an explicit interface that should be treated as untrusted and validated accordingly.
The exact implementation does not need to match FiveM, but separating remote access from the MTA bridge would make CEF much more useful without exposing privileged functionality.
Describe alternatives you've considered
The main workaround is proxying requests through Lua:
CEF -> Lua -> fetchRemote -> Lua -> CEF
For assets, they can also be downloaded and cached locally before being exposed to CEF.
Both approaches work, but add unnecessary complexity and become especially awkward with large or frequently changing collections of assets, or things like filtering front-end stuff since you mess with a lot of parameters that change query results.
Bundling everything with the resource is also impractical for this kind of use case.
Additional context
No response
Security Policy
Is your feature request related to a problem? Please describe.
Currently, local CEF browsers cannot directly access remote content, even when the domain has been explicitly allowed through
requestBrowserDomains.I recently ran into this while integrating an R2 bucket. Since CEF could not load assets directly from it, I had to do something like:
CEF -> Lua -> external service -> Lua -> CEF
It works, but effectively turns Lua into a proxy for something browsers already handle natively.
This also affects common use cases such as CDNs, external APIs, pagination, dashboards, media and dynamically loaded assets, which makes everything MUCH more verbose and complex.
What I don't fully understand is why remote network access and access to Lua/MTA are tied together this way.
I understand that local CEF is privileged because it can communicate with Lua, and arbitrary remote pages should obviously not gain access to that. But network access itself seems like a separate capability.
Since CEF can already reach external services indirectly through Lua, the current restriction often seems to move the network boundary to Lua rather than prevent the interaction.
I'm also not familiar with the original reasoning behind this restriction, so I'd be interested to know whether it exists because of a specific security concern or simply because local browsers were originally designed around local content.
Describe the solution you'd like
Allow local CEF browsers to access remote resources from domains explicitly approved through
requestBrowserDomains, while keeping access to Lua/MTA as a separate privileged capability.For example, a local UI should be able to use normal browser functionality such as
fetch, XMLHttpRequest, remote images, fonts, media or WebSockets against approved domains.Loading or requesting content from a remote domain should not automatically give that remote content access to the MTA/Lua interface.
This is closer to how systems like FiveM handle NUI: normal web functionality is available, while communication with the game happens through an explicit interface that should be treated as untrusted and validated accordingly.
The exact implementation does not need to match FiveM, but separating remote access from the MTA bridge would make CEF much more useful without exposing privileged functionality.
Describe alternatives you've considered
The main workaround is proxying requests through Lua:
CEF -> Lua ->
fetchRemote-> Lua -> CEFFor assets, they can also be downloaded and cached locally before being exposed to CEF.
Both approaches work, but add unnecessary complexity and become especially awkward with large or frequently changing collections of assets, or things like filtering front-end stuff since you mess with a lot of parameters that change query results.
Bundling everything with the resource is also impractical for this kind of use case.
Additional context
No response
Security Policy