[wp-trac] [WordPress Trac] #49110: Add ability to lock/restrict public REST API access from WP Admin

WordPress Trac noreply at wordpress.org
Thu Jan 2 15:56:04 UTC 2020


#49110: Add ability to lock/restrict public REST API access from WP Admin
-------------------------+------------------------------------------------
 Reporter:  apedog       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  close        |     Focuses:  administration, rest-api, privacy
-------------------------+------------------------------------------------
Changes (by jorbin):

 * keywords:   => close


Comment:

 Plugins should be able to use the REST api on the front end and an option
 to disable it is essentially an option to allow users to break their site.
 This topic has been discussed in #39806, #38446 amongst other places. As
 @joehoyle wrote one of the previous times this was discussed:

 > The more WP functionality core functionality we see moving to be build
 on the REST API, the more it will become not possible to disable it. The
 REST API is not just an external facing layer on WordPress, it is core
 functionality.
 >
 > As per usual, if you don't want your site to be publicly accessible,
 there are plugins and other means of doing that - but it's not a default /
 feature of WordPress core to enable such a thing.


 User facing options also are not free, as was noted by Havoc Pennington in
 2002 in an article that has had a lasting impact on the philosophies of
 WordPress:

 >It turns out that preferences have a cost. Of course, some preferences
 also have important benefits - and can be crucial interface features. But
 each one has a price, and you have to carefully consider its value. Many
 users and developers don't understand this, and end up with a lot of cost
 and little value for their preferences dollar.
 >
 >Too many preferences means you can't find any of them.
 >Preferences really substantively damage QA and testing.
 >Preferences make integration and good UI difficult.
 >The point of a good program is to do something specific and do it well.
 >Preferences keep people from fixing real bugs.
 >Preferences can confuse many users.
 >
 >I find that if you're hard-core disciplined about having good defaults
 that Just Work instead of lazily adding preferences, that naturally leads
 the overall UI in the right direction. Issues come up via bugzilla or
 mailing lists or user testing, and you fix them in some way other than
 adding a preference, and this means you have to think about the right UI
 and the right way to fix problems. Basically, using preferences as a band-
 aid is the root of much UI evil.


 I don't see any new arguments that makes me believe this ticket shouldn't
 be closed as a duplicate of #39806

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


More information about the wp-trac mailing list