Ghost's API has a number of endpoints which should be available for what we refer to as 'public' access. Essentially, any data which can be accessed legitimately from the frontend of a blog, ought also to be accessible through other clients. As described in #4004, public access will still require a client ID, so that this access can be revoked.

The frontend controller code which handles outputting data via a theme is a client of the API, so is the {{#get}} helper (#4439), and also javascript code in the theme which may make requests via AJAX. Our plan is to have default clients which automatically get access, just like frontend controller/theme code.

Similarly to the frontend controller, the {{#get}} helper uses the internal method-call version of the API, so it doesn't need a client id. Each blog will get a default client id which is made available to any JavaScript in a theme (issue #4184) so that it can make ajax calls, and eventually it will be possible to register custom clients as well.

The endpoints that will be public in the first iteration, will be the browse & read endpoints of the post, tags and user resources. Several of the authentication flow endpoints are already public as they happen before auth is available. Every other endpoint should remain behind user auth for the time being. Settings and config will need consideration for public access shortly after, and the other endpoints will become available with the introduction of full oAuth 2.0 flows for clients.

The Rules

Several of the endpoints which are public have very strict rules around what information that can be accessed from that endpoint when the request is public.

• Posts: - only published posts may be accessed, unless a draft is specifically requested via the UUID (which cannot be looked up via the public API).
• Users: - only active users may be accessed, email addresses and passwords must not be returned
• Tags: - no rules yet, but private/hidden tags may change this in future

Tasks / Checklist

The following tasks are required to complete this work:

• make the posts, tags, and users browse & read endpoints accessible for public requests
• ensure that draft posts and inactive users cannot be accessed by public requests
• ensure that the rules remain in place when making requests across relations, e.g. tag.posts or tag.posts_count
• ensure that the rules remain in place when the filterparameter is used (API: Filter parameter (GQL filter queries spec) #5604)
• ensure that user email addresses and passwords are not returned for public requests
• ensure that no other endpoints can be accessed
• determine what the public access behaviour should be for blogs which are marked as private (all HTTP requests to the api should require the same cookie?)

A note on the settings endpoint: when made publicly accessible, settings will have the rule that only settings with type blog and theme can be accessed publicly. The private blog isPrivate and password settings are currently incorrectly classified as blog settings and would need to be changed before the settings endpoint can be made public.

• Fix settings endpoint