CORS Issue with Google Chrome

Single Sign On to a profile is blocked by CORS in Google Chrome as https://solid.example.com/jwks is cached by the browser with a particular Access-Control-Allow-Origin header. Tested using Google Chrome Version 75.0.3770.100 and Solid 5.1.6.

Please describe what you did in reproducible steps

Browse to https://solid.example.com
Click Log in
Click the solid.example.com identity provider and login with test1
Visit the test1 profile at https://test1.solid.example.com
Click Log in
Click the test1.solid.example.com identity provider
Click logout
Browse to https://solid.example.com
Click logout

Browse to https://solid.example.com
Click Log in
Click the solid.example.com identity provider and login with test2
Visit the test2 profile at https://test2.solid.example.com
Click Log in
Click the test2.solid.example.com identity provider

Expected behaviour:

Automatic login as test2.

Actual behaviour:

Nothing happens when you click the identity provider.

Any material that will help, logs, error messages, etc.

Details:

The console in Chrome developer tools says:

“Access to fetch at 'https://solid.example.com/jwks' from origin 'https://test2.solid.example.com' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value 'https://test1.solid.example.com' that is not equal to the supplied origin. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://solid.example.com/jwks with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.

The following HTTP request is made for test1:

GET /jwks HTTP/1.1
Host: solid.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://test1.solid.mydomain.com/common/popup.html
Origin: https://test1.solid.mydomain.com
DNT: 1
Connection: keep-alive

The following HTTP response is seen from the server for test1:

HTTP/1.1 200 OK
Date: Wed, 03 Jul 2019 12:00:00 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
X-Powered-By: solid-server/5.1.6
Access-Control-Allow-Origin: https://test1.solid.mydomain.com
Vary: Accept,Authorization,Origin
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Authorization, User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow, WAC-Allow, Content-Length, WWW-Authenticate
Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE
Content-Type: application/json; charset=utf-8
Content-Length: 3090
ETag: W/"c12-rnReKfRAdIl+RoAH4i8+uD1Huqg"
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

{"keys":[{"kid"………………….]}

The following HTTP request is made for test2:

GET /jwks HTTP/1.1
Host: solid.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://test2.solid.mydomain.com/common/popup.html
Origin: https://test2.solid.mydomain.com
DNT: 1
Connection: keep-alive
If-None-Match: W/"c12-rnReKfRAdIl+RoAH4i8+uD1Huqg"

The following HTTP response is seen from the server for test2:

HTTP/1.1 304 Not Modified
Date: Wed, 03 Jul 2019 12:01:00 GMT
Server: Apache
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
ETag: W/"c12-rnReKfRAdIl+RoAH4i8+uD1Huqg"
Vary: Accept,Authorization,Origin

Since the request to /jwks for test2 uses the If-None-Match header the server responds with a HTTP 304 and the browser uses the cached response. Unfortunately the cached response has the “Access-Control-Allow-Origin: https://test1.solid.mydomain.com” header which does not match the origin on https://test2.solid.mydomain.com and the browser blocks the request.

@RubenVerborgh thoughts?

Bắt đầu bằng cách tái hiện luồng đăng nhập trong Chrome và kiểm tra yêu cầu /jwks cùng phản hồi 304 được lưu trong cache của nó, sử dụng các lỗi console và các header của yêu cầu được mô tả ở đây. Theo dõi cách máy chủ tạo các header CORS và cache cho endpoint đó; được xem là hoàn tất khi việc chuyển đổi giữa test1 và test2 không còn sử dụng lại phản hồi dành riêng cho origin và đăng nhập tự động thành công.