You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently wry does not expose or support upstream proxies for the webview on Linux.
WebkitGTK supports this out of the box since version 2.16 but it is not exposed in a uniform interface in wry.
I would like to have an exposed wry proxy configuration, where it is possible to set the webview proxy independent
of the underlying WebkitGTK method. Possibly this interface could be used for Webview2 by adding custom parameters
to the window creation by default.
I would like to have a patch for older wry versions, so we could use this feature in Tauri 1.x instead of just in the 2.x releases.
There are no alternatives present and using this for auditing or compliance would require a custom built version of Tauri and Wry.
The functionality is needed in corporate environments where there are upstream proxies to be honored and when auditing Tauri applications it is helpful to use common security tooling in the process.
The proxy feature is exposed on windows via the custom webview arguments (--proxy-server 127.0.0.1:8080) and on MacOs in a new beta version.
Discussed this shortly with @wusyong before opening the issue here.
The text was updated successfully, but these errors were encountered:
Currently wry does not expose or support upstream proxies for the webview on Linux.
WebkitGTK supports this out of the box since version
2.16
but it is not exposed in a uniform interface in wry.I would like to have an exposed wry proxy configuration, where it is possible to set the webview proxy independent
of the underlying WebkitGTK method. Possibly this interface could be used for
Webview2
by adding custom parametersto the window creation by default.
I would like to have a patch for older wry versions, so we could use this feature in Tauri
1.x
instead of just in the2.x
releases.The most recent supported interface is exposed in the
WebsiteDataManager.set_network_proxy_settings
and the deprecated version is exposed via
WebContext.set_network_proxy_settings
.There are no alternatives present and using this for auditing or compliance would require a custom built version of Tauri and Wry.
The functionality is needed in corporate environments where there are upstream proxies to be honored and when auditing Tauri applications it is helpful to use common security tooling in the process.
The proxy feature is exposed on windows via the custom webview arguments (
--proxy-server 127.0.0.1:8080
) and on MacOs in a new beta version.Discussed this shortly with @wusyong before opening the issue here.
The text was updated successfully, but these errors were encountered: