proxy network setting not working?

[pstefka]

Hi,

I've started with Keypirinha today - and I like it really much! As such I'm still learning, but I think the proxy network setting doesn't work.

My user configuration file on a Windows 10 system looks like this:

[network]
proxy = system

[app]
hotkey_run = Alt+Space

I've tried setting the corporate proxy in the IE LAN setting both as an automatic configuration script and also as proxy server using IP address. Irrespective of the setting, the shipped packages I've tried (GoogleTranslate & WebSearch) connect directly to the destination address not respecting the proxy setting.

Is it a bug, or do I miss something? Thanks!

[polyvertex]

Hey, have you checked the content of the console/log file of Keypirinha? What is the protocol of the proxy you tried?

[pstefka]

The console says:

07:52:51.327 Python: Traceback (most recent call last):
07:52:51.327 Python: File "lib\urllib\request.py", line 1318, in do_open
07:52:51.327 Python: File "lib\http\client.py", line 1239, in request
07:52:51.327 Python: File "lib\http\client.py", line 1285, in _send_request
07:52:51.327 Python: File "lib\http\client.py", line 1234, in endheaders
07:52:51.327 Python: File "lib\http\client.py", line 1026, in _send_output
07:52:51.327 Python: File "lib\http\client.py", line 964, in send
07:52:51.327 Python: File "lib\http\client.py", line 1392, in connect
07:52:51.327 Python: File "lib\http\client.py", line 936, in connect
07:52:51.327 Python: File "lib\socket.py", line 722, in create_connection
07:52:51.327 Python: File "lib\socket.py", line 713, in create_connection
07:52:51.327 Python: socket.timeout: timed out
07:52:51.327 Python:
07:52:51.327 Python: During handling of the above exception, another exception occurred:
07:52:51.327 Python: Traceback (most recent call last):
07:52:51.327 Python: File "C:\Users\osk11211\Downloads\keypirinha-2.15.4-full-portable\default\Packages\GoogleTranslate.keypirinha-package\googletranslate.py", line 116, in on_suggest
07:52:51.327 Python: File "C:\Users\osk11211\Downloads\keypirinha-2.15.4-full-portable\python\site\keypirinha_net.py", line 40, in open
07:52:51.327 Python: fullurl, *args, data=data, timeout=timeout, **kwargs)
07:52:51.327 Python: File "lib\urllib\request.py", line 526, in open
07:52:51.327 Python: File "lib\urllib\request.py", line 544, in _open
07:52:51.327 Python: File "lib\urllib\request.py", line 504, in _call_chain
07:52:51.327 Python: File "lib\urllib\request.py", line 1361, in https_open
07:52:51.327 Python: File "lib\urllib\request.py", line 1320, in do_open
07:52:51.327 Python: urllib.error.URLError:

I've traced originally with Wireshark and that said direct connection instead of proxy IP.

[pstefka]

Btw. the protocol of the proxy is http.

[polyvertex]

I could not reproduce the issue neither with a SOCKS5 or an HTTP proxy. Sorry for that but I would need more info in order to replicate your environment and the issue. Would you mind taking a screenshot of your proxy settings at system level?

You may blur the proxy address out of privacy concern but since some parsing is involved during the reading of these settings by Keypirinha, please blur only the network address(es) and keep the original format so I can test in conditions that are as close as possible to yours.

I assume you did not close this issue on purpose?

[pstefka]

Sure, the closing was a mistake - reopening, sry.

The "normal setting":

Also tried changing to IP:port

Resulted in:

 WARNING: Unrecognized format of system's proxy setting: "10.2.100.20:80"
