bdolor

Hi Paul,

A fix was put in place about a month and a half ago, so I’m guessing you are using an earlier version?

https://github.com/BCcampus/pressbooks-openstax-import/commit/14b1eb8cab7b2ecde755c6c824761189952d17ac

If you are able to upgrade to version 1.2.1 that would likely remedy the problem.

It looks like you’re using Pressbooks 3.7.1 on that site. The latest Pressbooks version is 3.9.6. Pressbooks Textbook version 3.0.1 is made to work with the latest version of Pressbooks.

https://github.com/pressbooks/pressbooks/releases

Starting with version 3.8, Pressbooks stopped using the WP repo to deliver updates to the code base and now releases updates via Github. In order to receive updates to Pressbooks through the WP admin interface, instructions are to use the WP plugin Github Updater: https://github.com/afragen/github-updater

https://github.com/pressbooks/pressbooks/releases/tag/v3.8.0

There have been a lot of changes to both the code base and server dependencies since PB 3.7.1

https://github.com/pressbooks/pressbooks/blob/dev/docs/installation.md

If you are not currently in a position to update Pressbooks to 3.9.6 I would roll back your version of Pressbooks Textbook to 2.7.1

Hi Rowena,

thanks for reaching out. On the book that you provided a link to, it looks like your theme is currently set to Luther? Were you previously using the Open Textbook Theme?

Thanks, just bad timing – closing

Ah, I see you are not a troll, just a misinformed noob. There is no paid customer service associated with this plugin. It is not a ‘product’ and there is no ‘service’ to be had beyond what you bring to the table. Poor guy. I don’t know who you were talking to, but it was no one associated with this plugin. You’re confused and flailing about for all to see. Thanks for the tip on attitude though — yours is a shining example.

I’m done here. All the best!

Hi,

you sound like a troll, and not like someone who actually wants help.

I see that you’ve recently posted an inflammatory comment on another eBook plugin:

Sorry about your luck. Hope you get the response you’re looking for absolutely nowhere.

Hi,

There are no explicit conditions in the code that would produce the effect that you are describing. Existing/non-existing chapters in the book that you are importing into have no bearing on what gets filtered for search/import. Search results get returned if the book/chapter is marked as ‘public’, if the search term is found in the book/chapter title and if the book/chapter license is not ‘all-rights-reserved’. Those are the only conditions that are necessary. Importing chapters requires only that you mark the book/chapter for import and hit ‘Start’.

If you are getting any error messages or can describe what can be done to recreate the behaviour I can look into it further, but right now I can’t think of anything that will be helpful to you besides confirming that this is not how it works on my system, nor was it a specific design decision.

Hi @bseeger,

thanks for identifying an issue. Moments ago, I put in fix for this.

https://github.com/BCcampus/pressbooks-textbook/commit/a18bb8f5ee619d1ccc3f607b7307b11ffbc53c26

I will be pushing out an updated version to the WP repo soon.

2 months later…we find the source of the problem to be unrelated to this plugin.

The default settings of our f5 (BIG-IP) appliance/load balancer which sits in front of Apache on our network does not always preserve source IP addresses. A blast of HEAD requests from a ‘bad IP’, probing for the existence of known WP vulnerabilities, triggered the f5 to share an open TCP connection to our machine with another client. Hence, the false positives detailed above. It is all here in the f5 documentation.

I understand the efficiency aspect of this ‘feature’, but why it’s desirable to trade efficiency for accuracy in the logs is beyond me. At any rate, I wanted to mark this as resolved and document it here for anyone else who may come across it with similar issues.

Hey colomet, sorry you’re having trouble. I can’t help you with the very little amount of information you’ve provided about your problem. Typically, you’ll want to provide enough information so that others can re-create your issue, or be able to ascertain if it’s something specific about your setup. Providing error messages from log files is very helpful, for instance.

Please ensure that you read and follow the instructions at https://codex.www.ads-software.com/Using_the_Support_Forums if you want help. The part titled ‘Not Enough Information’ is relevant.

We do not sit behind a proxy server so you are correct in thinking it will not be relevant. As mentioned, Disable Proxy Detection is on/checked/enabled — we are relying on $_SERVER[‘REMOTE_ADDR’] to return an IP address when logging brute force attempts.

Thanks for letting me know. If it continues to be helpful while troubleshooting issues with get_ip() — After disabling the cache plugin for a week we see the same behaviour. I also disabled APC on the server this weekend. The problem persists. This should remove any doubt that the problem is either our server configuration or installed plugins.

What I continue to see in the access logs are 4 or 5 login attempts per second coming in from a malicious IP, one login attempt from our user, then more, rapid attempts from the same malicious IP. What I see in the database are 5 invalid/brute_force login attempts attributed to our user’s IP. The application seems to attribute the brute force behaviour to the wrong IP.

In most circumstances it is relevant to highlight that a plugin hasn’t been updated in a while, but in this particular case, I can’t imagine how it would play any part in why we are seeing what we are seeing.

thank you for your feedback, dwinden.

Thanks for running tests, although I do suspect that the rate at which the test logins are being attempted is generous, comparatively. The frequency of login attempts would need to tighten up to mimic what we are experiencing. That said, if this problem comes down to caching, this detail is a moot point.

Indeed, PHP is installed with the APC extension https://www.php.net/manual/en/apc.configuration.php and the APC Object Cache Backend is installed, which ‘provides a persistent memory-based backend for the WordPress object cache’.

By identifying that we are using a caching plugin, are we confident that this plugin is incompatible with object caching?

Thank you dwinden, for presenting a possible scenario. The only thing the two types of login attempts share in common is the time of the attack/attempted login.

My attempt at encapsulating the problem: A brute force attack launched from one IP gets interpreted as having come from two IPs. My proposal: It’s not actually happening; data recorded in the database is incorrect.

Reasoning that apache’s access_log is the source of truth, data in the plugin’s [prefix]_itsec_log table isn’t accurate. What we’re seeing is a host/IP lockout on both legitimate and illegitimate attempts.

On the server I see 5 login attempts from the ‘nefarious’ IP over a period of 8 seconds. A 200 status code is returned for all 5 of those login attempts. During that same 8 second period I also see 1 login attempt from the legitimate user coming from a different IP which also returns a 200 status code.

The plugin interprets that pattern as 5 invalid login attempts from the ‘bad’ IP (this is good) and 5 invalid login attempts from the legitimate user’s IP. We tried interpreting this literally; that the attack was indeed coming from our network and also from another foreign network, until we ruled it out by looking at firewall and apache logs.

On the server, over the next 20 seconds I see more attempts from the ‘nefarious’ IP to POST to the wp-login.php page, but a 403 status code is returned. I also see a 403 status code returned for the legitimate user.

Both the ‘nefarious robot’ and the legitimate user get locked out.