Support » Plugin: WPeMatico RSS Feed Fetcher » Uncaught Error: get_columns() on null

  • Resolved kbatdorf

    (@kbat82)


    Hi,

    We are getting this error on more than one of our sites after a recent update:

    Uncaught Error: Call to a member function get_columns() on null in /plugins/wpematico/app/settings_page.php:92

    I’m guessing it’s from this:

    <div id="post-body" class="metabox-holder columns-<?php echo 1 == get_current_screen()->get_columns() ? '1' : '2'; ?>">

Viewing 12 replies - 1 through 12 (of 12 total)
  • Plugin Contributor manuelge

    (@khaztiel)

    Hi kbatdorf,

    We want to help you solve this problem, please create a ticket in our support system and attach the Debug File from the plugin.

    You can find it and download from your WordPress admin, WPeMatico, Settings, System Status tab ->Debug Info

    If you can include the campaigns logs by checking the checkbox field before download the debug file.

    Regards,
    Manuel

    Hi Manuel,

    I submitted the ticket under the account [ Deleted email, don’t post that again please ]. We have a few websites set up and are getting the same error on each site. Thanks

    • This reply was modified 4 months, 3 weeks ago by Jan Dembowski.

    Just to report that this function …

    > You can find it and download from your WordPress admin, WPeMatico, Settings, System Status tab ->Debug Info

    … is dangerous (particularly when no warning is given in the plugin or in the support channel as to its implications). We looked more closely at what it contained after it had been sent in. It contained various of our secret API keys in the full dump of all PHP constants loaded in WordPress. There surely should be a warning somewhere. We had to revoke and replace them all.

    I’ve marked this topic as “modlook” because the WP plugin team asked me to do so, presumably so that an official opinion can be given on this feature.

    Plugin Author etruel

    (@etruel)

    Hi @davidanderson,
    Thank you for your report. All information that reveals system data is dangerous.
    Although we filter all WordPress security constant data and also the screen shows the content of the file to be downloaded, this should only be used for private custom support for a developer you trust.

    @kbat82 we already fixed that issue and is in our development repository until the release in a few moments.

    thanks!

    It is not true that all system data is dangerous – suggesting that genuinely useful debugging information (like WP version, PHP version) is equivalent to private/secret keys is false. (Plus, if you believe all the information you’ve asked for is dangerous, you should explain this to the people you’re asking it from beforehand, which you did not do here and the plugin does not say either; it merely describes it as “debugging information”, which Kevin took on trust as accurate).

    Furthermore, there are *no* reasonable circumstances under which you anyone should even ask to be trusted with (potentially) a customer’s secret API keys. You should entirely remove the code that includes those, and only grab a fixed list of constants whose meaning is known and has no security implications. No rational site owner would give such information to a third party. How can we know what security procedures you have, where you store such data, what risks it might face? Why would we even want to spend time making that assessment? As I say, the very act of asking for such data is a breach of trust.

    Please understand my point. The secret keys are now useless – we have recycled them; they are no longer the point. But you need to improve your security practices. What you have done is explicitly forbidden by the forum guidlines – https://wordpress.org/support/guidelines/#the-bad-stuff – you are not permitted to ask for information that (potentially) includes private credentials, whether you ask it to be posted here or sent off-site.

    Did you remove the “modlook” tag? I was asked by the wordpress.org plugins team to add it so that they can review this. Only they should remove it, once they have done so.

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    *Reads. Removes modlook tag.*

    All information that reveals system data is dangerous.

    That’s not even remotely true.

    Although we filter all WordPress security constant data and also the screen shows the content of the file to be downloaded, this should only be used for private custom support for a developer you trust.

    @etruel What exactly are you getting when you ask for that debug info? Please don’t make me look at the plugin source to answer that question.

    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    @etruel Please do not ask users to go off site for support. Keep it here, users are not your customers.

    The thing that caused us an issue is that it includes *all* defined PHP constants, minus a fixed blacklist (e.g. database password, DB_PASS). So, if the site has any other secret credentials defined as PHP constants (we had several), they’re there in the debug information.

    (The other contents, in which I did not find anything I believed to be security-sensitive (though one might wonder what use there is for things like the IP address of the MySQL server), was basically anything you can think of: versions of everything, Apache modules, PHP environment settings + extensions, browser details, various WP settings, the plugin’s own settings, list of all installed mu-plugins, versions + update availability of all installed plugins + themes, a full list of inactive plugins, complete list of cron tasks + schedules).

    Plugin Author etruel

    (@etruel)

    Hi @jdembowski,

    That’s not even remotely true.

    Yes, you’re right, it’s a very ambiguous phrase.

    Below I explain the content of the file.

    We never refer any user to the site unless he is a previous customer or we can’t solve his problem without revealing data. As in this case. @kbat82 got these weird errors because his site was trying to be hacked.

    WOW before continuing, I want to apologize to David, we have been victims of many attacks by users with other personal interests. And I thought David was just another one. He appeared within a support topic for a third person and I didn’t understand.
    Recently I was able to see his experience and profile on WordPress. I see I can learn a lot from him. 🙂

    For a couple of weeks we have been working very hard on the plugin, (you can see the releases so often) securing many things in the code by advice from moderators of wordpress plugins.
    We have a list of their tips for which we are improving and renewing the code.

    Last night we released a new version with more security enhancements that included this extra Warning that David suggested in his first message.

    The idea of this debug file we have copied time ago from other plugins such as EDD or Awesome Support and some others, which use it to debug quickly and successfully most of the problems. (We try to copy the big ones) And by which we can help many users who have problems with their bad configurations in WordPress and servers.

    That information in the file are the defined user constants that may be relevant for debugging, but removing the sensitive values defined in wp-config.
    The entire file is showed in a textarea before the user can download it.

    If you need the code I could copy paste o refer to where it is, but I don’t think that this topic is the right place.

    Anyway we will put a deactivated checkbox to not include this unless the user specifically wants it.

    I hope this clarifies things better and if there is any problem we will make our best to solve it.

    [ Signature deleted ]

    • This reply was modified 4 months, 3 weeks ago by Jan Dembowski.
    Moderator Jan Dembowski

    (@jdembowski)

    Forum Moderator and Brute Squad

    Unrelated: I get that online translators are often needed but don’t post the link to that one. That’s a form of spam.

    If they need that link, which I’ve removed, then use a different translator.

    Thank you for the kind words and the wording changes.

    I must say that in my opinion, though, this is not enough:

    That information in the file are the defined user constants that may be relevant for debugging, but removing the sensitive values defined in wp-config.
    The entire file is showed in a textarea before the user can download it.

    You remove a blacklist of “known sensitive” values, because you know that sometimes constants have secret information in them. But, the blacklist will often not contain them all. Requiring the user to audit all the information is a poor use of everybody’s time. Only experts are capable of understanding the contents of PHP constants. Also, many sites may have people with access to manage your plugin’s options who aren’t meant to be able to extract secret keys – and so they shouldn’t be allowed to read them in the debug information. Few site owners (such as myself) would understand that allowing user X to manage WPeMatico options actually means allowing them to read all the site’s secret API keys. Not all sites are owned/managed by a single all-powerful individual.

    Remember that for some secret API keys, that gives access to all data at a third-party service. EU privacy laws require site owners to audit and control things like that, and make a data protection assessment. This is all so much trouble. You really should just have a “whitelist” approach instead of a “blacklist” – just grab the constants you know are needed. If later you find your whitelist was too short, you can add the missing ones. But grabbing everything and telling the user to audit it himself should not be done, with constants, variables, server RAM, or anything of that sort.

    Plugin Author etruel

    (@etruel)

    Hi @davidanderson,
    Thank you for taking the time to write this all down.
    This clarified many more things.
    We will follow your advice. We are currently working on this to make a white list for the next version.

    Thanks again

Viewing 12 replies - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.