Make WordPress Core

Opened 14 months ago

Last modified 13 months ago

#57809 new enhancement

Application password success_url should allow http when host is localhost or localhost:port

Reported by: aquarius's profile aquarius Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Application Passwords Keywords: dev-feedback has-patch needs-unit-tests
Focuses: Cc:

Description

When using wp-admin/authorize-application.php to walk a user through the application password flow, WordPress will refuse to use a success_url with an http scheme, requiring that it's https (or a custom scheme). This is good security, and browsers implement the same SSL requirement for many browser APIs for the same reason. However, browsers also have an exception for http://localhost URLs, because it makes local testing much easier. WordPress should do the same here; a local test of a web app which interacts with the WordPress API should be able to walk a user through the application passwords flow, and at the moment it can't. Similarly, a non-web app running on a desktop computer can stand up a temporary HTTP webserver on a high-numbered port to serve the success_url much more easily than it can register a custom URL scheme.

Attachments (1)

localhost-secure-context-app-passwords.patch (1.1 KB) - added by aquarius 14 months ago.
Small patch to make localhost HTTP urls acceptable as success_url and reject_url for the application password flow a la browser secure contexts

Download all attachments as: .zip

Change History (10)

#1 @aquarius
14 months ago

  • Component changed from General to Application Passwords
  • Summary changed from Application password success_url should allow http when directed to localhost to Application password success_url should allow http when host is localhost or localhost:port

#2 follow-up: @TobiasBg
14 months ago

  • Keywords close added

Thanks for the ticket! It looks like this has been considered and you can achieve this by configuring an environment type, see https://core.trac.wordpress.org/ticket/52092#comment:1 .

#3 in reply to: ↑ 2 @aquarius
14 months ago

Replying to TobiasBg:

Thanks for the ticket! It looks like this has been considered and you can achieve this by configuring an environment type, see https://core.trac.wordpress.org/ticket/52092#comment:1 .

Ah, no, that's a different issue. That allows a locally running WordPress to create application application passwords in the admin by setting environment type to local, and works great. What I'm talking about is something different: a locally running _consumer_ of the API, something that isn't WordPress itself. I build an app -- a desktop app, or a web app currently in testing before deployment -- which wants an application password so it can consume your WordPress data from https://wordpress.example.com/wp-json. My web app is running on, say, localhost:3000 while I'm building and testing it. So to get an application password for the WordPress API, it will direct the user to https://wordpress.example.com/wp-admin/authorize-application.php?success_url=http://localhost:3000/got-password. This will fail, because authorize-application.php won't allow a success_url to be http. This makes testing the application difficult, and this is why browser APIs that require a secure context (https URLs) have an exception for http://localhost(:port). (https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts explains.)

#4 @TobiasBg
14 months ago

  • Keywords dev-feedback added; close removed

Ah, my bad. Thanks for the clarification!

@aquarius
14 months ago

Small patch to make localhost HTTP urls acceptable as success_url and reject_url for the application password flow a la browser secure contexts

#5 @aquarius
14 months ago

I have attached a small patch which does this; if it's better to do a GitHub PR then I can do that instead, of course.

#6 @costdev
14 months ago

  • Keywords has-patch needs-unit-tests added

#7 follow-up: @cadic
13 months ago

#8 in reply to: ↑ 7 @aquarius
13 months ago

Replying to cadic:

Looks like a duplicate of https://core.trac.wordpress.org/ticket/52617

Not quite, I think. That's about allowing all URLs when environment type is local. What I propose here is that WordPress works a little more like browser secure contexts: that an https URL is required as success_url but that http://localhost:(port) counts as an https URL, which makes testing plugins and authorized apps easier.

#9 @peterwilsoncc
13 months ago

@aquarius Thanks for the patch and linking the the MDN docs on secure contexts.

Either patches or GitHub PRs are equally easy. Most committers use GitHub these days as the tests run on them, if that influences your preference.

I'll chat to some members of the WP Security team about treating http://localhost, etc as a secure context in all environments rather than just development environments.

Note: See TracTickets for help on using tickets.