[wp-trac] [WordPress Trac] #38521: REST API: Get rid of the `/users/me` redirect

WordPress Trac noreply at wordpress.org
Mon Oct 31 03:40:20 UTC 2016


#38521: REST API: Get rid of the `/users/me` redirect
--------------------------+--------------------------
 Reporter:  jnylen0       |       Owner:  rachelbaker
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  4.7
Component:  REST API      |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+--------------------------
Changes (by rmccue):

 * keywords:   => close


Comment:

 Replying to [comment:13 jnylen0]:
 > For requests that require preflight (which is the case here because this
 endpoint only works when authenticated), the CORS spec explicitly
 prohibits redirects during both the preflight request and the actual
 request.

 You're correct that the preflight checking doesn't follow redirects, my
 bad. This again still only applies to External JS-based clients.

 It's worth noting as well that these clients are somewhat discouraged from
 using OAuth 1.0a, as they would need to expose their secret publicly. The
 typical process for creating JS apps that connect with OAuth 1.0a is to
 have a server proxy the requests in any case.

 Replying to [comment:14 pento]:
 > I'm not convinced that this is a documentation issue. With the redirect
 in place, the developer experience will either be "nice, this just works",
 or "omg, everything is exploding, I don't know why", particularly when it
 comes to the internals of OAuth libraries, or `XMLHttpRequest` behaviour.

 Let me be clear: if OAuth libraries don't follow redirects correctly,
 '''they are broken'''. Similar arguments could be made for the various
 HTTP request methods, headers we send back, etc etc: the client may see
 "this doesn't work", but it's not always our job to fix this. If the OAuth
 libraries don't work properly, that is an issue with them.

 > Making `/users/me` behave as a proper resource seems like it will fix
 this.

 The thing is that `/users/me` is '''not''' a resource. We cannot just
 pretend it is. There's no entry in the database with the ID `me`. It is a
 pointer to a real resource with a real ID.

 Again, I have to '''strongly recommend closing this''' in favour of
 stronger documentation.

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


More information about the wp-trac mailing list