Closed BryceBarbara closed 3 months ago
@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
@AndreiMaz I literally called that out in the post. I can try to spell it out more clearly though:
@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
@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:
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.
@skoshelev @exileDev @AndreiMaz Any thoughts on comment above?
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
nopCommerce version: 4.70.4
Steps to reproduce the problem:
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:
localhost
in these scenariosStore
that is to be used for local requests