TT-RSS was recently updated to not download anything from localhost or any 127.0.0.0/8 IP addresses. Try using the network IP instead and see if it works.
If you can, put the internal server on a standard port (80 for HTTP, 443 for HTTPS), the fetch_file_contents function has been restricted to only downloading from those ports because of security concerns. I re-read the commit log and I think you can access tt-rss locally on any address/port combo, but it won’t download anything (including feeds) from servers that are not on a standard port.
I have tt-rss and rss-bridge in docker containers with nginx in front as a reverse proxy without any issues.
When subscribing to a feed I use the full domain and not the docker alias. The docker container resolves the domain as the server’s external IP address i.e. 10.1.1.100
short hosts are allowed, unless they resolve to loopback. URL hostname doesn’t have to be fully qualified. it has to be accessible for tt-rss, though. short hostname on a different docker network won’t be.
also,
this isn’t a validation related error. check your docker networking / firewall.
I face the same issue. I use a LAN IP address instead of the local loopback now.
For example in /etc/hosts:
192.168.60.59 myself-on-LAN
and then replacing any RSS subscription feed URL from http://localhost:1234/bridge.php[...] to http://myself-on-LAN/bridge.php[...]
Edit: By the way, I found out that using a host name such as “myself_on_LAN” (with underscore “_” characters) will make the “extended validation” fail (because of filter_var($url_filter_var, FILTER_VALIDATE_URL) so don’t use them in your /etc/hosts file!
Here is how to update the fields in Postgresql:
UPDATE ttrss_feeds SET feed_url = REPLACE ( feed_url, 'localhost:1234', 'myself-on-LAN' );
SELECT feed_url FROM ttrss_feeds; //Display the results
Obviously this assumes a reverse proxy has been set up to forward requests on port 80 to the appopriate port.
Example for nginx:
server {
listen 80;
server_name mylocalhost;
location / {
include proxy_params;
proxy_pass http://127.0.0.1:1234;
}
}
I find it a bit daft to have to hit a router/gateway in order to reach a locally hosted service (instead of going straight for loopback), but I’m no security expert nor sysadmin so I guess we have no choice here? Still very weird to me.
I set up tt-rss and RSS-bridge (rssbridge.userver.lan on a machine userver.lan with NPM installed) and both are working. When I am trying to subscribe to a feed from RSS-bridge, say,
Are you running both in Docker containers? Are you able to subscribe to Internet-based feeds? tt-rss doesn’t have anything to do with DNS resolution, so you may need to adjust something.