[wp-trac] [WordPress Trac] #51939: Basic Auth staging protections conflicts with App Passwords

[WordPress Trac]

#51939: Basic Auth staging protections conflicts with App Passwords
-----------------------------------+-----------------------
 Reporter:  TimothyBlynJacobs      |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  highest omg bbq        |   Milestone:  5.6
Component:  Application Passwords  |     Version:  5.6
 Severity:  blocker                |  Resolution:
 Keywords:                         |     Focuses:  rest-api
-----------------------------------+-----------------------

Comment (by TimothyBlynJacobs):

 I agree, we should put it in an option somewhere. Should it be network
 wide or per-site?

 We could put it in the beginning of `admin.php` like how we handle the
 upgrade checks.

 Ideally, we'd also be able to handle if the user is auto-updated when they
 aren't visiting the admin. Depending on how the auto update happens, the
 basic auth header might not be populated in `upgrade_560`. For instance if
 cron is fired out of band, isn't protected by basic auth at all, or the
 host uses WP-CLI to update.

 We could potentially do a loopback request to the homage page and check
 for a `401` error or `WWW-Authenticate` header in the response? Loopback
 doesn't always work, but we've been reporting that error in Site Health
 for a while now, so maybe this isn't a major issue.

 We also need to handle invalidating this. Would there be an issue checking
 for `PHP_AUTH_USER` on every `admin.php` and deleting it immediately? Or
 should we only delete it if it has been let's say 24 hours of it not being
 reported/

 We should also report that App Passwords is disabled in Site Health due to
 this in Site Health, but this can wait until 5.6.1.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51939#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform