CIDRAM login page – access denied!

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. 🙂

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.