Experiments...

Disclaimer: I'm not an security expert, assume I'm wrong.

Auth and WP with Gatsby

GatsbyJS & WordPress integration plugins make it easy to access all the site content at build time but does NOT provide any way of dynamically querying the data during the client run-time. Essentially, gatsby-source-wordpress plugin 'scans' the WP install and constructs a dynamic GraphQL Schema (the data from WordPress). This is the 'gatsby' data layer and it's constructed from the WPGraphQL+WPGatsby WordPress plugins. The Graphiql tool at http://localhost:8000/___graphql (in development) allows us to peruse the schema (data).

At runtime on the client device, the gatsby-source-wordpress Schema is not in 'scope', so to speak. It's only used via Gatsby at build. This begs the question, "how do we communicate with a WordPress installation from the client?". This is not as simple/obvious as maybe first envisaged. We could make requests to the WP-REST endpoint, or we could make a request to WPGraphQL endpoint. (Which is what the Gatsby integration utilises.) It might be possible to make requests via wp_ajax_url.

Connecting to the WP endpoints poses some intriguing solutions/options. One of these options is using cloud functions to make requests on behalf of the client. This has a distinct advantage in that the WP endpoints (essentially, URLstrings) are never divulged to the public on the client. Removing a potential point of attack. Authentication is a crucial aspect, we certainly don't want users to have access to data they are not supposed to be able to read (or worse write).

• ** Public/Private**

  A list of thoughts / ideas

• Assume all WordPress data is publically accessible unless explicitly set as private.

• Traditionally, wordpress manages data and organises page layouts using the "template heirarchy". It's perhaps reasonable to suggest that it attempts to make as much information as public as possible.

• data stored in media-folder are not on private urls

• Ensure private content cannot be accessed by a public/un-authetincated request.

• WordPress has it's own system for managing user credentials and passwords.

• Authenticated infomation (eg, user-passwords) is not exposed to the public via the WP-REST-API or WPGraphQL.

• However, with the necessary user credentials infomation may be readable/writeable.

• Everything within the gatsby-source-wordpress graphql schema is traversable by those who know the endpoint.

• The WP_REST api and other forms of data may also be accessible to those who know the URL.

• Assume data is accessable to the public unless known otherwise A good example of wp data that may help explain this behaviour is the post/page status. Which by default in WP can be one of the states below.

• publish, draft, private, password-protected

Only published posts will appear on the gatsby-source-wordpress schema, but this doesn't mean that posts with the other status cannot be accessed via WPGraphQL if the user has the correct permissions.

WP manages User data straight out of the box. There are a variety of role options, and an implementation for managing user data (CRUD) eg, password resets. Although it provides many advanced features, things can get complicated pretty quickly, especially if using plugins for extra functionality, eg, restricted content.

• MPORTANT: Restricted Content

  Never render restricted content at build time, always render the return of a successful authenticated API request. Guarantee that the endpoint is not accesible to unauthenticated users or those without the correct privilages.

JWT & CORS

There are various options for making authenticated requests and securing content with WP. Notably JWT (javascript-web-tokens) and CORS (Cross-origin-resource-sharing) header cookies. Both of these options require the client browser being given some sort of ticket/token, this is sent alongside a request(header) that WP can veryify. These are both similar but there is a difference between JWT and CORS header cookies.

JWT's are a web standard, but as they are publically accessible. It is possible to mimic them on a client. Due to this they are limited by a short expiration duration and meaning that they need to be renewed frequently.

CORS header cookies are harder to interfere with from the client, perhaps making them a more robust option than the JWT.