Images Problem - 4.0 Version

Somebody?

logisz wrote:

??

You should look up 'fake URL cache injection' it's causes and its solutions. I just fixed this problem on my site but I did about 5 things and I do not know which one worked. It appears the issue came from a bot attacking my site. Check your log files.

Hi all,

ajmurray3 is kind of on the right track but I can give you some more detail/insight, and perhaps the NOP folk can guide us more (or raise an issue perhaps).

I don't know if this is "a thing" for all stores or things like azure or any of the various hosting providers, however I can verify this 100% happpens in the following setup.

IIS has two features (read here: https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-application-initialization) that enable "always on" and "warmup" type features.

Nop has a "keep alive" feature.

If you have "featured products" (or anything really) that appears on your *home page* that NOP likes to cache, then what happens is the "warmup" action creates a request to the HOME PAGE, which in turn triggers caching of all the cachable items on the home page but the issue is that this REQUEST will have (in most/all? cases) the HOSTNAME header as "localhost/127.0.0.1/etc..."(possibly config based, and haven't tested but I think "URLREWRITE" also can getn in the mix here), which in turn causes several functions (mostly involving image URL generation) to use "LOCALHOST" rather than "DOMAINNAME", which of course will cause the image to not be found unless you happen to have a local server running with the images/thumbnails in exactly the right path...

Once this startup event has triggered caching of things like "http://localhost/images/thing.jpg" then this is what will be rendered (from cache) everytime someone "gets" that cached item, so search results and so on - until that is the cache expires (60 mins?) or an "Admin" manually clears the cache...


AFAIK there are two "temporary" solutions
1) flip a setting "mediasettings.useabsoluteimagepath = True" (if here is an Admin page I couldn't find it - but /Admin/Setting/AllSettings -> search "absoulute" shoudl find it...) - (not recommended - apparently bad for SEO)
2) disable "Enable Preload" on the server... your startup times will increase :(, but not horribly... so maybe this is okay...?

Either this is a bug/design flaw in NOPcommerce or an in built issue/incompatibility with this feature and NOPCOMMERCE (although I have not seen anywhere that says this or warns against it).

OR there is some element of store configuration/server configuration that we/I am missing that will resolve this issue...

Hopefully someone with a better understanding of the depths of NOPCOMMERCEs intended operation around this can guide us in the correct/better way for this one.

One final note:

I don't know the in/out of either NopCaching or IIS/webserver startup mechanics, but I can ONLY GUARANTEE to get this failure on FULL IISRESET type behaviour NOT recycle of appPool, NOT restart webSITE and not "NopCommerce" restart application.

Like I said I don't know if the NopCommerce "inmemory" cache has some kind of persistence magic that allows it to survive process switching or apppool restarts or what...

So just hoping this helps others to reproduce and understand the deeper picture of what options others have highlighted previously in this thread.

Finally (this time for real),
The last piece of the puzzle, is that IF you have a hostname setup in the bindings in IIS then the "Enable Preload" appears to use that rather than "localhost/default/127.0.0.1" and so the caching issues isn't present in this case, same goes for SSL, which will also (mostly) have a hostname associated with it, so if you are only getting this in a test/other server, then once you apply a SSL cert and have it behind a live domain/hostname then this issue (of the specific nature I specified previously) will not occur.

I'm not sure, but I think this is probably a "fault/feature" of IIS when just using default bindings without hostnames.

eg: if you set up a number of test/dev whatever servers on IIS like :
myserver:81
myserver:82
myserver:83

with preload enabled
then you will likely see this behaviour/symptoms.

Hope this helps others.

Somebody with an sollution? Same problem here...

nginx Reverse proxy

I've solved this problem for me (running IIS 7.5).
By default, when specifying the HTTPS bindings, you cannot enter a Host Name. The field is disabled.
Apparently, IIS gets confused and sometimes will just return the IP address (or localhost address) for the relative sources for, say images, and other content. (looks like most people had a problem with images relative to the root, that in the generated HTML, had something that looked like https://123.123.123.123/images/imagename.jpeg
instead of
https://www.mywebsite.com/images/imagename.jpeg

To fix, find your certificate and change it's friendly name to *my.certificate.name (just add the asterisk to the beginning of the name) and save. [Use MMC and add the certificate plug in]
Open IIS manager again (if already open, close, then re-open), select your website, go to Bindings and find your https binding type, highlight and click edit.
You will see the Host Name field is now editable. Enter your host name, save and restart IIS.

That's it.

Nop 4.3 running in docker, reverse proxy is Azure application gateway.
Having the same issue, clearing cache does the trick but I'm not sure if it is temporary.
Anyone from Nop team can look into this?

Hello,

It seems that the problem there is if you clear cache on server e not on client side.

I don't know if it is a binding problem.

for example:

https://127.0.0.0:xxx/Admin/ClearCache - create problem

https://www.samples.com/Admin/ClearCache - works fine

hope this help