blog post on using a cloudflare worker to xdebug a live hit locally

[hanoii]

This is my first attempt at a blog post, not sure if it's useful, interesting or even well written, but gave this a try.

It is AI assisted

Rendered at https://pr-609.ddev-com-fork-previews.pages.dev/blog/cloudflare-workers-live-requests-on-your-local/

[github-actions]

🌐 Fork Preview for PR #609

https://pr-609.ddev-com-fork-previews.pages.dev

This preview updates automatically when you push changes to your fork.

[rfay]

Yay!

[rfay]

• It's really easy to do ddev share with cloudflared with a stable domain (that matches the TLD you're working with). If you're up to it, consider doing this instead of using the manual update you're using. This is documented at https://docs.ddev.com/en/stable/users/topics/sharing/#setting-up-a-stable-cloudflared-domain
• I did a related thing in 2013 for external service callbacks, similar to your use-case. Payment services often need this kind of thing. https://randyfay.com/content/tunneling-http-debug-or-develop-external-webservice-call. It's so much easier these days!

[hanoii]

I did that for my own use case, the stable domain, I didn't want to overcomplicate the blog post... there is one thing that that I also did which was to add the live domain as a fqdn to ddev so everything internal to drupal was as it the host were the live one too:

ddev share --provider=cloudflared --provider-args="--http-host-header demo.devhosting.com.ar --hostname ddev.devhosting.com.ar"

Might add this though.

[hanoii]

I had to run ddev non-interactively, so that it doesn't prompt me to update /etc/hosts with the fqdn to localhost, which obviously I didn't want that to happen

[hanoii]

Other than that any other feedback? Would you publish it as is?

[rfay]

I had to run ddev non-interactively, so that it doesn't prompt me to update /etc/hosts with the fqdn to localhost, which obviously I didn't want that to happen

Interesting problem. DDEV tries to add to hosts file when the domain can't be looked up, or when it doesn't evaluate to 127.0.0.1. I thought that when I tested this earlier I didn't see problems like this.

Other than that any other feedback? Would you publish it as is?

I want to walk through and manually test. I'm sure @stasadev will have some input as well.

I would like a better title. "Using Cloudflare Workers to tunnel matching traffic into your local" doesn't mention DDEV and doesn't really say what the goal is. I think the goal is using Xdebug to debug an internet-exposed service that happens to be your local DDEV project.

IMO the stable subdomain would simplify this article, rather than making it more complex, because right now you have to go figure out what domain you're auto-assigned and fiddle with things. Maybe that happens anyway, not sure.

I'm also not sure why you have to do any of the cloudflare worker stuff if you have ddev share with a stable domain.

[hanoii]

I'm also not sure why you have to do any of the cloudflare worker stuff if you have ddev share with a stable domain.

Even with this, the share would be a tunnel, I can't tunnel to a domain that's already pointing somewhere else. The worker also has logic to only tunnel very specific traffic.

[hanoii]

Interesting problem. DDEV tries to add to hosts file when the domain can't be looked up, or when it doesn't evaluate to 127.0.0.1. I thought that when I tested this earlier I didn't see problems like this.

Yes, I found it odd and wondered if there was a setting to avoid this. I looked at the code and that's where I noticed this wouldn't happen if called non-interactively.

https://github.com/ddev/ddev/blob/4c4462078299db2e2baa1a1a1884bdc981c6ef17/pkg/ddevapp/hostname_mgt.go#L26-L28

[hanoii]

And is not just publishing a live domain, is actually hijacking the live domain.

Say that you want to debug something hitting ddev.com, but on your local. This is what I am doing.

[rfay]

Say that you want to debug something hitting ddev.com, but on your local. This is what I am doing.

I would normally debug it on xxx.ddev.com or some such. it's usually the TLD that is the issue with things like this.

[hanoii]

but that's the thing with the article, saml was hitting ddev.com, and changing that was what I wanted to avoid.

I was looking to debug a hit in the ddev.com not change that. Doing a subdomain that would simply mean using the tunnel. So this is not about using a stable subdomain with cloudflare tunnels, or ngrok which I already had it.