CLI fails from behind proxy

[rokkie]

When the environment variables http_proxy/https_proxy are set, the CLI fails:

http_proxy=http://localhost \
https_proxy=http://localhost \
PLATFORMSH_CLI_TOKEN=xxx-yyy-zzz \
  php ./bin/platform project:info

Results in

[ConnectException]                                            
cURL error 7: Unsupported proxy scheme for 'tcp://localhost'

I suspect that the change in src/Service/Api.php from #1037 was a bit overenthusiastic.
To test this I've reverted that and ran the same command again. Now I got:

[ConnectException]
cURL error 7: Failed to connect to localhost port 1080: Connection refused

which makes sense since I don't actually run a proxy on my machine, but at least it seems to try to connect instead of just bailing.

[rroblik]

Same for me since 3.65.2 ; was working under 3.65.1

[pjcdawkins]

Well, you seem to be the proxy tester 😄

I assume this is because PHP's stream functions need tcp://, while cURL needs http://

[rokkie]

I assume this is because PHP's stream functions need tcp://, while cURL needs http://

I guess so to.

you seem to be the proxy tester

TEST ALL THE PROXIES!!! 😛

[pjcdawkins]

Hmmm... the change to Api.php was to add ssl:// as a possible scheme as well as tcp://, so I guess it's actually that PHP's wrappers want tcp/ssl, while curl only wants tcp. I'll try to find an authoritative source...

[pjcdawkins]

I haven't found anything very clear yet, but here's an attempt ^

[rokkie]

I've checked out the branch locally, ran composer install and executed the same

http_proxy=http://localhost \
https_proxy=http://localhost \
PLATFORMSH_CLI_TOKEN=xxx-yyy-zzz \
  php ./bin/platform project:info

command, but it still says

[ConnectException]
cURL error 7: Unsupported proxy scheme for 'tcp://localhost'

[pjcdawkins]

Thanks, good point I can just try that myself. I've pushed an update, can you git pull and try again please?

[rokkie]

Looking better, i now get

cURL error 7: Failed to connect to localhost port 1080: Connection refused

which (again) makes sense since I don't actually have a proxy running.

[pjcdawkins]

Thanks.

Hm. It looks like Guzzle (5) doesn't do any adapting for this proxy setting. It might be more helpful (but also might be annoyingly 'magical') to check for extension_loaded('curl') and transform the proxy scheme for Guzzle (http->tcp, https->ssl) if curl isn't loaded. I've committed this: ffc9c11

[rokkie]

Is there anything more that I can do/test?
As far as I can tell it looks fine, the Connection refused was to be expected.
The real proof of the pudding (on my end) is on our buildserver, but I have to rebuild the gitlab runner first and I can't do that easily from a local branch/different fork.
I'm happy to test when this is merged #feelinglucky.

[pjcdawkins]

It's in release 3.65.3 so please try again with your gitlab!

[rokkie]

Hi again!

I've tested the 3.65.3 release but it still fails :(
However, I have a strong suspicion that this is caused by our own proxy/firewall.
The message I get is

...
debug1: Connecting to git.eu-4.platform.sh [52.215.88.119] port 22.
debug1: connect to address 52.215.88.119 port 22: Connection timed out
...

A quick search points here for a possible solution that I want to try, but I can't make out from the documentation how to configure/integrate this.
I've searched a bit through the source code and there seem to be options for configuring ssh, but i'm a bit lost as to what the 'preferred' way of doing this is.
From what I can tell, *.platform.sh is already the default 'wildcard host' and I just need/want to add Port 443 to that.
Can you tell me how I'm supposed (as in, the 'preferred way') to do this?

Thanks for the help so far!

[pjcdawkins]

The GitHub thing only works because they expose SSH over port 443 as well as 22 (https://docs.github.com/en/github/authenticating-to-github/using-ssh-over-the-https-port)

I don't think we have an equivalent... I'll check.

(but firstly.. does the GitHub thing work for you, e.g. for cloning GitHub repositories via SSH? your firewall may or may not be able to block SSH over any port)

[rokkie]

I've asked if SSH over 443 should work (asked because I don't have direct access to the build server so I can't try out myself) and the answer was "443 is open, until someone decides to turn on protocol inspection in the firewall" followed by the question if it isn't easier to just use https (over 443).
Is that something I can do with the CLI, or otherwise manually? Or is https just not supported on your side?

[pjcdawkins]

We happen to support Git-over-HTTPS, via a custom authorization scheme. It doesn't have any particularly convenient client implementation.. essentially you'd want to send an HTTP header with Authorization: Bearer <TOKEN>, where the token is the access token you can get through platform auth:token. And you'd need to know the right URL format, which I think is the URL you get from platform project:info url. But I don't think anybody has actually used this.

For SSH to the container (and therefore rsync, scp, and operations that need to go through the container like platform sql) we only support SSH, and only on port 22.

[rroblik]

Dear @pjcdawkins ; any new about git over https support ?

Mandatory in my enterprise.

Thanks

[rroblik]

Up