Support » Plugin: Pareto Security » uninstalled

  • Resolved alx359

    (@alx359)


    Been using PS for a few days. Had to uninstall it unfortunately, because it messes up with other plugins without giving proper notice.

    Missed about half a day of work yesterday trying to figure out why a plugin extension I was coding through their local API was’t producing the desired result. In other case backend form elements just disappeared.

    The PS log in both cases stayed SAFE.

    I like PS aim for simplicity and activate-and-forget approach. It isn’t good though when stuff gets crippled without proper logging to the usual channels one monitors (debug.log). IMHO, it should be a “verbose” mode, where each stopped “attack” gets a detailed entry in a common log, so one could better figure out cause and consequence.

    Also, if some activity was deemed “safe”, why it’s changing the stream of data at all?

Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author te_taipo

    (@te_taipo)

    Thanks for that and sorry to hear about this. There is an update coming out shortly which may or may not address what you are experiencing. If you do try it out I would be very keen to hear about what those safe entries would have been about. They are likely records of false positives that would need to be addressed.

    I would also like to know if possible which other plugins had form elements disappear.

    – For the disappearing form elements: Enhanced Ecommerce Google Analytics. “General Setting” screen. There’s no event entry in PS at all.

    – The product where I get the access to their local API filtered is WP Tao. The test consisted on coding a custom event in php following their guide.

    – Also a false positive [HIGH] happened. A lightbox opening that contains the following piece of code in the url:
    [Notice] Request: ewdo=win_iframe/craft_prints-a3/motif_family (WP Admin IP).
    (At least here, the pertinent functionality seems to continue working w/o just being stripped.)

    As suggested, my main concern isn’t just getting those fixed. I wouldn’t feel confident leaving PS in a live environment, if stripping random stuff from the data stream is considered normal behavior, for whatever reason.

    HTH.

    Thanks.

    Plugin Author te_taipo

    (@te_taipo)

    – I have fixed the issue with the form elements. This was a clash with style sheets. Because this was a bug in Pareto Security in the way if loaded its style sheets, it was not blocking or stripping anything from the data stream.
    – There were a couple of black list items that would have caused the notices when accessing lightbox. The notice means that no action was taken. Those issues should now be resolved
    – I cannot see where there could be a conflict with the API requests. I have run some tests using the scenarios above and have not produced any errors.

    Hopefully this addresses these issues. Thanks again anyway for your feedback. Most valuable.

    I have fixed the issue with the form elements …

    Bugs are always understandable obviously. Perhaps I’m not understanding how PS works. What does PS do when it finds a threat? Does it just monitor the stream or also takes action? What recourse does the site admin has in such process?

    – I cannot see where there could be a conflict with the API requests…

    Installed PS again (2.3.8) and the API issue is still there (no entry in PS). What I failed to mention is there’s a premium popup plugin (Master Popups) that’s taking the user registrations and calling WP Tao API custom event I wrote. The popup works fine by meaning I get the emails for new registrations etc, but the API does not as it isn’t showing the pertinent entry in the WP Tao’s timeline. I’m aware you can’t make much of such fuzzy explanations, and a test environment is needed to reproduce the issue. I’ll try to help you out but need time to put a new instance of the website up for tests.

    Regards.

    Plugin Author te_taipo

    (@te_taipo)

    Pareto Security does not update/sanitise an input from a client. When a threat request is detected it first checks to see if the request was made by an admin, and if so it will not block the request. Even if requests are not blocked they are still logged, so therefore if there is an issue that is occurring that is not showing up on the log, then its likely a code clash.

    Yes please when you have a chance I would like to know.

    One extra thing you could try is to input the URL of the WP TAO API into the Domain Name Safelist (one per line).

    Was preparing the test env as promised, but can’t reproduce the filtered API issue anymore with the latest PS update (2.3.9).

    The lightbox false positive, and the disappearing input fields issues appear fixed too.

    I like PS approach and commitment, and gonna leave PS on live from now on. Shall report back if something else arises.

    BTW, I’m using WP Fastest Cache. Do I need to clear cache (page and/or mins) with each PS update?

    Thanks!

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