Need to avoid routing Nop self-requests through the public Store URL

[BryceBarbara]

nopCommerce version: 4.70.4

Steps to reproduce the problem:

1. Setup Commerce to be behind a reverse proxy
2. Set the store's URL to be the reverse proxy's URL
3. See Nop incur latency and potentially have requests get blocked when trying to make requests to itself

We're seeing issues where having a store behind a WAF can cause internal requests to be blocked. An example of this is: https://github.com/nopSolutions/nopCommerce/blob/develop/src/Libraries/Nop.Services/ScheduleTasks/TaskScheduler.cs#L206

Although the immediate workaround is to update the WAF to not block those requests, that quickly becomes a game of cat and mouse as new requests get added in new versions that can get blocked. This also makes using plugins in these scenarios harder since they may also need to may local requests but don't have an "official" way to avoid the WAF.

I can think of a couple ways to avoid this:

1. Have Nop explicitly use localhost in these scenarios
2. Add a new property to Store that is to be used for local requests

[AndreiMaz]

@BryceBarbara We also use Cloudlflare WAF and it works absolutely fine. If you use some kind of "under attack" Cloudflare modes, then simply add a page rule to ignore it for the "scheduletask/runtask" URL. It's much easier to configure

[BryceBarbara]

@AndreiMaz I literally called that out in the post. I can try to spell it out more clearly though:

• New requests added in updates are blocked until we whitelist them but there's no way to learn of new requests without manually auditing things
• Plugins make more use of these local requests and they need a way to ensure these don't go through the public URL

[AndreiMaz]

@BryceBarbara I understand. But using localhost instead of URLs also could cause issues on some hosting companies that process localhost some "other" way (block or redirect to other hosts). So it's better to configure it on CloudFlare rather than in code

[hoffmanntravis]

@AndreiMaz I think the optimal solution here would be to support two fields on the store table; one internal, one external. The internal field, would be used for internal routing (and could be set the same as the store, or if null defer to the former store field, etc). The external field (what is there now), would be used for external communications.

This way, users can send things like emails and other correspondence or long-lived links that required a custom domain host, or just generally should route through the external network edge. Additionally, by supporting an internal url for loopback communication, the application could be made to route through an internal load balancer, Azure Url, AWS Url, web gateway or reverse proxy, and so forth. It's quite common and reasonable to ask the application to talk to itself through a different mechanism distinct from the network path used for ingress by users. Perhaps even localhost would even work.

Primary reasons for this separation include:

• No unnecessary latency of leaving the intranet or local machine in question (depending on setup)
• More reliable routes
• Routing flexibility
• Avoid sending unnecessary traffic over the public internet (security) in some cases
• Avoid Web Application Firewalls
• Ensure the app communicates with itself and not some other host (this is a common scenario during migrations if you are doing a blue-green; you don't want to route the 'new' Green instance to the 'old' Blue instance that the CNAME is pointed at

Finally, I'm not sure it's correct to say that the 'best' way to design the nop application is to rely on changes to external appliances independent of it. In my view, it would be much better if the application is sufficiently flexible to be able to communicate with itself, regardless of the edge network infrastructure.

[wboyd-aw]

@skoshelev @exileDev @AndreiMaz Any thoughts on comment above?

[AndreiMaz]

We would prefer to avoid this logic. It'll make a store configuration just less trivial for most store owners. It's better to configure a new rule on CloudFlare rather than in code