Programmatically handling proxy credentials in gui.App.setProxyConfig

[kevwilso]

Hi All ( and @rogerwang ),

Our product currently utilizes 0.12.3 and is moving to 0.14.*. The product supports proxy scenarios and allows a customer to configure a proxy and internally we utilize gui.App.setProxyConfig to set it up.

One missing feature is a way to include the credentials needed for the Proxy in scenarios where proxy authentication is used. Currently a pop-up occurs and the user has to enter this every time they launch the application. Is there any way to avoid this pop-up and send the credentials via the setProxyConfig??

If not, I would like to request that as a feature. It would be of major help.

Thanks,

Kevin W.

[rogerwang]

Will see this. Thanks

[kevwilso]

Thanks Roger. Let me know if you need any further information.

[kevwilso]

Roger,

Quick question. What release do you think the solution will appear in? If you haven't narrowed it down no worries; just trying to do some planning on my side.

Thanks,

Kevin W.

[rogerwang]

Will try to fix it in the next release. Thanks.

On Thu, Jun 23, 2016, 9:47 PM Kevin Wilson notifications@github.com wrote:

Roger,

Quick question. What release do you think the solution will appear in? If
you haven't narrowed it down no worries; just trying to do some planning on
my side.

Thanks,

Kevin W.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#4966 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAKGGfuk9nLUcFyNOdwHEle2Y8RXBThEks5qOo59gaJpZM4IzSyl
.

[rogerwang]

Unfortunately the proxy config in Chromium internal doesn't support username/password, but you can workaround this by using the webrequest API: https://developer.chrome.com/extensions/webRequest#event-onAuthRequired

I'll also see to provide an API for the password manager in Chromium so you can save the username and password for users.

[rogerwang]

I just enabled password saving for the auth dialog in git. It will be available in the next nightly build. Hopefully this will make life easier for your users.

[kevwilso]

Thanks Roger. When the username password is saved, it encrypted and is it save across sessions or is it clear on application restart.

[fujunwei]

I am interested in trying this out, please assign it to me, thanks.

[fujunwei]

@rogerwang It can work with webRequest::onAuthRequired, Do you mean we need expose an api to developer like http://electron.atom.io/docs/api/app/#event-login?

[rogerwang]

@fujunwei is that very different with webRequest::onAuthRequired?

And can reporter's need be fulfilled by webRequest::onAuthRequired?

[fujunwei]

@kevwilso Does webRequest::onAuthRequired satisfy your requirement?

[kevwilso]

Hi Roger/Fujunwei,

The webRequest::onAuthRequired is a satisfactory workaround. Note though the better solution would be to be able to gui.App.setProxyConfig. However, I understand current limitations there (re: chromium).

Thanks,

kevwilso

[fujunwei]

Thanks @kevwilso . @rogerwang Do we need to expose an API in nw.App based on webRequest extension?

[rogerwang]

@fujunwei webRequest is already a supported API, I don't think we need to wrap it.

Maybe supporting username/password in nw.App.setProxyConfig with saving the password with password manager( components/password_manager) is a good choice. Another option is to wait for Chromium upstream to implement setting it in the proxy settings.

[fujunwei]

@rogerwang Do you mean the usage of the API will be

var password = URLEncoder(password)
nw.App.setProxyConfig('user:' + password + '@host:port')

The username/password will be saved with password manager and be used when that is required?

[fujunwei]

@rogerwang I suggest that a callback need to be added to handle the username/password because setProxyConfig has supported pac url.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.