У меня есть прокси-сервер Keycloak Gatekeeper (https://localhost: 8080 ) перед моим приложением (http://localhost: 8081 ) для разгрузки OAuth2. Он подключается к серверу Keycloak (https://keycloak.my.company). Вход и доступ к приложению через Gatekeeper работает нормально.
Теперь у меня есть фрагмент AJAX, который выполняется каждые 10 секунд для перезагрузки определенного содержимого. Это работает только до истечения времени жизни JWT. Затем Gatekeeper отправляет перенаправление на Keycloak (как и должно быть), но запрос AJAX не может последовать из-за ошибки CORS.
Запросы выглядят так:
OPTIONS https://keycloak.my.company/auth/realms/demo/protocol/openid-connect/auth
? client_id=demo-app-spring
& redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Foauth%2Fcallback
& response_type=code
& scope=openid+email+profile
& state=33a3da4d-1c83-4363-857c-511b26706649
Host: keycloak.my.company
User-Agent: ...
Accept: */*
Accept-Language: ...
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: x-requested-with
Origin: http://localhost:8080
DNT: 1
Connection: keep-alive
Ответ:
HTTP/1.1 200 OK
Content-Length: 93
Content-Type: application/json
Date: Mon, 20 Jan 2020 14:20:33 GMT
Set-Cookie: _0bc78=http://172.26.12.34:8080; Path=/
Vary: Accept-Encoding
Firefox говорит мне:
Quellübergreifende (перекрестное происхождение) Anfrage blockiert: Die Gleiche-Quelle-Regel verbietet das Lesen der externen Ресурс auf https://keycloak.my.company/auth/realms/demo/p… nid + электронная почта + профиль и состояние = c758c30a-1c1 c -46f7-9155-f71b906ac61a. (Grund: CORS-Kopfzeile 'Access-Control-Allow-Origin' fehlt).
(перевод: заблокировано как Same-Origin-Policy запрещает чтение ресурса. Причина Заголовок CORS 'Access-Control- Allow-Origin 'отсутствует)
Вопросы, которые приходят мне в голову:
- Почему перенаправление не считается "простым запросом CORS" из-за X-Requested- С заголовком?
- Почему Keycloak не отвечает на запрос CORS? Он имеет "+" в качестве CORS Origin и "https://localhost: 8080 / *" в качестве действительного URL перенаправления
- Является ли это правильным способом для обновления sh токена в конце концов? Или стандартный мандат, что клиент (Javascript) проверяет время жизни и обновляет JWT до того, как выполнит фактический запрос?
Заранее благодарим за любые подсказки !
Редактировать: Конфигурация:
verbose: true
listen: :8080
redirection-url: https://localhost:8080
tls-cert: local/localhost.crt
tls-private-key: local/localhost.key
upstream-url: http://localhost:8081/
skip-upstream-tls-verify: true
client-id: demo-app-spring
client-secret: xxx
discovery-url: https://keycloak.my.company/auth/realms/internal
secure-cookie: true
enable-logging: true
enable-refresh-tokens: true
encryption-key: xxx
store-url: redis://localhost:6379/
enable-default-deny: true
resources:
- uri: /
white-listed: true
...
enable-cors: true
cors-origins:
- 'https://localhost:8080'
...
cors-methods:
- GET
- POST
- OPTIONS
- DELETE
- PUT
cors-headers:
- authorization
- content-type
- Cookie
- authorization
- content-type
- accept
- x-requested-with
- origin
- referer
Мои первые попытки были без перенаправления. С Redis я теперь сталкиваюсь с проблемами, описанными в https://issues.redhat.com/browse/KEYCLOAK-11077