Fallback to <img> loading on XHR failure

[VeryStrongFingers]

Would it be worthwhile to attempt the loading of the fallback pixel image, in the case of XHR failure?

shynet/shynet/analytics/templates/analytics/scripts/page.js

Lines 23 to 34 in 213c44a

	xhr.send(
	JSON.stringify({
	idempotency: Shynet.idempotency,
	referrer: document.referrer,
	location: window.location.href,
	loadTime:
	window.performance.timing.domContentLoadedEventEnd -
	window.performance.timing.navigationStart,
	})
	);
	} catch (e) { }
	},

The pixel CORS header will always allow any host to connect

shynet/shynet/analytics/views/ingress.py

Lines 89 to 92 in 510df19

	resp = HttpResponse(data, content_type="image/gif")
	resp["Cache-Control"] = "no-cache"
	resp["Access-Control-Allow-Origin"] = "*"
	return resp

so in the event of a CORS (or other) failure on XHR - falling back to loading the <img src="..../pixel.gif"> would theoretically work.

I'm happy to do a PR for it, if deemed appropriate

[milesmcc]

Hmm. Thanks for pointing this out. You may have honestly found a bug — the CORS headers of the image shouldn’t be * always. Instead, they should match that of the script.

Hmm.

[VeryStrongFingers]

@milesmcc CORS doesn't apply to <img> tags according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#What_requests_use_CORS
Might not even need that header at all

[milesmcc]

Thanks for pointing out this issue. I realize the fix may have been the exact opposite of what you expected---origin checking is now enforced for images too---but that's ultimately a security consideration. I thought that CORS was enforced for images, so when you pointed out that it wasn't, I realized that meant there was a way to get around origin enforcement!