WordPress.org

Make WordPress Core

#23446 closed enhancement (fixed)

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

Reported by: daniloercoli Owned by: westi
Milestone: 3.6 Priority: normal
Severity: normal Version: 3.5
Component: XML-RPC Keywords: has-patch mobile commit
Focuses: Cc:

Description

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.

Attachments (1)

login-url-xmlrpc.diff (785 bytes) - added by daniloercoli 14 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 redsweater14 months ago

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.

Last edited 14 months ago by redsweater (previous) (diff)

comment:2 redsweater14 months ago

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.

comment:3 markoheijnen14 months ago

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.

comment:4 redsweater14 months ago

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.

Last edited 14 months ago by redsweater (previous) (diff)

comment:5 markoheijnen14 months ago

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.

comment:6 follow-up: redsweater14 months ago

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.

comment:7 in reply to: ↑ 6 daniloercoli14 months ago

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

Last edited 14 months ago by daniloercoli (previous) (diff)

comment:8 SergeyBiryukov13 months ago

  • Version changed from trunk to 3.5

comment:9 westi11 months ago

  • Keywords commit added
  • Milestone changed from Awaiting Review to 3.6
  • Owner set to westi
  • Status changed from new to accepted

comment:10 westi11 months ago

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.

comment:11 westi11 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

Note: See TracTickets for help on using tickets.