Can't login when accessing Self-Hosted version behind Cloudflare proxy

[ekadin-mtc]

Issue Description I am running the self-hosted version of Puter in Kubernetes and trying to access it through a Cloudflare tunnel. The page loads fine, but login doesn't work. It looks like the login and api requests are hardcoded to use the port number (4100), however, Cloudflare only proxies 443. I tried changing the http_port in the config.json to 443 but that resulted in Puter trying to bind to 443 (unsuccessfully).

Expected & Actual Behavior Perhaps there can be a separate option to set the port for the server URL to use without affecting the bind port?

Addition Information or Screenshots (if applicable)

[KernelDeimos]

You can set pub_port to 443 in the config; this parameter allows you to set the port for the web page origin separately from the listen port. Thanks for bringing this up; I'm going to pin this issue until we've documented this.

[KernelDeimos]

README.md is updated; closing this issue

[ekadin-mtc]

Thanks! @KernelDeimos

We're making progress; made it to the next error 😀

In Chrome or Edge: GET https://api.puter.xxx.com/socket.io/?auth_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1dWlkIjoiZDExZDU4ZjctNDkyNC00ZTk2LTgzNGItMjAwOTA0ZGQ3ODE0IiwiaWF0IjoxNzEyMjQ0NzcwfQ.ZA1_Ybgtkq1axKXPJuM7cbzzMBzNVnLILydr5cd8gyg&EIO=4&transport=polling&t=OwfoqIU net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH And in Firefox: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.puter.xxx.com/socket.io/?auth_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1dWlkIjoiMmYwMGZlY2EtYTMwZi00OTQ5LThkNmMtMjU3ZGI2NThmNDkyIiwiaWF0IjoxNzEyMjQzNDA5fQ.9cPo09CvRj8X8VQKdmy9JHmJuGfAOCYfN5OR9Mm2sAU&EIO=4&transport=polling&t=OwfpJSw. (Reason: CORS request did not succeed). Status code: (null).

I initially set the pub_port with the protocol set to https, but I also tried leaving protocol on http and instead setting "origin" and "api_base_url" to https://puter. and https://api.puter. respectively with the same results.

Not sure if this should be a separate issue....

[KernelDeimos]

Is the api subdomain part of the (or has its own) certificate? That's one thing I can think of. The CORS error is confusing me because it looks like your domain and port configuration is consistent (from what I can tell in the screenshot)

[MohamedElashri]

Thanks! @KernelDeimos

We're making progress; made it to the next error 😀

In Chrome or Edge: GET https://api.puter.xxx.com/socket.io/?auth_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1dWlkIjoiZDExZDU4ZjctNDkyNC00ZTk2LTgzNGItMjAwOTA0ZGQ3ODE0IiwiaWF0IjoxNzEyMjQ0NzcwfQ.ZA1_Ybgtkq1axKXPJuM7cbzzMBzNVnLILydr5cd8gyg&EIO=4&transport=polling&t=OwfoqIU net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH And in Firefox: Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.puter.xxx.com/socket.io/?auth_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1dWlkIjoiMmYwMGZlY2EtYTMwZi00OTQ5LThkNmMtMjU3ZGI2NThmNDkyIiwiaWF0IjoxNzEyMjQzNDA5fQ.9cPo09CvRj8X8VQKdmy9JHmJuGfAOCYfN5OR9Mm2sAU&EIO=4&transport=polling&t=OwfpJSw. (Reason: CORS request did not succeed). Status code: (null).

I initially set the pub_port with the protocol set to https, but I also tried leaving protocol on http and instead setting "origin" and "api_base_url" to https://puter. and https://api.puter. respectively with the same results.

Not sure if this should be a separate issue....

I actually had this issue and figured out what is the problem. Cloudflare does not allow universal SSL on sub-subdomains (i.e sub.sub.domain.com) unless you pay for Total TLS ($10 per month). So the setup I think you have is like

puter.example.com

and the API endpoint will be a subdomain of that

api.puter.example.com

This is what causes the problem. So you will either need to buy Total TLS, order an Advanced Certificate covering the subdomain. Or use example.com and api.example.com levels for puter. This probably should be added to README.md because puter behavior of requiring the API to be hosted on a subdomain of URL is not standard. Maybe allowing it to be served from another subdomain can work. Something like puter.example.com and puterapi.example.com and make this configurable will be useful for self-hosted scenarios and allow more flexibility.

[ekadin-mtc]

@MohamedElashri You nailed it! I just figured that part out as well 😀. I have a wildcard cname pointing to my tunnel so I didn't think that the subdomain of puter.example will be treated differently. When I tried adding a cname for api.puter, Cloudflare presented a warning letting me know that it won't be covered by the Universal SSL. I tried going with puterapi.example.com but obviously ran into CORS issues at that point.

@KernelDeimos Is that something that can added for self-hosters?

[MohamedElashri]

I agree that this might be useful to add. Or at least make it clear in self-hosting instructions. And at this point I think it is fair to assume that we need to re-open this issue. @KernelDeimos What is your view on that?

And just to clarify, this does is about Cloudflare DNS itself, not just Cloudflare tunnels. so this problem will be with anyone using Cloudflare to manage the DNS.

[ekadin-mtc]

@MohamedElashri Correct, except that for tunnels, Total TLS is not an option.

For now, I went with example.com and api.example.com and everything seems to be working. Now I can start having fun! 🤣

@KernelDeimos One more point for the Readme is that when proxying through Cloudflare (and maybe other proxies?) if you are setting pub_port (and not origin and api_base_url) then you will also need to change protocol to https to avoid mixed content errors.

[KernelDeimos]

@KernelDeimos Is that something that can added for self-hosters?

I think we can do that, and also have a mode where we use /api instead of `api.

need to re-open this issue

I created a new one, #230, which covers this and a few other details

[KernelDeimos]

In case this is relevant, I fixed a bug that prevents puter from working when the main domain itself is a subdomain.