[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26869:
-------------------------------------
Comment: was deleted
(was: Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should use the full url that's reported as authentication endpoint. The client library currently maps the host portion to the known REST service host.
In full details:
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize* instead of *oauth-openshift.apps-crc.testing/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
)
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26869 at 10/25/19 5:38 PM:
--------------------------------------------------------------------
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should use the full url that's reported as authentication endpoint. The client library currently maps the host portion to the known REST service host.
In full details:
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize* instead of *oauth-openshift.apps-crc.testing/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
was (Author: adietish):
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should use the full url that's reported as authentication endpoint. The client library currently maps the host portion to the known REST service host.
In full details:
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize* instead of *https://oauth-openshift.apps-crc.testing/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26869 at 10/25/19 5:37 PM:
--------------------------------------------------------------------
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should use the full url that's reported as authentication endpoint. The client library currently maps the host portion to the known REST service host.
In full details:
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize* instead of *https://oauth-openshift.apps-crc.testing/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
was (Author: adietish):
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should use the full url that's reported as authentication endpoint. The client library currently maps the host portion to the known REST service host.
In full details:
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26869 at 10/25/19 5:36 PM:
--------------------------------------------------------------------
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should use the full url that's reported as authentication endpoint. The client library currently maps the host portion to the known REST service host.
In full details:
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
was (Author: adietish):
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26869 at 10/25/19 5:33 PM:
--------------------------------------------------------------------
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases in crc and on all online variants this works just fine and wont report an error.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
was (Author: adietish):
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases and on all online variants this works just fine.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26869 at 10/25/19 5:32 PM:
--------------------------------------------------------------------
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint (*<REST-service-host>/oauth/authorize*).
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases and on all online variants this works just fine.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
was (Author: adietish):
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint.
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases and on all online variants this works just fine.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim edited comment on JBIDE-26869 at 10/25/19 5:31 PM:
--------------------------------------------------------------------
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the one of the known REST-endpoint.
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases and on all online variants this works just fine.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
was (Author: adietish):
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the host of the REST-endpoint.
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases and on all online variants this works just fine.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26869) CRC server adapter: OpenShift connection that is created is unusable at times
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26869?page=com.atlassian.jira.plugi... ]
André Dietisheim commented on JBIDE-26869:
------------------------------------------
Digging further I found out the following: when this happens, the request to retrieve the token via the REST service fails with a 403 while when done via the Web-Site URL things work properly.
In the client library we retrieve the authorization endpoint via the unprotected url *<REST-service-host>/.well-known/oauth-authorization-server*. We then get the following json:
{code}
{
...
"authorization_endpoint": "https://oauth-openshift.apps-crc.testing/oauth/authorize",
...
{code}
The REST client then only uses the path and replaces the host with the host of the REST-endpoint.
The client requests:
{code}
curl -k -v "https://api.crc.testing:6443/oauth/authorize?response_type=token&client_i..."
{code}
and gets an error:
{code}
< HTTP/2 403
< audit-id: 4416d6ab-5f0a-4bab-b5b3-507e9a6aa319
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< content-length: 248
< date: Fri, 25 Oct 2019 20:43:11 GMT
<
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {
},
"status": "Failure",
"message": "forbidden: User \"system:anonymous\" cannot get path \"/oauth/authorize\"",
"reason": "Forbidden",
"details": {
},
"code": 403
{code}
Re-requesting won't help, you always get the same error back.
In 8/10 cases and on all online variants this works just fine.
If you instead then use the host that's provided in the json and request
{code}
curl -k -H "X-CSRF-Token:1" "https://oauth-openshift.apps-crc.testing/oauth/authorize?response_type=to..." -v -H "X-OPENSHIFT-AUTH-ATTEMPTS: 1" -H "Authorization: Basic ZGV2ZWxvcGVyOmRldmVsb3Blcg=="
{code}
You get the token via the following response:
{code}
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: https://oauth-openshift.apps-crc.testing/oauth/token/implicit#access_toke...
< Pragma: no-cache
< Pragma: no-cache
< Referrer-Policy: strict-origin-when-cross-origin
< Set-Cookie: ssn=MTU3MjAzNTQxOHxSZ2N0YXNjZENEMGx2Qk9zTHBidDZQQzIwU3kwMnNjMEh3VGRwTk5GcmRqemFEaXV0M0lnOW5wMmR1bUV3cjE1RUdYU1h3NXZKMWhiRDVtczFqcTJUY2I2MEQyVDI0RWNEc1I0U1k1UjlVT2pWV3hFcGREOFZIajBqWHlLbWo3OHduU0xXeGJzSmZIbG5reEpabUJqTDVOcy1oQkFMSGxHQXc9PXzPAWZ_kLR1ZzE8gHpjwIrj8y_enudtAwsN09vQGToCCw==; Path=/; HttpOnly; Secure
< X-Content-Type-Options: nosniff
< X-Dns-Prefetch-Control: off
< X-Frame-Options: DENY
< X-Xss-Protection: 1; mode=block
< Date: Fri, 25 Oct 2019 20:30:18 GMT
{code}
The token is in the *Location* header (access_token=).
It thus looks to me as if in these failure cases, CRC didnt start up correctly, portions failed to come up.
To solve this issue we should request on the host that's reported in the json, not replace it by the known REST endpoint. We'd also have to verify that requesting in this way also works for OpenShift 3.x. Chances are high given that the latter also reports in the same way, at least from what I can see in employee.openshift.com.
> CRC server adapter: OpenShift connection that is created is unusable at times
> -----------------------------------------------------------------------------
>
> Key: JBIDE-26869
> URL: https://issues.jboss.org/browse/JBIDE-26869
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.AM1
> Environment: CRC Beta5
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Critical
> Fix For: 4.13.0.Final, 4.14.0.AM1
>
> Attachments: crc-connection-error.mp4, start-crc-error-openshift-conn.mp4
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> *Result:*
> Connection fails to authorize, reports that it cannot access resources using system:anonymous. Refreshing the connection doesn't help, so it's apparently not a timing issue (ex. creating the connection before the cluster is fully up and running)
> {code}
> com.openshift.restclient.authorization.ResourceForbiddenException: forbidden: User "system:anonymous" cannot get path "/oauth/authorize" forbidden: User "system:anonymous" cannot get path "/oauth/authorize"
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.createOpenShiftException(ResponseCodeInterceptor.java:111)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:66)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.tryAuth(OpenShiftAuthenticator.java:109)
> at com.openshift.internal.restclient.okhttp.OpenShiftAuthenticator.authenticate(OpenShiftAuthenticator.java:62)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.followUpRequest(RetryAndFollowUpInterceptor.kt:213)
> at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:102)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at com.openshift.internal.restclient.okhttp.ResponseCodeInterceptor.intercept(ResponseCodeInterceptor.java:55)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
> at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
> at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
> at okhttp3.RealCall.execute(RealCall.kt:66)
> at com.openshift.internal.restclient.DefaultClient.request(DefaultClient.java:315)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:307)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:275)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:243)
> at com.openshift.internal.restclient.DefaultClient.execute(DefaultClient.java:226)
> at com.openshift.internal.restclient.DefaultClient.get(DefaultClient.java:423)
> at com.openshift.internal.restclient.authorization.AuthorizationContext.isAuthorized(AuthorizationContext.java:63)
> at org.jboss.tools.openshift.core.connection.Connection.authorize(Connection.java:237)
> at org.jboss.tools.openshift.core.connection.Connection.connect(Connection.java:226)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureOpenshift(ConfigureCRCFrameworksListener.java:102)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener.configureFrameworks(ConfigureCRCFrameworksListener.java:73)
> at org.jboss.tools.openshift.internal.crc.server.core.listeners.ConfigureCRCFrameworksListener$1.run(ConfigureCRCFrameworksListener.java:66)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBDS-4805) Error With Reccommenders: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct at org.eclipse.recommenders.internal.rcp.RcpModule$Listener$1.afterInjection(RcpModule.java:278)
by David Guthrie (Jira)
David Guthrie created JBDS-4805:
-----------------------------------
Summary: Error With Reccommenders: java.lang.NoClassDefFoundError: javax/annotation/PostConstruct at org.eclipse.recommenders.internal.rcp.RcpModule$Listener$1.afterInjection(RcpModule.java:278)
Key: JBDS-4805
URL: https://issues.jboss.org/browse/JBDS-4805
Project: Red Hat CodeReady Studio (devstudio)
Issue Type: Bug
Affects Versions: 12.12.0.GA
Environment: * eclipse.buildId=12.12.0.GA-v20190628-0434-B4598
java.version=11.0.3-redhat
java.vendor=Oracle Corporation
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_US
Framework arguments: -application org.eclipse.ui.ide.workbench -product com.jboss.devstudio.core.product
Command-line arguments: -os win32 -ws win32 -arch x86_64 -application org.eclipse.ui.ide.workbench -product com.jboss.devstudio.core.product
* Camel Fuse development
Reporter: David Guthrie
Customer:
{quote}
I did an upgrade on Code Ready Studio to 12.12
and when I go from
{code}
public void configure() throws Exception {
from("file:E:/inputFolder")
.split().tokenize("\n")
.to("jms:queue:javininusex");
}
{code}
to
{code}
@Override
public void configure() throws Exception {
from("{{route.start}}")
.split().tokenize("\n")
.log("{{route.start}}")
.to("{{route.end}}");
}
{code}
it starts show an error on the {{xxxx}} lines. which then sometimes goes to a pop up window that says check the recommender faq at .... (now this won't pop up and I didn't get the address) that is an invalid page.
{quote}
Log error
org.eclipse.recommenders.completion.rcp
Error
Fri Oct 18 13:53:29 PDT 2019
Session processor ‘class org.eclipse.recommenders.internal.calls.rcp.CallCompletionSessionProcessor’ failed with exception.
{code}
java.lang.NoClassDefFoundError: javax/annotation/PostConstruct
at org.eclipse.recommenders.internal.rcp.RcpModule$Listener$1.afterInjection(RcpModule.java:278)
at com.google.inject.internal.MembersInjectorImpl.notifyListeners(MembersInjectorImpl.java:97)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:95)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:65)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:54)
at com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:38)
at com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:62)
at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:84)
at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)
at com.google.inject.internal.FactoryProxy.get(FactoryProxy.java:54)
at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at com.google.inject.Scopes$1$1.get(Scopes.java:65)
at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
at com.google.inject.internal.InjectorImpl$4$1.call(InjectorImpl.java:978)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)
at com.google.inject.internal.InjectorImpl$4.get(InjectorImpl.java:974)
at org.eclipse.recommenders.internal.calls.rcp.CallCompletionSessionProcessor.findReceiverTypeAndModel(CallCompletionSessionProcessor.java:136)
at org.eclipse.recommenders.internal.calls.rcp.CallCompletionSessionProcessor.startSession(CallCompletionSessionProcessor.java:111)
at org.eclipse.recommenders.completion.rcp.processable.IntelligentCompletionProposalComputer.fireStartSession(IntelligentCompletionProposalComputer.java:305)
at org.eclipse.recommenders.completion.rcp.processable.IntelligentCompletionProposalComputer.computeCompletionProposals(IntelligentCompletionProposalComputer.java:171)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalComputerDescriptor.computeCompletionProposals(CompletionProposalComputerDescriptor.java:336)
at org.eclipse.jdt.internal.ui.text.java.CompletionProposalCategory.computeCompletionProposals(CompletionProposalCategory.java:340)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.collectProposals(ContentAssistProcessor.java:334)
at org.eclipse.jdt.internal.ui.text.java.ContentAssistProcessor.computeCompletionProposals(ContentAssistProcessor.java:291)
at org.eclipse.jface.text.contentassist.ContentAssistant$2.lambda$0(ContentAssistant.java:2014)
at java.base/java.util.Collections$SingletonSet.forEach(Collections.java:4795)
at org.eclipse.jface.text.contentassist.ContentAssistant$2.run(ContentAssistant.java:2013)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at org.eclipse.jface.text.contentassist.ContentAssistant.computeCompletionProposals(ContentAssistant.java:2010)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.computeProposals(CompletionProposalPopup.java:575)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.lambda$0(CompletionProposalPopup.java:505)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:72)
at org.eclipse.jface.text.contentassist.CompletionProposalPopup.showProposals(CompletionProposalPopup.java:500)
at org.eclipse.jface.text.contentassist.ContentAssistant$AutoAssistListener.lambda$0(ContentAssistant.java:380)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:40)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:185)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3919)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3550)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$5.run(PartRenderingEngine.java:1173)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1062)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:155)
at org.eclipse.ui.internal.Workbench.lambda$3(Workbench.java:635)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:338)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:559)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:155)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:137)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:107)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:660)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:597)
at org.eclipse.equinox.launcher.Main.run(Main.java:1468)
{code}
This seems to be related to upstream issues https://bugs.eclipse.org/bugs/show_bug.cgi?id=541266 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=542689 where recommenders doesn't work with Java 11 and has been removed by upstream eclipse and by the Red Hat Eclipse RPM packages https://issues.jboss.org/browse/RHECLIPSE-82.
I don't see a way to disable recommenders in codeready studio.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0
[JBoss JIRA] (JBIDE-26899) Refreshing non-functional connection to CRC doesnt help (need to create new)
by André Dietisheim (Jira)
[ https://issues.jboss.org/browse/JBIDE-26899?page=com.atlassian.jira.plugi... ]
André Dietisheim updated JBIDE-26899:
-------------------------------------
Comment: was deleted
(was: https://github.com/openshift/openshift-restclient-java/pull/411 fixes the issue.)
> Refreshing non-functional connection to CRC doesnt help (need to create new)
> ----------------------------------------------------------------------------
>
> Key: JBIDE-26899
> URL: https://issues.jboss.org/browse/JBIDE-26899
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.13.0.Final
> Environment: CRC
> Reporter: André Dietisheim
> Assignee: André Dietisheim
> Priority: Major
> Fix For: 4.14.0.AM1
>
>
> *Steps* - not reproducibe at 100%, happens from time to time:
> # ASSERT: have ~/.crc folder killed
> # EXEC: create new CRC server adapter & Start it
> # ASSERT: OpenShift connection is created
> # ASSERT: Connection fails to authorize, reports that it cannot access resources using system:anonymous.
> # EXEC: try to login with *oc login*. If oc reports *Error from server (InternalError): Internal error occurred: unexpected response: 400*, repeat until it succeeds (waiting required)
> # EXEC: Once oc login succeeds: refresh the connection in Eclipse
> Result:
> Connecting still fails with the same error.
> Expected result:
> Refreshing the connection should succeed once the server is fully up and running and oc succeeds to log in.
> Workaround:
> # EXEC: edit the connection instead of refreshing it (ex. remove a character from username and add it back again)
> Result:
> Connecting succeeds
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
- 1
- 0