Access-Control-Allow-Origin header value http://preview.hs-sites.com

[Craig]

Many of our clients use WordPress as the platform for their main company websites. When building landing pages and blogs etc on HubSpot, one challenge we have consistently faced is navigation - specifically that the menus have to be maintained in two places - in a HubSpot coded file (include) and also on WordPress.

Hence, we have started using the WordPress API to grab the menu items from the main site and build the menu in HubSpot dynamically. Landing pages that we have created are on subdomains of the main domain where the WordPress install resides, so cross origin requests are not needed.

All works OK 90% of the time, but we have intermittent issues where the request to the WordPress API is rejected based on the value of the Access-Control-Allow-Origin header being sent as http://preview.hs-sites.com rather than the landing page URL. As I said, it’s not all the time - but when it does happen the user viewing the page has no navigation! Obviously we can have a fallback where we use some static code, but I’d like to understand how/why this is happening.

For clarity, these are LIVE landing pages, not being previewed or using any preview links.

Thanks in advance.

Craig

[mcoley]

It would also be a good idea to add preview.hs-stites.com so you can still preview your website as well.

[Craig]

@Matthew_Coley - thanks for this. I’ll check the request origin and match it against a whitelist (so including the preview site), - I just didn’t want to do this until I found the cause!.

I now understand what the issue is - it’s being cached on the WP end. Apologies if that’s what you guys were getting at before!

I feel better understanding why it was behaving like this!

Thanks for the help - @pmanca too!

[mcoley]

The issue is the same issue that you are having. If you run curl -I https://insights.learnlight.com/wp-json/wp-api-menus/v2/menu-locations/sidebar_primary, you see Cache-Control: max-age=600, must-revalidate. Once the cache invalidates, it will cache the first request it gets. In this case, because you are loading a preview of the website in the editor, the request is sent from preview.hs-sites.com and the Access-control-allow-origin header is fixed at that value.

As proof, I waited for the cache to become stale and hit it with a curl and now no Access-control-allow-origin headers are set. It seems like the behavior of the WP api is to just set this header to the origin of the request and that response is cached unfortunately. This is broken behavior in WP API as I can break your website by just hitting the API. To make your website more resilient, you can add an access control header for your HubSpot website to be always added in the WP API configuration.

[mcoley]

It seems like a temporary solution would be to add a random query param at the end of the API request ?random={randomlyGeneratedNumber}, which should prevent caching.

[mcoley]

Hi Craig,

I did some research this morning, and it seems like CORS may be busted for WP API according to this issue: https://github.com/mozilla/science.mozilla.org/issues/338. Which version of the API are you using?

Thanks,
Matt

[Craig]

Hi @Matthew_Coley not sure what they repo is for but that (closed) issue is a year and a half old - WP API was still being developed as a plugin at that point.

[3PETE]

@craigivemy How are you making those requests/API calls? When the Access-Control-Allow-Orgin header is being sent that is usually an indication of someone trying to make a front-end request to HubSpot. For security reasons we only allow server-side requests to our APIs.

[Craig]

Hi @pmanca - the request is being made via AJAX - but the request isn’t to the HubSpot API (which I know does not support AJAX requests), but to the WordPress API.

[3PETE]

@craigivemy Ok got it. Does this happen on live HubSpot pages that are published or on a staging domain?

[Craig]

@pmanca these are live pages. No preview URLs, fully live pages on a subdomain of the main domain that hosts the site we connect to to get the menu items.

[3PETE]

@craigivemy thanks for the info. I’ll reach back to the COS development team and see if I can get any clarity. Before I do that can you link me the page that I can share with them as an example.

[Craig]

Sounds good, thanks.

Example url is http://landing.skytrail.com/quick-enquiry-thank-you.

As I said, this issue is intermittent (but is present on other portals and LP’s too), and most of the time it is OK. I was thinking perhaps it’s related to editing the template recently, or perhaps being signed in and with Design Manager open or something - but having said that I can’t actually find a way to trigger it - just seems random.

Thanks

[Craig]

@pmanca any luck with this? Cheers

[3PETE]

@craigivemy Sorry for the delayed response. We were all hands on deck last week with our Inbound Conference.

This is an issue with caching. When you preview the website, it makes the api call under preview.hs-sites.com, so the response has access-control-allow-origin set to preview.hs-sites.com. When you open up the page, the response is cached for the preview site, not for the live site, hence why it doesn’t load. It won’t affect any of your customers

To be safe, you can add "Cache-Control" : "no-cache" in the request header
But then you will lose the benefit of caching

[Craig]

Hi @pmanca - no worries I thought that might be the case. We had a few from our agency over in Boston.
Not sure I’m following how this is being cached though.

I just loaded this page http://lp.learnlight.com/global-mobility-talent-management and I was seeing the error. I cleared all cache, loaded in incognito, in 3 different browsers and also sent to 3 colleagues, all of whom were visiting this page for the first ever time and they are also seeing the error and the missing menu.

Thanks

Craig

[Craig]

@pmanca just to let you know I’m now loading the menu statically when the API request fails, but the error will still be logged in the console along with ‘Menu loaded statically’

[3PETE]

@craigivemy did you add that header? The cacheing would be on our CDN side and not on the client side. When I look at the logs I still see the request being sent from hs-preview sites.

image.png1178x26 12.6 KB

[Craig]

@pmanca sorry did I add which header?

[3PETE]

"Cache-Control" : "no-cache"

[Craig]

@pmanca ah sorry no I hadn’t yet - I’d prefer not to if possible. Not sure I understand exactly how this is happening.

At what point is the header being sent as http://preview.hs-sites.com in the first place? When somebody edits the page within HubSpot?

If it’s sent as http://preview.hs-sites.com then, when the page is viewed live with the live URL - why would it be using a cached response from a totally different URL (the edit page URL) and from a new person/IP/browser etc? As I said, when it wasn’t working yesterday (you’ll see it now is working) - people who had never viewed the page before were getting the error.

Thanks

Craig