Closed Samurai336 closed 8 months ago
A few more details, if I connect via it local ip (192.168.x.x) with http it has no problems given I've disabled the forced https setting in invidious its self.
Thanks for opening the issue.
This looks a bit strange, since other instances that use let's encrypt (https://vid.puffyan.us or https://invidious.fdn.fr) work fine. Does major browsers (Chrome/Firefox) load your instance without any sort of warnings? I know there are tools to verify certs, but I don't know the best way to do that.
For what it's worth, we're validating certificates using the built-in CA bundle that comes with Roku ca-bundle.crt.txt
As a last resort, if you're really blocked and there's no way around it, I can perhaps disable CURLOPT_SSL_VERIFYPEER and/or CURLOPT_SSL_VERIFYHOST (maybe add a setting) but I would like to avoid this if possible
So no issues around the https in Firefox or Chromium browsers. I'm currently self hosting the instance from home with a DDNS and an nginx reverse proxy behind that, but that shouldn't be whats messing things up.
If you're a cool dude you can email or PM me and I'll give you the details to try things out on you end maybe you can see something I can't on your debugger.
Just don't want to put my server's details in the bug here. XD
Also happy Thanksgiving, this was a side adventure on my day off. :P
@Samurai336 I can take a look, you can use the web app to send me an email (in the app info tab) which will include your setting. That should help with replicating your setup
Ok email with details sent! Sorry it took me a day to get to it.
No worries! I've identified a couple of issues:
https://your-domain.com/api/v1/trending
, the urls of the thumbnails are in the format https://your-domain.com:PORT/vi/VIDEO-ID/maxres.jpg
, not the expected https://your-domain.com/vi/VIDEO-ID/maxres.jpg
. I believe this is because you are both behind a reverse proxy AND using external_port
. Removing the external_port
field should fix it.This server's certificate chain is incomplete. Grade capped to B.
. In comparison, testing https://vid.puffyan.us and https://invidious.fdn.fr for example, they both have a grade of A+. I'm not very familiar with this particular issue, but it looks like there are guides on how to fix it (example) - of course I'm not a 100% positive this is what's causing the issue, but it's the only difference I seeAs a last resort, if you're really blocked and there's no way around it, I can perhaps disable CURLOPT_SSL_VERIFYPEER and/or CURLOPT_SSL_VERIFYHOST (maybe add a setting) but I would like to avoid this if possible
For what it's worth, I've tested this with your instance, and while I was able to get video feed, but thumbnails were not loading properly, because I do not have the option to disable CURLOPT_SSL_VERIFYPEER
when loading images.
So the options are either to fix the certificate, or to use unsecure HTTP
I think I understand now, yes the way I have it set up is there is an reverse proxy handling all outside connections, my firewall is listening on 443, that forwards it to the reverse proxy listening on 4443, that then based on the incoming domain forwards is to the invidious instance on the local network over regular http.
Is this whats breaking things?
Ignore that, it was because I had the proxy using cert.pem and not fullchain.pem; because I am a dingus.
OK I fixed the certificate, Passed the test in the app, but the thumbnails didn't load, is that a caching thing will that go away eventually?
OK I fixed the certificate, Passed the test in the app, but the thumbnails didn't load, is that a caching thing will that go away eventually?
Ah, apparently yes, there's some caching of old thumbnails that are not valid. But I tested with your instance, and thumbnails show up. If you load something new (like a search) thumbnails should load for you.
I have added a couple of items to the roadmap: testing for thumbnails, and an option to clear the cache.
By the way, if you restart the device (not just turn it off, but restart from the settings) the cache should be cleared.
ok looks to be more or less working on my end. So thanks for walking me through that.
One thing I want to make a feature request on is I'd like to be able to basic auth my connection to my invidious instance.
the reason is so I can keep my instance personal/private from bots and scrapers and prevent randos from making accounts on it.
I can file a separate ticket for this and if you want test on my set up.
Thanks, feel free to open another issue. But I think this might not be Playlet related.
VPN is an option for myself, but my parents would not be able to figure out a VPN XD
When I try to connect to my invidious instance the connection totally fails. If I try to log in anyway it tells me it is unable to get the local issuer of the certificate. The certificate is a let's encrypt certificate so likely not the issue.
invidious settings `external_port', 'domain', and 'https_only' are set as recommended in their docs. I can access my instance in the browser at the proper domain no problems.
Unsure how to diagnose further.