Configuring auth.remote plugin for mobiles

For those of you using the auth.remote plugin in slave mode with an external CMS like Drupal, WordPress or Joomla!, the RESTful access to AjaXplorer necessary to create a communication with the mobile (iOS / Androïd) clients is tricky, but should work. It’s all about setting the right configuration for the various MASTER_XXX options of the auth.remote driver (inside bootstrap_plugins.php).

Technical background : read it!

When accessing AjaXplorer through the web in an « auth.remote » configuration, the login action is never performed via AjaXplorer, but it is done via your CMS login form and your CMS triggers the necessary actions to log your users in AjaXplorer as well.

However, the mobile clients are not supposed to know how to connect to e.g Drupal, and can only try to authenticate against Ajaxplorer. In that case, once the authentication submitted to AjaXplorer, a remote call mechanism will let AjaXplorer submit the authentication credentials to the CMS : it means that Ajaxplorer handles « like a user » and will grab the CMS login form, fill it, and submit it. At this point, if the login is successfull, the CMS will log Ajaxplorer back!

Wordpress implementation is quite straightforward, but Joomla & Drupal necessit 2 calls, one for getting the login form secure tokens, and a second for submitting the form with these values. This is performed by loading the HTML page that contains the form, parsing it, find the login form by it’s HTML ID, and grab the hidden inputs key/values to submit the POST query.

For this reason, you’ll have to make sure that the MASTER_URI (see below) points to a page that indeed display the login form, that this form’s HTML id is the right one as defined by MASTER_AUTH_FORM_ID. For Joomla, the default id is login-form, but some install seem to use form-login instead. For Drupal, the default id is user-login-form.

If it’s still not working, and you see concerning »loadHTML() function failing » in your log file, the page HTML is probably creating errors at parsing time. In that case, create a simple login page with the least HTML possible, but just the login form of your CMS.

MASTER_XXX Configurations keys

We describe here only the MASTER_XX options, other options are described in the auth.remote documentation. One important thing to remember though, is to set the TRANSMIT_CLEAR_PASS to true.

  • MASTER_AUTH_FUNCTION will be « drupal_remote_auth« , « joomla_remote_auth » or « wordpress_remote_auth » depending on the bridge you are using. See below on how to add your own custom function if your CMS is different.
  • MASTER_HOST can be detected automatically, but otherwise set to the host of your cms installation (so it can be, or localhost, or Most generally for shared hosts it will be your real domain name, not a local adress. Warning, no trailing slahs.
  • MASTER_URI will be the path on your host to your CMS, beginning with a slash. Can be something like « /wordpress » or « /wordpress/ » … The combination of MASTER_HOST and MASTER_URI should lead to the page containing the login form.
  • MASTER_AUTH_FORM_ID : (useless for WP) The HTML identifier of the login form as it appear in the login page. You can use F12 (developer tools) in most modern browser, to inspect the HTML and find the corresponding <form> tag and it’s id attribute : <form id= »login-form »> bla …. </form>

When testing the configuration, you may have to try several times, and you are soon locked out of the server by the brute force login defence mechanism. In that case, searched for the failedAJXP.log file inside the PHP temporary folder and delete it, and this should work! Or simply turn the server in debug mode (see AJXP_SERVER_DEBUG on bootstrap_context.php), this will avoid the brute force login mechanism.

My CMS is not in the list!

Don’t panic, you « simply » have to implement your own function to perform the authentication submission. The idea is to use an HttpClient to POST the right values to the CMS. Add this function in the auth.remote/cms_auth_functions.php file, and check the existing implementations to see how it’s done. In some case, only a POST is necessary, in other there is a two-way communication, in that case you can use a DOMDocument to parse the HTML response of the CMS.