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?

Commencez par reproduire le flux de connexion dans Chrome et inspectez la requête /jwks ainsi que sa réponse 304 mise en cache, en utilisant les erreurs de console et les en-têtes de requête décrits ici. Suivez la manière dont le serveur génère les en-têtes CORS et de cache pour ce point de terminaison ; le travail est terminé lorsque le passage de test1 à test2 ne réutilise plus une réponse spécifique à une origine et que la connexion automatique réussit.