I would like to know if its possible to do this. I know it is not sensible but I would just like to get it to work and once it does it will be useful knowledge but never to be used in real life.
I have a VM running a svelte front end and directus backend. If I open ports on my router (port forwarding) then I can via HTTP connect to the frontend, which contacts the backend and everything is great. Except that it is HTTP and eg firefox will not allow login info to be entered into fields in a HTTP page. (Edge will).
So I run the front end under HTTPS. This works except that there are mixed block errors because https is accessing http data (the backend). So that’s not good as all of the dynamic data is missing.
So I used caddy as a reverse proxy to allow
to pass onto http://8055. And if I run within my network (ie I don’t use https://1.2.3.4:8555 but use https://vm-name:8555) then that works.
But (and we at last get to the problem), if I use https://1.2.3.4:8555 (so go straight to the backend for testing) then firefox gives me SSL_ERROR_INTERNAL_ERROR_ALERT but not much useful information on that.
In Edge it gives
The connection for this site is not secure
78.150.84.100 sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
So in summary, I know I can use vn-name:8555 in the Caddyfile. Can I use ip-address:8555 - will that work?
4. Error messages and/or full log output:
The only info in the caddy log is where I reload the log.
The protocol error occurs when Caddy receives a HTTPS request for a site it isn’t configured to serve. It isn’t managing a certificate for that site (1.2.3.4), so it simply doesn’t offer the client a certificate at all. This presents as a protocol error.
To have Caddy manage a certificate for both, so that it can accept requests for either, add both addresses to the site block, e.g.
Hi @Whitestrake,
still having problems.
I changed the Caddyfile to
log default {
output file /var/log/caddy/wolfsberg.json
format json {
time_local
}
include http.log.access admin.api
}
}
vm-name:8555, 1.2.3.4:8555 {
# Another common task is to set up a reverse proxy:
reverse_proxy localhost:8055
tls internal
}
Open port 8555 on the router and try http://1.2.3.4:8555 in firefox and get
Secure Connection Failed
An error occurred during a connection to 78.150.84.100:8555. Peer reports it experienced an internal error.
Error code: SSL_ERROR_INTERNAL_ERROR_ALERT
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
But https://vm-name:8555 does work - accept unknown certificate and then directus appears.
I just want to add that if I use https:1.2.3.4:3000 (or use vm-name instead) which will then call port https:8555 to get the dynamic data from directus listening on http:8055 then data is not retrieved. In the firefox browser console, I get
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://1.2.3.4:8555/items/articles?fields[]=*&fields[]=author.avatar&fields[]=author.first_name&fields[]=author.last_name&fields[]=fred&filter=%7B%22membersOnly%22:false%7D&sort=-publish_date. (Reason: CORS request did not succeed). Status code: (null).
Uncaught (in promise) Error: Network Error
Trying to access an https resource that has an invalid certificate will cause this error.
Trying to access an http resource from a page with an https origin will also cause this error.
And I am doing both of these things. So is my set up not going to work because I have a browser retrieves the frontend, runs javascript to get dynamic data over the network which is https with an invalid certificate?
This happens whether I go outside of the router (so use 1.2.3.4) or use vn-name.
Just to be absolutely sure, here, could you confirm…
Is 78.150.84.100 equal to 1.2.3.4 here?
The hostname you type in the browser address bar must match the site address you write in the Caddyfile.
If CORS is involved, your prospects are dim for getting this working. The entire purpose of CORS is to make this kind of hackery very difficult or impossible - to protect clients from insecure systems.
To make things easy here, what you want is for all requests to go through Caddy, including requests for the backend, so that Caddy can put HTTPS up in front of it all. That might involve some configuration of your frontend to point subsequent backend requests at the right place, but I’m not familiar with the app in question.
Also, you might want a valid, trusted certificate, rather than a self-signed one. That would neatly preclude IP address targets, as you can’t (easily) get a publicly trusted HTTPS certificate for these.
Hello @Whitestrake,
So much for my cunning plan to hide my external IP address!! Fortunately it does change on a regular basis.
And 1.2.3.4 is quicker to write.
The front-end does point to caddy for the backend (either https://vm-name:8555 or https://1.2.3.4:8555) and those values are in the directus env CORS_ORIGIN value.
I know this works using http for both ends but then it only works with Edge (which warns but doesn’t forbid) whereas Firefox forbids sending user input over http.
Getting a proper certificate rather than self certificate is a good idea.
I think another thing I need to do is create a table of what works and what doesn’t because it is all getting rather messy.
If this is the case, we should expect zero instances of this:
Since both the frontend and the backend are accessed via HTTPS, via Caddy. That also knocks out the CORS issue with accessing HTTP resources from HTTPS origins. That leaves you only with the issue of getting a valid certificate for your site, which means, hopefully, getting one should see you with a working setup?
Having investigated further, I suspect that https is not going to work with my setup. svelte will deliver the https but the browser will not allow directus data to be fetched via https delivered via caddy with an internal certificate.
Caddy does work for accessing directus directly.