Page 1 of 1

Issue with af_readability

Posted: 20 Nov 2015, 12:58
by xtaz
Since the last commit to clean up the curl hacks I've noticed that af_readability doesn't seem to be working. All my feeds which used to have it enabled are now just showing the real feed contents and not the readability parsed version. Has a bug been introduced there?

Re: Issue with af_readability

Posted: 20 Nov 2015, 13:10
by fox
af_readability seems to be working fine here. are you running w/ open_basedir restrictions enabled?

this is the only change to the plugin in the cleanup changeset, not sure why it could be broken now:

Code: Select all

diff --git a/plugins/af_readability/init.php b/plugins/af_readability/init.php
old mode 100644
new mode 100755
index cfdcb69..6216d51
--- a/plugins/af_readability/init.php
+++ b/plugins/af_readability/init.php
@@ -106,8 +106,7 @@ class Af_Readability extends Plugin {
                        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
                        curl_setopt($ch, CURLOPT_HEADER, true);
                        curl_setopt($ch, CURLOPT_NOBODY, true);
-                       curl_setopt($ch, CURLOPT_FOLLOWLOCATION,
-                               !ini_get("safe_mode") && !ini_get("open_basedir"));
+                       curl_setopt($ch, CURLOPT_FOLLOWLOCATION, !ini_get("open_basedir"));
                        curl_setopt($ch, CURLOPT_USERAGENT, SELF_USER_AGENT);

                        @$result = curl_exec($ch);

Re: Issue with af_readability

Posted: 20 Nov 2015, 13:17
by xtaz
I am running with open_basedir enabled yes. But it does include the whole directory that tt-rss is in and the /tmp directory. open_basedir = "/usr/local/www:/tmp". I'll try disabling it and will see what happens.

Re: Issue with af_readability

Posted: 20 Nov 2015, 13:22
by fox
it's not really the issue with directories you allow, problem is it forbids curl from following any http redirects, which is why the really horrible hack was in place previously. why? i have no idea

so it's either not enabling open_basedir (personally i think its its a useless kludge which provides false sense of security, much like safe_mode was previously), not using curl (define NO_CURL in config.php), or getting used to tt-rss not following http redirects.

i can add a separate check into af_readability to disable content-type checking if open_base is enabled but it can easily lead to tt-rss downloading a huge-ass jpeg file or something like that and trying to feed it to readability libraries which may produce suboptimal results, at least used-traffic wise.

i think i'll link this post in the faq

Re: Issue with af_readability

Posted: 20 Nov 2015, 13:25
by xtaz
Ahhh interesting. I have previously seen feeds randomly fail and when you read why it failed it says something like 302: forbidden. Then when you press f-r it loads the feed fine. That might explain that then? Maybe I will just leave it completely disabled then!

Re: Issue with af_readability

Posted: 20 Nov 2015, 13:35
by fox
the previous implementation, being a shitty hack, might not have worked at all times, yes

latest commit should allow to get af_readability to work (well I hope) by force-disabling CURL although imo CURL is more valuable than open_basedir

the choice however is yours

Re: Issue with af_readability

Posted: 20 Nov 2015, 13:56
by xtaz
Yep thanks for the advice. I'm just going to leave open_basedir disabled. I ran for years without it with no problems, it just causes problems, and the fact I have /tmp as one of the directories probably makes it pointless anyway. And yes, disabling that means I am now getting full feeds again. So problem solved!