Maikuolan

No worries; Happy to help. And done. ??

From the front-end updates page, look for “Quic cloud compatibility module”, select “Install + Activate“, and press “OK”. After that, it should all be handled automatically.

Based on what they mention at their docs:

This is not a set-it-and-forget-it kind of thing. In order to optimize global performance, we add and remove nodes frequently, which means the list of IP addresses also will change frequently.

..I wouldn’t recommend adding static rules for any specific ranges or specific IP addresses of theirs anyway, as they’re basically saying those ranges and IP addresses are going to change over time, which means those rules will quickly become outdated, and in need of updating on a regular basis.

Instead, seeing as they’ve conveniently provided a list to specify which IP addresses they’re using at any given time (the list you’ve linked to there), the best approach, I think, would be for me to write a module to handle it all automatically. I’ve already created a similar module in the past for BunnyCDN, so the framework for creating such a module for Quic cloud is basically already there.

I’ll make a start on it tonight, and depending on how it goes, have it ready either tonight or some time tomorrow. I’ll reply back again once it’s ready. ??

Hi,

The easiest way to prevent a specific IP address being blocked would be to whitelist that IP address via an auxiliary rule.

From the auxiliary rules page at the CIDRAM front-end:
1. Click the “Create new rule” toggle to display the controls for creating a new auxiliary rule.
2. Enter a name for the new auxiliary rule.
3. From the auxiliary rule action menu, select “If the following conditions are met, whitelist the request.”
4. At the provided condition line, at the condition source menu, select “IP address”, and at the condition value field, enter the IP address to be whitelisted (the attached image shows as example).
5. Click the “Create new rule” button (all the other fields/menus/etc provided at the page can be ignored for now, as they won’t be needed for this specific rule).

Once done, CIDRAM shouldn’t block the IP address anymore. For any IP addresses already recently blocked (e.g., the specific IP address of concern in this case), be sure to also clear said IP address(/es) from the IP tracking page if/when listed there. ??

The easiest way to whitelist your own IP address would be by creating an “auxiliary rule” via the auxiliary rules page provided by the CIDRAM front-end. ??

Once you’ve gained access to the front-end and visit that page, you’ll see some clickable text labelled “Create new rule”. When you click on that, some fields will appear where you can enter your IP address and specify the appropriate action to take when CIDRAM encounters it (in this case, to “whitelist the request” when the “conditions are met”, the condition being that the request originates from your IP address). There’s a lot else that can be done from that page too, but for just whitelisting, most of the options and fields provided there won’t be needed.

If there’s a cache.dat file located in the base of CIDRAM’s vault directory, that’ll be the file containing the tracking information for login attempts (alongside any other temporary caching, statistical information, etc). Deleting that file outright should immediately restore access to the login page.

If the file doesn’t exist, it could be the case that CIDRAM has detected the availability of a supported caching mechanism (e.g., APCu) and has opted to use that instead of file caching. If that’s the case, to restore access to the login page, you’ll need (in order of most-to-least tedious) to either (1) delete the specific cache entries responsible (if the caching mechanism used provides some kind of interface of its own, most likely using that, or, if not, it might be trickier as you’d likely need to interact with its API using code), (2) restart the cache mechanism (typically achieved by restarting the PHP process, as most such caching mechanisms typically interact with PHP via PHP extensions), or (3) wait 24 hours for it to expire by itself.

The code responsible for creating the cache entry which triggers the “Maximum number of login attempts exceeded” message, blocking further login attempts, sets the expiry/TTL for that cache entry as 1 day from its creation time, as long as the login endpoint isn’t being continuously hammered after the default maximum number has already been reached (e.g., by bots, which mightn’t realise they’ve been blocked from logging in and might keep trying anyway), or, for when that occurs, sets it as 1 day multiplied by the number of additional attempts.

Hi ozguy,

