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

[aquarius]

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.

[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 .

[aquarius]

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.)

[TobiasBg]

Ah, my bad. Thanks for the clarification!

[aquarius]

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

[aquarius]

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.

[cadic]

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

[aquarius]

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.

[peterwilsoncc]

@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.