It seems that the proxy settings are still not working properly in the new 12.0 Beta 3/3.1/3.2 releases. In the current release, it's been discovered that the /CONNECTION= is being set to PROXY instead of Proxy, so that's going to be fixed in Beta 3.3/4. But it's still not working, so I'm setting up this new thread to keep track of things. I've moved the relevant comments over here as well.
I'm working on a tester so we can try to determine what is and isn't working in inetc and will post it shortly. We'll get this nailed down as I'd really like to have proxies working in 12.0 final.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Looks like manual proxy setting is completely ignored. Platform's just using system proxy no matter what I set. And because system proxy is blocking skype and teamviewer sites I'm not able to install them...
I confirm the problem.
I'm using a patched Jhttpp2 . this proxy ask no proxy auth.
When configuring specific proxy mode, the option is ignored.
I've even tested that on a computer with open http, and no jhttpp2 running, it works as if the proxy options were ignored...
anyway thanks for the hardwork
I've update to 12.0 beta 3.2
I've update to 12.0 beta 3.2 and the problem persist
I've seen the commandline through task manager for the updater:
the option if passed as argument
PortableAppsUpdater.exe /STARTUP=false /MODE=UPDATE /KEYBOARDFRIENDLY=false /BETA=true /CONNECTION=PROXY /PROXYIP=127.0.0.1 /PROXYPORT=3128
the problem is the same if I launch the command manually
after
"PortableApps.com Updater
Checking for apps..."
this box appears:
"Unable to connect to PortableApps.com to retrieve portable apps.
Please try again later. [ SendRequest Error ]
[OK]"
so the problem seems to came from the updater itself ?
does it need to be updated independently ?
Maybe it can help ...
I just found the source
I just found the source PortableApps.com.nsi
I've identified the code about proxy
${GetOptions} "$CMDLINE" "/CONNECTION=" $strConnectionType ${GetOptions} "$CMDLINE" "/PROXYIP=" $strProxyIP ${GetOptions} "$CMDLINE" "/PROXYPORT=" $strProxyPort ${If} $strConnectionType == "Direct" StrCpy $strConnectionString '/NOPROXY /CONNECTTIMEOUT 30 /caption "${APPNAME}" /USERAGENT "Wget/1.13.4" /NOCOOKIES' ${EndIf} ${If} $strConnectionType == "Proxy" StrCpy $strConnectionString '/PROXY $strProxyIP:$strProxyPort /CONNECTTIMEOUT 30 /caption "${APPNAME}" /USERAGENT "Wget/1.13.4" /NOCOOKIES' ${EndIf} ${If} $strConnectionType == "Automatic" StrCpy $strConnectionString '/CONNECTTIMEOUT 30 /caption "${APPNAME}" /USERAGENT "Wget/1.13.4" /NOCOOKIES' ${EndIf} ... inetc::get $strConnectionString /nocancel ${strRemoteUpdateURL} ${strUpdateFile7z} /ENDI just noticed that the parameter /CONNECTION=PROXY did not march the expected /CONNECTION=Proxy (or ${If} compare without case)
But testing with /CONNECTION=Proxy, doe not work better.
If I understand well proxy just add that to inetc::get command line
/PROXY 127.0.0.1:3128 /CONNECTTIMEOUT 30
I've tried /PROXYIP=http://127.0.0.1
but it does nothing better.
I don't know that language or inet::get procedure...
It's done as /PROXY IP:PORT as outlined in the documentation but the Platform is passing PROXY instead of Proxy in a few places in the code. I'll have this fixed in the next beta. Thanks for noticing this.
Please try this quick change to the 3.2 beta. Just replace your existing PortableAppsPlatform.exe. This should, in theory, get it working. I'd like some independent verification before I push it out, though.
Sometimes, the impossible can become possible, if you're awesome!
it corrects the syntax of /CONNECTION=
however it still moans about SendRequest error.
the problem seems inside the inet::get procedure.
SendRequest means it is unable to download. It's a basic error. I was able to download the list of apps via the platform using this updated platform exe and a free HTTP proxy listed online. Are you using an HTTP or HTTPS proxy? I think it may only support the former.
UPDATE: It seems to be ignoring it on my end. I'm passing it in as documented, with a fake local proxy I know isn't running, but it's just connecting directly. I think I'll just ditch proxy handling for now as inetc doesn't seem to properly handle it anyway. It's very odd as I had it working with a minimal proxy setup previously.
Sometimes, the impossible can become possible, if you're awesome!
I confirm the same symptom here on my home PC without any proxy
I've just posted ProxyTest 1.0.0. In it you'll fine ProxyTest.exe which is configurable with ProxyTest.ini. You can set the proxy port, proxy ip, download url, and download file name which will be saved to the same directory. It'll bring up a messagebox with the inetc call and the response generated from the call. To test it with the updater database download, set the URL to this and the download file name to update.7z.
Please let me know what does and doesn't work for you.
Pro tip: You can copy the text of a Windows message box by ensuring it's in the foreground (click the titlebar) and then hitting CTRL-C on your keyboard.
Sometimes, the impossible can become possible, if you're awesome!
It works perfectly ...
surprising ! why is it not working in the updater .?
note that the
ProxyTest.ini should rather contain
DownloadedFileName=update.7zwhen I stop the proxy it fails, if I start it it works.
amazingly normal.
I noticed similar behavior here. So the inetc calls may respond differently to /PROXY being written out vs it being contained in a variable. That will be my next test.
Sometimes, the impossible can become possible, if you're awesome!
This works with my setup as well. I'm looking forward for new version already :).
Ok, I think I have this sorted. Backup your platform first for safe keeping.
Starting with the 12.0 Beta 3.2 release, first replace your PortableAppsPlatform.exe with this one that I posted above on May 21. That fixes the command line.
Next, replace your PortableAppsUpdater.exe with this one that I just posted now. This one re-arranges all the inetc calls so they don't use passed variables for all the important bits, just hard-coded strings. In theory, this should get it working with proxies (though not SOCKS proxies yet).
Please report back with your findings!
Sometimes, the impossible can become possible, if you're awesome!
Hi,
thanks very much.
my first test are good, it does the checking without errors.
it can list the applications
and I could download one application via the GUI
I did not test automatic update on one application, since all is updated.
many thanks again
Thanks for testing. I'll be including these fixes in Beta 4 which should release later today or tomorrow.
Sometimes, the impossible can become possible, if you're awesome!
Thanks John for Updating this two Files. Now my Connection for Updating works correcly over Proxy.
Regards
Klaus.Ka
You're welcome. I wanted to make sure I got this one nailed down for the 12.0 release. Having a couple confirmations pre-beta 4 also means I can be relatively confident that the changes, as counter-intuitive as they are, should workaround the issue of calling the plugin within NSIS correctly.
Sometimes, the impossible can become possible, if you're awesome!
I don't know why, but the update of Chrome, which normally download an update on internet, works now well with a manual proxy...
that is cool!
If this is not done by portable apps platform or by Chrome portable installer, maybe is it the new way "foxyproxy" is integrated as proxy manager by Chrome...
anyway cool!
If you updated via the platform's updater, it will download both the live installer (...online.paf.exe) and the Chrome MSI from Google via your proxy you have configured in the platform.
Sometimes, the impossible can become possible, if you're awesome!
That makes a corporate guy happy
Thanks!