Locked yourself out of your MODX manager? Don't worry, we'll break in for you.
There are several ways to lock yourself out of MODX, other than blocking your own user by entering the wrong password over and over again. Sometimes passwords aren't the issue and here's how to fix the most common of those mistakes.
Methods with DB access
If you have access to the database, you can use a few quick methods to get back in. Most of them are just dummy mistakes that are very common and very likely to miss, because MODX handles global system settings and context settings in a similar way. So this is where you could have gone wrong.
Anonymous Sessions
Switching off anonymous sessions in the system settings is the first very common mistake people can make. So, make sure that anonymous_sessions are switched on in your modx_system_settings table. So what does this do and why might this be the reason for it? Glad, you asked:
Unless you run a shop site or anything where you need to recognize your user - so let's say you store certain information in the PHP session, such as their cookie settings or their anonymous user id because they're in your shop and you need to remember what shopping cart belongs to them, you need anonymous sessions to be switched on in the context - but if you don't do that, this might give you a speed and memory advantage. Meaning it might speed up your instalation quite a bit. But what people need to do is update the setting in the context and not globally in system settings. If you set this to false in system settings, your admin user will not get a session from the system because basically you told MODX "I don't do PHP sessions" - and that's why it will not give you a session for the MODX manager.
Try switching this on first in case you switched it off. MODX default is to have this setting switched on. So if you find it has been altered, there is basically zero risk of messing things up if you switch it on.
Session Cookie Domain
This was a tricky one and also the reason for us to write this article. We migrated a site to a new system and it didn't let us login to the manager. Everything was set up correctly, It just didn't want to give me a session for whichever reason. It was quite hard to find, so we did some digging. In the end, session_cookie_domain was set to the main sites domain. So why did we do this? A multi-context site that has multiple domains for let's say languages or separate parts of the site needs to know which domain "owns" the cookies. And that is supposed to be a single one, otherwise you have multiple sessions for just one visitor.
Make sure that this domain is the site you are running on. For us, the problem was that is was set to client-domain.com and we moved the site to another system under client.lux-medien.com to upgrade it. We did some testing first, so we tried to login to the manager to check if everything is working. It didn't let us in. No error message, no nothing, HTTP 302 and that's it.
So what we needed to do is set session_cookie_domain in modx_system_settings to null. It was set to the actual domain. MODX was unable to create a cookie for us, so this was the reason. Much like the above this might have been solved by moving this setting to context settings, but we haven't tried that.
We could have set it to the temporay client domain as well, but we didn't. We just needed to get in first and after migration we set it back to the live domain.
Sessions Table
A lot of times it helps to clear the session table. It's a mess in the database and everything is stored there, but for the most part those sessions aren't critical to the system. So let's say something has changed, for example your user role, a permission sprofile, etc. - This stuff is part of the sessions table, and if it's wrong, let's get rid of it to make sure that you're not working with erroneous data. You might up fixing things that have already been fixed.
Out of luck? Let's use the crowbar then.
Breaking into MODX
For this method you need filesystem access. So what you are going to do is create a user, you'll add them to the Administrator Group and you will start a session with the mgr context for that user straight away. This is your last resort and it shouldn't be your weapon of choice. This is the method you use when all else fails.
So here's what you're going to do.
- Create a PHP script in the webroot and give it a name like letmein.php
- Copy the code below into it
- Adjust username and password setting to your needs.
- open yourdomain.com/letmein.php
Evil hacker code:
<?php
// Include MODX core configuration
include_once 'config.core.php';
require_once MODX_CORE_PATH . 'model/modx/modx.class.php';
// Initialize MODX
$modx = new modX();
$modx->initialize('web');
// Set up the user credentials
$username = 'modx_admin';
$password = 'change-me-to-something'; // Change this to a secure password
$email = 'admin@something.com';
// Check if user already exists
$existingUser = $modx->getObject('modUser', array('username' => $username));
if (!$existingUser) {
// Create a new user
$user = $modx->newObject('modUser');
$user->fromArray(array(
'username' => $username,
'password' => $password,
'active' => true,
));
// Create a user profile
$profile = $modx->newObject('modUserProfile');
$profile->fromArray(array(
'email' => $email,
'fullname' => 'I am root.',
));
$user->addOne($profile);
// Save the user
if ($user->save() === false) {
echo "Failed to create user.";
exit;
}
// Assign the user to the Administrator group
$member = $modx->newObject('modUserGroupMember');
$member->set('user_group', 1); // 1 is the ID for the Administrator group
$member->set('member', $user->get('id'));
$member->save();
$existingUser = $user;
}
// Log the user in
$modx->user = $existingUser;
$modx->user->addSessionContext('mgr');
// Initialize the manager context
$modx->initialize('mgr');
// Redirect to the MODX manager
header('Location: ' . MODX_MANAGER_URL);
exit;
?>So what now?
The script above will log you in with a live user it just created. Make sure you delete it after fixing what you needed to fix. Also delete the user you created along with it. You should do a full backup of your site, then do a full upgrade of the site to see if you have accidentally messed with core files. You should also check out permission profiles and if they are still up to date.
If this also does not work, it will very likely be a session issue and you should try to revert to detault settings.
Default MODX Session Settings
These are the default Session and Cookies Settings in MODX. Stick with them and revert to them if anything has been tampered with. They might have been changed for a reason, but in order to you to get back in you should try this first.
If none of those methods work, talk to the MODX Community on Slack or send us an email. We can get you back in and give you an estimate.
If we don't succeed, we won't charge you.
4 MODx Packages you don’t want to miss out on
Sometimes you do what everybody else has been doing and end up doing it wrong or in a very inefficient way. This happens with MODx all the time.
Pretty-printing SOAP messages in jax-ws
Since you need to write our own additional handler to solve this, I thought I'd publish this little piece of software to the public, even if it's tiny.
Locked out of MODX manager - and how to solve it
Every once in a while you will lock yourself out of the MODX manager. This might happen due to an upgrade, a service migration or just because you haven't logged in in a while and you don't really know what's going on. Here are the most common ways to solve these issues.