• On Friday, we started going through 2.0-beta1 issues. Asked Rachel why we did crazy things where we did crazy things. Some new issues opened.
• Daniel bonked hard on the password handling code. Setting a cookie to view a password-protected post in REST API is pretty bad.
• Core’s cookie handling is per COOKIE_HASH, not post, so viewing a second password-protected post nullifies the first.
• We can’t pass the password as a GET parameter because it could expose the password in the logs.
• WordPress.com accepts the password as a GET parameter. This is likely an unacceptable risk for core.
• Ryan suggested authorization headers instead of parameters.
• Another open question: what fields are expected to be password-protected?
• We should err on the side of less data (e.g. not in the loop) for the time being.
• Discussed #1023 (returning error when returned data mismatches declared schema)
• Meech suggested we try not to solve the problem of “anyone with access to the source code can break the API”
• Ryan’s suggestion is we encourage clients to write robust clients, and not segfault on bad data. Likes the idea of including useful header data in the request, but not in the response.
• Q: Should plugin developers be able to remove fields from a response?
• Rachel has used our existing filters in v1 of the plugin to add and remove fields.
• Ryan: it’s important our documentation emphasizes removing fields would break things.
• Meech: Consider who we’re protecting, and what we’re protecting them from. This seems to be protecting clients from bad plugins. But it really seems we’re trying to force people to use our ideas. If I’m a plugin and start breaking clients, I’ll get reports on how to fix it.
• Rachel: Users can disable WordPress themes with a constant. We should make sure WP-API is as extensible as WordPress.
• Rachel: 80% of users don’t know how to write the PHP code to break a response. The 20% that can, also know how to refer to documentation and best practices.
• Joe: Agree with the consensus. Get really pissed off when someone locks down what he knows how to work around.
• Decision to not restrict removal of fields. We can’t easily report the distinction either.

#meetingnotes