Expose 'login_url' and 'admin_url' via XML-RPC

[daniloercoli]

To show the preview of 'private'/'draft'/'pending review' posts we need to authenticate to WordPress by using the login form, and the redirect_to parameter.
Sometime the URL of the login form cannot be guessed by replacing xmlrpc.php with wp-login.php :)

We have the same issue for the URL of the admin dashboard.

[redsweater]

Since you're going to the trouble of proposing changes in WordPress's API to support this useful screen-scraping, wouldn't it make more sense to support a method "wp.authenticate()" or similar that would explictly return a cookie suitable for session-scoped requests to the site as the logged-in user?

I can imagine push-back that the API shouldn't empower clients to access the whole site like this, but the fact is as Danilo notes you can automate this through screen-scraping, anway. If you are going to go the extra step of outright advertising the required APIs for accomplishing this, why not make the whole process more foolproof?

The added benefit of formalizing this is you would then also have a central point of authentication for this person, that the user could disable either through plugin or admin-panel options. In that scenario, if a client app attempts to wp.authenticate() and receives an error, they can pass it along to the user.

I don't think concessions should be made to supporting full "browser-style" authentication unless you go all the way and make it foolproof and more administratable.

[redsweater]

As far as the admin interface URL is concerned, note that this is already exposed via the wp-includes/wlwmanifest.xml file, which also defines a couple other URLs-of-note in relative terms to the xmlrpc.php API endpoint. This would probably be a more natural location to add the login_url, unless there is some move afoot to deprecate the wlwmanifest.xml file.

[markoheijnen]

That seems valid except that authenticate would be the wrong name. Also the manifest file doesn't help since it has the same flaw. It's a static file.

[redsweater]

Ah, good point. So I guess wp.login() would be more appropriate for the name? I think this should probably come down to a discussion of whether WordPress core developers are comfortable with the API providing any affordances at all for helping clients to gain full login permissions.

Personally I am for it from the point of view that because the API and the web interface both use the same credentials, absence of full login permissions is only protected by obfuscation of the login URL, and the challenge presented to API clients of simulating a web-based login procedure.

[markoheijnen]

For now it it. I'm still hoping on a RESTfull API for early next year and who knows then it is different. So I guess the patch is the best way to go. Unless the roadmap is clear for the next couple of years.

[redsweater]

Ah - shame on me for not looking at the patch, I didn't realize there is already a blog_options type API call that conveys everything wlwmanifest.xml does and more, dynamically.

It does seem like adding the login and admin page URLs to that would be reasonable. I still think given the dance you have to do to screen-scrape the login page, it would be nice to just add a wp.login() method to get the cookie, but this patch is obviously less work and probably a less debatable change.

[daniloercoli]

Replying to redsweater:

It does seem like adding the login and admin page URLs to that would be reasonable. I still think given the dance you have to do to screen-scrape the login page, it would be nice to just add a wp.login() method to get the cookie, but this patch is obviously less work and probably a less debatable change.

For the sake of precision it's just a POST to the login form with the URL of the target page set as "redirect_to" parameter.
We are using this technique in 2 case:

• When we need to preview a draft|private|pending post. The value of the redirect_to parameter is set with the permaLink of the post/page.
• When we need to access the Dashboard of the site. You can change the location of /wp-admin/ and sometimes for security reason users did that.

If you are curious see: ​http://ios.trac.wordpress.org/browser/trunk/WordPress/Classes/PostPreviewViewController.m#L205

[westi]

In 1291/tests:

XMLRPC: Add tests for new readonly "options" to read the login and admin urls for a site. See #23446.

Also fix the site url tests to match the option.

[westi]

In 24382:

XMLRPC: Expose the admin and login urls as read-only options over xml-rpc to make it easier to write rich clients. Fixes #23446 props daniloercoli.