Cloudfront behaviors with S3, Wordpress backend, and Vue frontend

Question

I'll try to explain my situation and issue as best as I can.

Previously I had a wordpress site behind cloudfront. Set up behaviors and that all worked well.

Recently I have moved to using my wordpress instance as an api host. I have a Vue build on s3 for my frontend content. All of this behind cloudfront.

So now, my default behavior must point to s3 instead of the wordpress instance. I'm having issues navigating pages now and I'm not sure why.

For instance while in the wordpress control panel if I click a link the default behavior is hit instead of wp-admin/. If I refresh after the default behavior is still hit. However, if I hard refresh (ctrl-shift-r) the desired wp-admin/ behavior is hit.

This also occurs with wp-json/*

I'm rather puzzled about why this is even happening so any input would help.

Adding an example. I navigate to: /wp-admin/edit.php?post_type=page Cloudfront routes to the default behavior of * which is s3. I hit ctrl-shift-r and /wp-admin/edit.php?post_type=page is loaded on my /wp-admin/* behavior.

I don't understand why or how to fix it.

I am building a PWA Vue site. I'll detail and mark my solution later.

For now, what this means is after the server worker is installed for the domain by viewing the front end it will disrupt the admin panel from being accessed. It hijacks the request before it even hits cloudfront, I assume.

Slightly confused about your description. "Default behaviour" is that a CloudFront thing? When you say "must point to S3" is that a question, a statement based on a software install guide, or something else? Why don't you just have another domain name or subdomain for your API and avoid the problem altogether? — Tim, Jul 15 '20 at 21:31
Yes it is a cloudfront thing. If no behavior matches the request route the default behavior is used. It's a statement. Previously the default behavior pointed to my ELB. Now it points to S3. Throwing WP onto a subdomain is an option but will also come with its own issues. — Josh Rodarte, Jul 15 '20 at 21:43

score 0 · Accepted Answer · answered Jul 20 '20 at 17:03

To prevent the service worker from hijacking the request a custom route is used to fetch the matching url.

I'm using workbox and this was the service worker I came up with.

import { precacheAndRoute } from 'workbox-precaching'
import { registerRoute } from 'workbox-routing'

precacheAndRoute(self.__WB_MANIFEST)

// Match admin routes
const matchCb = ({ url, request, event }) => {
    return (
        url.pathname === '/wp-admin/' ||
        url.pathname === '/wp-admin' ||
        url.pathname === '/preview=true/'
    )
}

const handlerCb = async ({ url, request, event, params }) => {
    event.respondWith(async function () {
        // Attempt to respond with cache
        const cachedResponse = await caches.match(event.request)

        if (cachedResponse) {
            return cachedResponse
        }

        // Use the network.
        return fetch(event.request)
    }())
}

// Add a route
registerRoute(matchCb, handlerCb)

Cloudfront behaviors with S3, Wordpress backend, and Vue frontend

1 Answers1