The default username is “admin”, and the default password is “password” (the login credentials for the CIDRAM front-end, just as it is with ZB Block, are specific to CIDRAM, aren’t related to the WordPress login credentials, etc). You can log in with that default username and password, and once logged in, can change the username and password using the “Accounts” page provided by the CIDRAM front-end. ??

Checking over it all, though it’s been mentioned elsewhere, I notice now that I haven’t mentioned about the default username and password under any of the WordPress-specific documentation for CIDRAM or at the plugin installation instructions. I’ll set a reminder for myself to fix that prior to the next release.

Good luck, and let me know if there are any issues. ??

Steps taken sound good so far. :+1:

Have you also populated some values into the “phpmailer” configuration directives at the configuration page? If anything needed from there is missing (e.g., phpmailer?host, phpmailer?username, etc), that could potentially cause 2fa to not work properly.

• This reply was modified 11 months, 3 weeks ago by Maikuolan.

In your wp-content/plugins directory, check for a cidram-configuration.yml file. Because WordPress replaces a plugin’s entire directory when updating plugins, if a plugin has any modified/customised files, there’s a risk of those modifications/customisations being lost as a result of updating through WordPress; so, in order for CIDRAM to avoid losing its configuration data (in the past, this was a problem), when operating as a WordPress plugin, recent and current versions of CIDRAM create a copy of the CIDRAM configuration file to that location. The strategy seems to work well for its intended purpose, but also means that when uninstalling/reinstalling the plugin entirely, configuration data from the plugin’s previous installation may potentially still be lingering in that directory. For a fresh reinstallation, deleting that specific file should remove any lingering configuration data from the previous installation (doing so shouldn’t break anything; CIDRAM will automatically recreate the file the next time it executes, with fresh/default data).

• This reply was modified 11 months, 4 weeks ago by Maikuolan. Reason: Better phrasing

Hi @kbliang,

I’ve pushed some changes just now which should solve the problem. If possible, from the front-end updates page, try updating to the latest available version (3.5.0-DEV+233360).

If not possible (i.e., due to 2FA already being enabled, and no available front-end account without it), if you edit your CIDRAM’s configuration file, look for the line enable_two_factor: true and change it to enable_two_factor: false, that should disable 2FA for your CIDRAM installation (you can reenable it again from the front-end configuration page after you’ve successfully logged in and updated).

After updating, try reenabling 2FA. If the problem persists, let me know. ??

Hi @kbliang,

Thanks for letting me know about this problem. I’ve been able to replicate the problem at my side, and can confirm, there seems to be a bug in the code. Investigating potential solutions now. I’ll reply back again when I progress a little further. ??

Thank you for the explanation and clarification, @aguinaldodarla. ??

@babylon1999 Please see: ToAC0g.jpg (1281×1041) (snipboard.io)

Hi @webtesher.

The issue should now be fixed (commit a83e933) ??

CIDRAM installations can be brought up-to-date early (e.g., when some kind of bugs like this have been fixed, and we want to patch our installations with the fix, but development isn’t quite ready just yet to have a new version/release tagged here at www.ads-software.com right away) by updating via the CIDRAM front-end updates page.

If the issue persists, please let me know.

Hi @webtesher.

Firstly, I apologise for the delayed response. It seems that the ticketing system here doesn’t notify me when there are new support tickets, for some reason. I saw this new ticket only per chance today when checking manually.

I’m investigating this issue right now, and I’ll reply back again shortly.

so where are the controls an logs located

Logs and controls can be accessed via the front-end (which is why you need the front-end, but also why you don’t want anyone other than yourself being able to access it).

Hi does this system/plugin still work

Yes. ??

When installed correctly, it should block requests in accordance with how CIDRAM is configured, its installed signature files, modules, etc. There is an “IP testing” page available at the front-end to simulate requests from various IP addresses, user agents, etc, in order to test whether a request would or wouldn’t normally be blocked.

Non-blocked requests shouldn’t normally see anything different than usual, and so, as long as someone is not blocked, it’s unlikely they would even notice whether CIDRAM is installed at all.

• This reply was modified 1 year, 8 months ago by Maikuolan.