A post for caddy2 would be nice, you certainly are one of a few who have it down.
On my iframe load I’m getting:
[Error] Refused to load https://<sub-domain>.<my-domain>.duckdns.org/index.php/auth/logout?redirect_uri=/ because it does not appear in the frame-ancestors directive of the Content Security Policy.
Did I miss something in my header section?
yes you missed something. What is your Content-Security-Policy ?
Also show your iframe from configuration.yaml
This is in my headers, but I noticed that you have :XXXXX is that a literal *.domain.com:XXXXX or do you insert each port and the duckdns.org domain name in here for subdomain in this reference section?
Content-Security-Policy "frame-ancestors domain.com *.domain.com"
So would yours be:
Content-Security-Policy "frame-ancestors <my-domain>.duckdns.org:8123 *.<my-domain>.duckdns.org:7329 *.<my-domain>.duckdns.org:7115 etc..."
Thanks in advance
I have xxxxx as a placeholder for the port I use. It is the EXTERNAL port to access the subdomain, not the proxied one. Mine is identical to what I show below (except different port and domain)
So say I was using port 12345…
Content-Security-Policy "frame-ancestors domain.com:12345 *.domain.com:12345"
I assume you also removed x-frame-options? (you should have)
That was it, solved it - it looks like my webpage card and panel_iframes are all working both internal on homeassistant.local and externally on my duckdns domain simply sick!! Love that caddy2 works so beautifully across both!
The only weird thing is that I created subdomains and 1 out of 5 didn’t show up in the certs folder with its own unique folder, but the site still directs just fine - wonder why, though if it ain’t broke…anyways huge thank you to you and Berichta for pulling these configs together working on the add-on and presenting a clear method for getting these to work!
About 20 minutes later that folder apparently popped up, so problem solved - great thank you both!
I see folders here \debian\ssl\caddy\certificates\acme-v02.api.letsencrypt.org-directory for all my sub-domains…
Great you got it working.
Interesting enough, my iOS HA app and iOS safari were displaying everything perfectly- created some backups and now I can’t get those to pop up my iframes again on local network (although Firefox displays fine) I’ve reset cache both safari and HA, reset HA, reset router. It says the same content policy error, though I’ve made the changes and they’re persisting? Idk what changes to attempt - I was thinking of resetting the modem too? What other troubleshooting would you recommend?
different browser? Also make sure you aren’t banned ip…
I’m still getting this error when looking at safari:
[Error] Refused to load https://<subdomain>.<my-domain>.duckdns.org/ because it does not appear in the frame-ancestors directive of the Content Security Policy.
Doesn’t matter if I do either of these:
-Server
Content-Security-Policy "frame-ancestors https://<my-domain>.org https://<subdomain1>.<my-domain>.org https://<subdomain2>.<my-domain>.org"
Permissions-Policy "geolocation=(self), microphone=()"
or
-Server
Content-Security-Policy "frame-ancestors <my-domain>.org *.<my-domain>.org"
Permissions-Policy "geolocation=(self), microphone=()"
still getting this error, any clue?
The second one is definitely working for me.
Oh hang on…
On local network?
Is iOS app on local network using the local IP address instead of the domain?
Does it work when on 4G?
So at one point it had worked all around - in local Mac browser, in iOS on wifi network to local HA instance and also outside the network on 4G. Now it only works on wifi local through my firefox browser on iPhone to homeassistant.local and through the safari browser out to the https site - I suppose this is as intended, but odd that for a few hours there was a point that it was working universally; is this just my network sorting things out in NAT loopback redirections and cache?
Maybe.
See my iFrames WON’T load if I use debian.local:8123 or ip-address:8123 on my network but will connect if I go via https://domain:port. This is as expected since you can’t access a https iFrame (which is what my iFrames are configured for in configuration.yaml)
If I use my domain internally and externally everything just works as expected.
With the iOS app if it really bothers you, set the internal url to be the https domain.
This is all 100% the behaviour I expect to see.
Hi David, totally with you on using external domain. I’ve complicated my network, because - you know why not? I’ve added a Rpi server that sits and dominates 443 pretty hard, so I have moved my external domain port for HA and associated sites upwards to avoid port sniffers and this cross-talk. I’ve set up a port forward from domain.com:12345 to IP_address:443 and I’m now getting a blank page (no errors) from 4G network, any clue as to what is happening?
Caddyfile
{
email <my-email>@email.com
}
(common) {
tls {
dns duckdns {env.DUCKDNS_TOKEN}
on_demand
}
header {
Strict-Transport-Security "max-age=31536000; includeSubdomains"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
Referrer-Policy "same-origin"
-Server
Content-Security-Policy "frame-ancestors <my-domain>.duckdns.org:12345 *.<my-domain>.duckdns.org:12345"
Permissions-Policy "geolocation=(self), microphone=()"
}
}
<my-domain>.duckdns.org:10100 {
import common
reverse_proxy localhost:8000 {
}
}
<subdomain1>.<my-domain>.duckdns.org:12345 {
import common
reverse_proxy localhost:7777 {
}
}
<subdomain2>.<my-domain>.org:12345 {
import common
reverse_proxy localhost:8888 {
}
}
Why are you proxying from 10100 to 8000? Is your HA listening on 8000? Do you have 10100 forwarded to 443 as well? I think you would need 10100 and 12345 forwarded to 10100 and 12345 in your router… Pretty sure that is how I had it setup. In my case I use IPv6 only (only an AAAA record for my domain) so I don’t port forward I just open that port to the device. But the way you have it written I’m pretty sure you need 10100-10100 and 12345-12345. But gotta say I have no clue why you would complicate things like this.
That did the trick! Thanks David!
How easy is it to setup Caddy compared to NGinx, and does Caddy have better reliability?
Hi @hazio,
Configuration-wise, from my own experience, Caddy is much simpler in comparison to NGinx.
This also has to do a lot with meaningful and secure defaults, which come by default.
If you want to check yourself, just have a look here.
With regards to reliability, that’s a different question. Caddy is programmed in GO, which adds some adventages itself. I am talking here about no dependencies, memory safety, etc.
In the wild, I assume, you may still find more NGinx installs, as it is considered the standard?
If in doubt, just give it a try. There are plenty of examples here, on the Caddy webpage or on the Caddy forum.
Hi @DavidFW1960,
I also found some browser console errors, but different. My browser was complaining about the URLs, so I changed that line in my header into:
Permissions-Policy "geolocation=(self 'https://domain.com' 'https://*.domain.com')"
I am still testing variations. Will let you know once I have new details.
One question in between, do you need the microphone in particular, or not? Why is that listed in your example?
HA will access to microphone (see this microphone icon in the top bar) so I assumed it needed that permission. It doesn’t seem to work though so I don’t know. I think I changed mine to include those quotes before.