Enable wildcard CORS support

[i-am-shodan]

Enable wildcard CORS support

[i-am-shodan]

I think what's happening in this case is that the CORS preflight check isn't returning a success code

[jayjb]

Hi @i-am-shodan,

Thanks for reporting in. This is an interesting use case. Am i correct in assuming that you are trying to use

.ext-footer
{
    background-image: url('<LINK>');
    background-size: 0 0;
}

where you replace the <LINK> with a web image bug?

[i-am-shodan]

Yep thats it. Looking a the browser it fails the CORS preflight check.

[i-am-shodan]

Worth saying I can also get this use case to work if I host the image on a service I control and correctly set a wildcard CORS policy.

[jayjb]

Hi @i-am-shodan,

Would you minding trying this using a "custom web image bug"? I see we added support for CORS (here)

[i-am-shodan]

I've tried both

[jayjb]

@i-am-shodan, can you check the response header contains the Access-Control-Allow-Origin: *? In my test now, it is there. So when you browse to that login page, have the browser dev tools open on the Network tab; you should be able to inspect the request and response.

[i-am-shodan]

curl -vvv http://MYHOSTNAME/terms/traffic/npxix77cb0qfqf6aidlo6lj9p/img.png

> GET /terms/traffic/npxix77cb0qfqf6aidlo6lj9p/img.png HTTP/1.1
> Host: MYHOSTNAME 
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 15 Jan 2024 14:05:56 GMT
< Content-Type: image/png
< Content-Length: 120
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< 

But I think the problem here (at least what the browser is reporting to me) is that it's failing the CORS preflight check (https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request). I have constructed one of these with:
curl -vvv -X OPTIONS -H "Access-Control-Request-Method: GET" -H "Access-Control-Request-Headers: origin, x-requested-with" -H "Origin: https://foo.bar.org" http://MYHOSTNAME /terms/traffic/npxix77cb0qfqf6aidlo6lj9p/img.png

I should be returning headers like:

Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400

But it isn't, this is what I get

* TCP_NODELAY set
* Connected to MYHOSTNAME (20.67.24.220) port 80 (#0)
> OPTIONS /terms/traffic/npxix77cb0qfqf6aidlo6lj9p/img.png HTTP/1.1
> Host: MYHOSTNAME 
> User-Agent: curl/7.68.0
> Accept: */*
> Access-Control-Request-Method: DELETE
> Access-Control-Request-Headers: origin, x-requested-with
> Origin: https://foo.bar.org
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 15 Jan 2024 14:04:35 GMT
< Content-Length: 0
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< Allow: OPTIONS, GET, POST
< 

So my guess is that it's failing the preflight because Access-Control-Allow-Methods and Access-Control-Max-Age are not set.

[i-am-shodan]

Worth saying that with Chrome + Edges devtools the request never appears because preflight fails

[jayjb]

Hi @i-am-shodan,

Thanks so much for all the detail. I've been reading up on this and it looks like you are correct. Ill be adding some preflight handling today.

[jayjb]

Hi @i-am-shodan,

Please could you give it another shot using a custom web image token? I've added cors preflight support

[i-am-shodan]

Success! Thanks for implementing this.

FYI, another thing that is also needed for the scenario is for everything to be under TLS.