| Summary: | [4.1] RequestHeader IdP - `oc login` fails because oauth-server sets incompatible headers | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Mo <mkhan> |
| Component: | apiserver-auth | Assignee: | Standa Laznicka <slaznick> |
| Status: | CLOSED ERRATA | QA Contact: | Wei Sun <wsun> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.1.0 | CC: | aos-bugs, apaladug, mfojtik, mkhan, slaznick |
| Target Milestone: | --- | Keywords: | OSE41z_next |
| Target Release: | 4.1.z | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1750786 | Environment: | |
| Last Closed: | 2019-10-16 18:07:59 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | 1750786 | ||
| Bug Blocks: | 1739262 | ||
|
Description
Mo
2019-09-10 14:00:57 UTC
Adding as blocking to another BZ w/ customer case as without this fix, the Request Headers IdP won't work for them. Verified on 4.1.0-0.nightly-2019-09-27-171543 $ curl -k -H "X-Csrf-Token: 1" 'https://oauth-openshift.apps.chuyu.qe.devcluster.openshift.com/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -v * Trying 10.0.96.164:443... * TCP_NODELAY set * Connected to oauth-openshift.apps.chuyu.qe.devcluster.openshift.com (10.0.96.164) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Request CERT (13): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=*.apps.chuyu.qe.devcluster.openshift.com * start date: Sep 29 02:07:50 2019 GMT * expire date: Sep 28 02:07:51 2021 GMT * issuer: CN=ingress-operator@1569722870 * SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway. > GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1 > Host: oauth-openshift.apps.chuyu.qe.devcluster.openshift.com > User-Agent: curl/7.65.3 > Accept: */* > X-Csrf-Token: 1 > * Mark bundle as not supporting multiuse < HTTP/1.1 302 Found < Cache-Control: no-cache, no-store, max-age=0, must-revalidate < Expires: 0 < Location: https://oauth-proxy-httpd.usersys.redhat.com/challenging-proxy/oauth/authorize?client_id=openshift-challenging-client&response_type=token < Pragma: no-cache < Referrer-Policy: strict-origin-when-cross-origin < X-Content-Type-Options: nosniff < X-Dns-Prefetch-Control: off < X-Frame-Options: DENY < X-Xss-Protection: 1; mode=block < Date: Sun, 29 Sep 2019 02:19:51 GMT < Content-Length: 0 < * Connection #0 to host oauth-openshift.apps.chuyu.qe.devcluster.openshift.com left intact @ Standa Now that this is verified, can I assume that 1739262 is also fixed ? Thanks Anand I would expect that, yes. Thanks Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3004 |