Provisioner seemed like a super cool add-on, until I got the access denied error and stumbled upon this thread. Nevertheless, before finding Provisioner, I did a sort of manual sync, because I’ve been doing a lot of editing on the live site, and completely ignoring the local copy. But since I needed to test some extensions and do other stuff, that could disrupt the live site, I needed the content and etc. back in the local version. So you can basically import almost all the tables to the local version except for modx_workspaces (contains a server specific path), modx_transport_packages and modx_system_settings (possibly contains server specific paths), because importing these will most break your install. This worked for me. Except for getting logged out of the manager ofc, because the session info is stored in the DB. Anyway, make sure to back up your original DB.
modx_system_settings contains some paths that are server specific and reinstalling all the extensions is just cumbersome. So I just excluded those tables since not many settings differed and was done with it. On the side-note: hardening (updates) of the MODx core is a good thing, so breaking an extension is just an unfortunate side effect. If I have some spare time, I’ll look into the source of Provisioner, maybe figure out a way to fix that login issue.
I’ll look into the source of Provisioner, maybe figure out a way to fix that login issue.
Its not the source, in a similar manner that Provisioner was updated to use the site id it now needs to use the site id + the session id in the auth header, you need to work out a way of doing this, maybe just run a snippet in the remote site that gives you this key(like the request handler code does) and then use this in the site id field in the Provisioner login. Note that with Provisioner you have to be a valid user in the remote site, so you have access to this data, you are not an attacker, the code update for 2.1.1 doesn’t take this into account as such, the prob is how can you automate this?
Use MODx, or the cat gets it!
Is it even possible? I mean you have to log in to get a session id, but you need it before you log in remotely, sounds to me like a closed loop problem. Wouldn’t the most secure way be just logging in at the target site and getting it, and then just paste it somewhere in the connection settings?
Yes, exactly, log in to the remote site through manager(you are after all a legit user), get the site id and the session id, go back to your Provisioner site and put this info into the site id field when you login, I’ve not tried this but this or some variant should work, the problem is its quite clumsy, using the site id wasn’t so bad as it’s in the config file but the session id is a bit harder to get.
Use MODx, or the cat gets it!
It’s not too bad either, sort of a two factor auth. I could try figuring this one out, if I knew which api method to call to get the required session id. Or is it just the phpsessid or whatever the session cookie is used by MODx?
From the above commit the code does this :-
$_SERVER['HTTP_MODAUTH'] = $modx->site_id.$modx->user->get('id').session_id();
whereas it used to do this :-
$_SERVER['HTTP_MODAUTH'] = $modx->site_id;
You just need to run a snippet with the first line above in and get the returned string, this becomes your site id in Provisioner.
Use MODx, or the cat gets it!
How about writing a snippet that encodes the key and places the encoded key on a page? Provisioner could visit that page, decode it using a private key set by the user or some other proprietary technique, and then log in.