09:15:28.893 Python: Traceback (most recent call last):
09:15:28.893 Python:   File "lib\urllib\request.py", line 1318, in do_open
09:15:28.893 Python:   File "lib\http\client.py", line 1239, in request
09:15:28.893 Python:   File "lib\http\client.py", line 1285, in _send_request
09:15:28.893 Python:   File "lib\http\client.py", line 1234, in endheaders
09:15:28.893 Python:   File "lib\http\client.py", line 1026, in _send_output
09:15:28.893 Python:   File "lib\http\client.py", line 964, in send
09:15:28.894 Python:   File "lib\http\client.py", line 1392, in connect
09:15:28.894 Python:   File "lib\http\client.py", line 936, in connect
09:15:28.894 Python:   File "lib\socket.py", line 722, in create_connection
09:15:28.894 Python:   File "lib\socket.py", line 713, in create_connection
09:15:28.894 Python: socket.timeout: timed out
09:15:28.894 Python:
09:15:28.894 Python: During handling of the above exception, another exception occurred:
09:15:28.895 Python: Traceback (most recent call last):
09:15:28.895 Python:   File "C:\Users\osk11211\Downloads\keypirinha-2.15.4-full-portable\default\Packages\GoogleTranslate.keypirinha-package\googletranslate.py", line 116, in on_suggest
09:15:28.895 Python:   File "C:\Users\osk11211\Downloads\keypirinha-2.15.4-full-portable\python\site\keypirinha_net.py", line 40, in open
09:15:28.895 Python:     fullurl, *args, data=data, timeout=timeout, **kwargs)
09:15:28.895 Python:   File "lib\urllib\request.py", line 526, in open
09:15:28.895 Python:   File "lib\urllib\request.py", line 544, in _open
09:15:28.895 Python:   File "lib\urllib\request.py", line 504, in _call_chain
09:15:28.896 Python:   File "lib\urllib\request.py", line 1361, in https_open
09:15:28.896 Python:   File "lib\urllib\request.py", line 1320, in do_open
09:15:28.896 Python: urllib.error.URLError: <urlopen error timed out>

What's a bit strange, the proxy change gets detected, however only when changing to IP:port.

[polyvertex]

Ah yes, the following line put me on track: WARNING: Unrecognized format of system's proxy setting: "10.2.100.20:80". KP expects the URL scheme to be specified instead of assuming http by default.

May I ask you to manually setup the proxy to http://10.2.100.20:80 (i.e. no automatic config script) and share the content of the log, to see if it solves this part of the issue?

[pstefka]

When I update the proxy, the log says:

10:51:31.674 Application configuration has changed
10:51:32.724 WARNING: Unrecognized format of system's proxy setting: "http://10.2.100.20:80"

However when I open the configuration again, the http got stripped away, so the config displays the IP:port only as seen on the attachment above.

[polyvertex]

Oh, I meant directly in Keypirinha. The point is to ensure Keypirinha deals correctly with your proxy once we got rid of the issue with the parsing of system's settings. Your KP config for the test would be:

[network]
proxy = http://10.2.100.20:80

[pstefka]

The problem is, the proxy requires authentication (NTLM - thought I've written it already, unfortunately I didn't), as such proxy setting without credentials won't work.

Nevertheless after replacing the user Keypirinha.ini with the setting you've sent, Keypirinha still tries to connect directly :-/ attaching the config (with other settings, though the behavior is the same) + trace

Desktop.zip

[polyvertex]

Alas NTLM authentication is not supported, I will evaluate the requirements to implement it but for now I cannot guaranty it will be supported in the future. I am aware this prevents some to use KP but time is a finite resource unfortunately. I will report back here any related news.

For the next release, I will fix the parsing issue that you found incidentally. Thanks for your feedback and for taking the time to answer my questions.

[pstefka]

Sure, no problem - I thank for the quick feedback!

However the traces show, that although proxy is set, KP connects directly, i.e. this has nothing to do with NTLM. I've installed Fiddler to intercept the proxy traffic, however when the connection is direct, fiddler can't help with the NTLM authentication.

[polyvertex]

However the traces show, that although proxy is set, KP connects directly [...]

There is indeed a connection attempt that goes to void after a DNS query has been made in the trace you provided.

I could not reproduce this myself so this issue is obviously configuration-dependent. To circumvent that, the best way is probably to make Keypirinha's plugins use the Windows API for network requests (i.e. for now Python's urllib.request standard module is used as a base API).

This might be tricky due to potential ABI-compatibility issues so this is a long shot. Good thing is potentially every kinds of setups supported by the OS would then be supported. In most cases for free.

Follow #247 to get updated on this.

[polyvertex]

Parsing issue should now be fixed in v2.16.
For the other parts of the issue, see above comment.