@Amalpaultech can you provide an explanation of why the web proxy is insufficient for the needs of your project?

In T313256#8086487, @bd808 wrote:

@Amalpaultech can you provide an explanation of why the web proxy is insufficient for the needs of your project?

I tried to get it working with the Web Proxy, but we couldn't get the Web Proxy to forward HTTPS requests for some reason, and couldn't fix that issue. And the Caddy container we use forwards all http request to https, which makes the Wiki unreachable.

@Amalpaultech as mentioned on the wiki, floating IP requests aren't typically granted to expose HTTP/HTTPS endpoints to the web. Can you detail why the web proxy didn't work?

It's not clear what issues you are having, but consider utilizing a different web server, or configure caddy differently. Caddy allows you to use http if needed, see https://caddyserver.com/docs/caddyfile/options. You might want auto_https disable_redirects.

@Amalpaultech, you are correct that the web proxy frontend does not currently support TLS encryption between the proxy and your upstream service. Requests from the frontend to your upstream will however include a X-Forwarded-Proto: https header that your software stack can use to determine that TLS encryption with the client has been handled already.

We really, really prefer that web services hosted in Cloud VPS projects use the shared proxy for a few reasons:

• It ensures that TLS encryption is used between the front proxy and the client.
• It saves an IPv4 address and instead uses a name-based vhost. IPv4 addresses are a precious commodity in the modern internet.
• It protects both the end user and your Cloud VPS project from leaking the client IP address which is considered personally identifiable information by the Wikimedia Foundation by hiding the client IP address from your service.

A few quick web searches were not enough to tell me exactly how to configure Caddy to honor an X-Forwarded-Proto: https header. I did find https://caddyserver.com/docs/json/apps/http/servers/automatic_https/#disable_redirects

https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults is also a usual reference. Specifically, it confirms caddy rewrites X-Forwarded-Proto, and how to avoid that.

Yeah, thanks for that info. I will see if I can get it working with the Web Proxy.

I had initially tried the auto_https disable_redirect, but it didn't seem to solve the issue. Will try any configuration with the X-Forwaded-Proto can make a change.

Hi, I am one of Amal's mentors for his GSoC project. I am also one of the primary developers and the chief architect of Canasta. Thank you all for your help with this so far.

For this project, we are not going to be entertaining any significant modifications to Canasta, especially not to the design of the software, as that is not the focus of his GSoC project. Namely, we won't be able to add support to honor X-Forwarded-Proto in the timespan of his GSoC contribution period. We are also not going to support disabling Caddy or making it use HTTP, as this would significantly undermine Canasta's functionality and defeat the purpose of testing Canasta on a Cloud VPS. It is also not Amal's responsibility to be making such changes to the Canasta codebase and I don't want him to spend more time debugging the specifics of a bespoke server setup just to demo something for his GSoC project.

Can a static public IPv6 address be assigned to this server? Surely there is no shortage of those yet ;) It seems, though, the inertia against doing so is a security concern.

If not, that's fine. What we're really looking to do is have it accessible in some way so we can access it somehow from the web, even if only within an intranet accessible by anyone with a Wikitech account. If this requires a VPN or SSH tunneling, then so be it. Would this be possible?

If it's necessary to make further modifications to Canasta, then I'm not so sure the Cloud VPS is going to be the right sandbox for Amal to use. Thanks again for the assistance so far.

P.S. I'm not able to access Amal's server; should I make another ticket to request access to it?

P.S. I'm not able to access Amal's server; should I make another ticket to request access to it?

I see three existing admins to that project: Amal, Jeffrey, Yaron. Any of those three have complete rights to manage access to servers within that project (including granting access to new users.) Documentation about ssh'ing into a VM (once you are a project member) can be found here: https://wikitech.wikimedia.org/wiki/Help:Accessing_Cloud_VPS_instances

In T313256#8093257, @JeffreyWang wrote:

For this project, we are not going to be entertaining any significant modifications to Canasta

Trivial solution: place an instance of your favorite HTTP server (nginx, apache2, lighttpd, ...) on the Cloud VPS instance with it configured to listen for unencrypted HTTP traffic on the port of your choosing and then to reverse proxy those requests to the TLS secured Caddy entry port of the Canasta stack. Canasta doesn't need to know anything about this local proxy or the shared proxy upstream from it.

+1 for approving for a single floating ip for this project.

WMCS is happy to support GSoC projects and students. Best wishes on your project Amal!

Please also be mindful that if this wasn't a GSoC project, I would have asked you to figure out how to make your project work correctly with the proxy, rather than granting a floating ip. I would encourage you to do so anyways. Happy to work with you further on how best to support yourself and others who might wish to use caddy on cloud vps. Feel free to file a separate ticket if you'd like to explore that further. If you're able to figure it out, please do share!

On the IPv6 question, it's not yet possible.. See T187929.

@Andrew We are done with the project so the floating IP can be reclaimed now. Thanks!

Thanks! I've reverted the quotas.