Same origin SSGTM proxying questions

Hi there, I was excited to see this post as it’s something I’ve been looking to test myself:

However, it seems like the blog post ends before explaining some key things. For example, some questions I ran into:

  1. How do you preview / test the server-side container now? I am not able to preview it using www.domain.com/data in GTM Server container when I set that as the debugging URL. I get an error, “Your Session has Expired”

  2. I currently doing this via CloudFlare method and I am wondering about CF proxying. In my worker I use my custom domain data.domain.com; which is proxied through CloudFlare. I feel like maybe I should remove the proxy for data.domain.com that is pointing to Stape as the request is essentially proxied already through www.domain.com/data

Any other guides / tips would be great!

2 Likes
  1. For preview you need to add domain.com/data to settings of server GTM container and use it for run preview.
    “Your Session has Expired” – If it happens all the time, it’s probably a problem with your server settings or DNS settings.

  2. Yes, you can keep only the option you will actually use

Hi Alex, I actually found that Google Server-side on same origin requires you pass the Host header, and in the article on stape.io the code sample for CloudFlare Workers does not include it (the NGINX sample does). I had to add that to fix it. Not having it also created data issues in GA4. My updated code was:

export default {
  async fetch(request, env, ctx) {
	let url = new URL(request.url);
	let newPathname = url.pathname.replace('/data/', '/');
	let newUrl = `https://data.domain.com${newPathname}${url.search}`;
	let newRequest = new Request(newUrl, request);
	newRequest.headers.set('Host', 'data.domain.com');
	return fetch(newRequest);
  },
};
2 Likes

Hi, I have the same problem, I used this script that you placed here and the problem continues, did this script solve it for you?

Yes it did fix it, what error are you having?

I assume you changed /data/ and data.domain.com in the three places to match your environment?

Yes, I changed those options, but the preview still doesn’t work, here are screenshots

I looked at your site and I think there might be a couple errors in your implementation:

  1. You’re missing GTM- on the GTM main script. In other words it should be GTM-12345 not just 12345
  2. I see network requests to your ssGTM subdomain; You need to update server_container_url
    parameter in your web container - https://purtymakeup.com/metrics

I think your Worker script looks good but I’m not sure why there is the yellow CloudFlare error tooltip there.

I understand, in the script that did not have GTM it is given to me by Stape’s Custom loader, it gives the main script without GTM and the second script that is placed after in that one the GTM is included

I did what you told me to put GTM in the main script and now it gives a 404 error

In server_container_url it is already with that URL

By the errors in Cloudflare, do you mean the parts that appear in yellow in the script of the image that I passed?

Oh I see, the custom loader must try to obfuscate that you are using GTM. That makes sense, I didn’t realize that, apologies.

Yes I meant the little yellow lightbulb but looking at your code it looks good.

Honestly I’m not sure then what might be going on here. I just tested again and our container is working correctly. Maybe someone from Stape knows, or I can think some more on it.

You do not need to add GTM- to the loader. Stape’s updated custom loader removes GTM- to increase protection against adblockers.

Try using the code for the worker listed here: A new way to set up a custom domain in server GTM - Stape
Also check the last point in the article above that you have this done.

@whmkt is it expected behavior that even after adding the same origin url with cloudflare worker, all the outgoing network requests in the browser are still going to the subdomain? That s currently our situation, and if that is the case, I might be missing something on what the added benefit would be from having same origin, if that is the case. Do you have some thoughts on this?

Hi @Adeola_Morren - I noticed the same thing actually and ended up not using same origin. I am also curious if I made a mistake somewhere or if that’s expected.

Yep exactly my thought… from a technical standpoint when following Stape’s instructions there is actually no way for this NOT to be the expected results … so this is where I’m wondering if perhaps something was missed in the documentation… or if the sole purpose was simply to have the original GTM load request to be from the origin domain, which I would highly doubt…

You should use your same origin in GTM containers (https://domain.com/metrics/) as transport url. You probably have a standard link with a subdomain there now, so requests are sent there.

Hi Alex - no, using the correct server_container_url parameter with the same origin. In other words if domain is www.domain.com my server_container_url is www.domain.com/metrics

Then something is overwriting your setup - there are no other options. For example you may have two Google tags with different server_container_url, or gtag in code with other server_container_url.

To get a deeper understanding of the cause at least a link to the site and screenshots/videos of your settings in the container are needed

I am in the same situation described above (did everything like in tutorial )

The issue is about the Stape.io server answering with a “Location:” header redirect when called from CF Worker :

Once the redirect request URL arrives to my browser all is working good…just not from CF Worker.

Same issues discussed here: Same origin problem / redirect problem - #8 by Alex