Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[Dan Winship]

On 10/3/19 10:44 AM, Jean-Francois Maury wrote:
> According to the spec, it's wrong to return 403 in this case. Please re
> read my wording from the spec.

RFC 2616 is the old version of the spec. The revised HTTP/1.1 spec text
explicitly allows either 401 or 403 in this situation:

RFC 7235, 3.1 "401 Unauthorized":

   If the request included authentication credentials, then the 401
   response indicates that authorization has been refused for those
   credentials.  The user agent MAY repeat the request with a new or
   replaced Authorization header field.

RFC 7231, 6.5.3 "403 Forbidden":

   If authentication credentials were provided in the request, the
   server considers them insufficient to grant access.  The client
   SHOULD NOT automatically repeat the request with the same
   credentials.  The client MAY repeat the request with new or different
   credentials.

-- Dan

> Should I understand that there is no plan at all to switch to 401 ?
> 
> Jeff
> 
> On Thu, Oct 3, 2019 at 3:46 PM David Eads  > wrote:
> 
> The 403 is intentional.  The user has been authenticated as
> anonymous, so a 401 isn't returned.  Kubernetes and OpenShift both
> return 403 when a user (even anonymous) attempts to access a
> forbidden resource regardless of whether it even exists.
> 
> On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury
> mailto:jma...@redhat.com>> wrote:
> 
> We are trying to adapt our library but found the following
> problem: when we issue a call to /apis or some of the discovery
> endpoint without authentication info; OCP returns 403 instead of
> 401.
> According to the HTTP spec,403 should not be repeated and
> authentication will not help (see
> https://tools.ietf.org/html/rfc2616#section-10.4.4)
> 
> So is it on purpose or is this going to be fixed ?
> 
> Jeff
> 
> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim
> mailto:adiet...@redhat.com>> wrote:
> 
> Hi Akram
> 
> Thanks for the answer. Insightful.
> For now we can't easily switch libraries given the extent of
> usage and amount of work to migrate.
> 
> Cheers
> André
> 
> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>> Hi André,
>>
>> indeed this is the new default. And, historically, because
>> of a CVE raising an issue about it, dropping discovery of
>> /api has been removed but then temporary restored in 4.1
>> and removed in 4.2.
>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>
>> On the Jenkins plugins we were about to fix similar
>> issues, cause /oapi was deprecated in OCP 4.2 . We depends
>> on kubernetes-client Java library which fixed this.
>> https://github.com/fabric8io/kubernetes-client/issues/1587
>> and follow the different PR. If you depend on this library
>> also, maybe you have your fix in a recent version.
>>
>> Otherwise, IIRC, the eclipse plugin required credentials
>> (or a token) to connect to openshift server, so in your
>> case, you maybe "just" need to use them to then get the
>> endpoints.
>>
>> Akram
>>
>>
>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim
>> mailto:adiet...@redhat.com>> a écrit :
>>
>> Hi
>>
>> In OpenShift 4.2 "/apis" started only being accessible
>> to authorized
>> users. This causes troubles for the Eclipse tooling
>> and the java client
>> library openshift-restclient-java
>> (https://github.com/openshift/openshift-restclient-java)
>> which tries to
>> discover endpoints before authenticating.
>>
>> Thus my question(s):
>>
>> * Is this the new default?
>> * if this restriction is deliberate, what's the
>> reasoning behind it?
>> * Is there a workaround?
>>
>> Thanks for your answers!
>> André
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> 
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> 
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 
> 
> 
> -- 
> 
> Jeff Maury
> 
> Manager, DevTools
> 
> Red Hat EMEA 
> 
> jma..

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[Ben Parees]

On Thu, Oct 3, 2019 at 11:30 AM David Eads  wrote:

> Yes, this is out of upstream, based on downstream choices we made five
> years ago.
>
> This behavior is not considered a bug.  When anonymous authentication is
> enabled, you will only get a 401 if presenting an invalid token or expired
> certificate.  When connecting anonymously, your connection successfully
> authenticated, it is not a 401 condition.  Your successfully authenticated
> connection (successful as anonymous), attempted to access a resource which
> it did not have access to, it is forbidden, getting a 403.
>

Thanks, that explanation helps.


> On Thu, Oct 3, 2019 at 11:18 AM Ben Parees  wrote:
>
>>
>>
>> On Thu, Oct 3, 2019 at 10:52 AM David Eads  wrote:
>>
>>> There is no plan to switch to 401.
>>>
>>
>> Would plans be created if a BZ were opened?  Or this is an outright
>> rejection of ever changing it because it's not deemed incorrect (or because
>> "it's an api now and we can't change it")
>>
>> (Also i assume this is coming out of upstream?)
>>
>>
>>
>>>
>>> On Thu, Oct 3, 2019 at 10:44 AM Jean-Francois Maury 
>>> wrote:
>>>
 According to the spec, it's wrong to return 403 in this case. Please re
 read my wording from the spec.
 Should I understand that there is no plan at all to switch to 401 ?

 Jeff

 On Thu, Oct 3, 2019 at 3:46 PM David Eads  wrote:

> The 403 is intentional.  The user has been authenticated as anonymous,
> so a 401 isn't returned.  Kubernetes and OpenShift both return 403 when a
> user (even anonymous) attempts to access a forbidden resource regardless 
> of
> whether it even exists.
>
> On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
> wrote:
>
>> We are trying to adapt our library but found the following problem:
>> when we issue a call to /apis or some of the discovery endpoint without
>> authentication info; OCP returns 403 instead of 401.
>> According to the HTTP spec,403 should not be repeated and
>> authentication will not help (see
>> https://tools.ietf.org/html/rfc2616#section-10.4.4)
>>
>> So is it on purpose or is this going to be fixed ?
>>
>> Jeff
>>
>> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
>> wrote:
>>
>>> Hi Akram
>>>
>>> Thanks for the answer. Insightful.
>>> For now we can't easily switch libraries given the extent of usage
>>> and amount of work to migrate.
>>>
>>> Cheers
>>> André
>>> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>>>
>>> Hi André,
>>>
>>> indeed this is the new default. And, historically, because of a CVE
>>> raising an issue about it, dropping discovery of /api has been removed 
>>> but
>>> then temporary restored in 4.1 and removed in 4.2.
>>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>>
>>> On the Jenkins plugins we were about to fix similar issues, cause
>>> /oapi was deprecated in OCP 4.2 . We depends on kubernetes-client Java
>>> library which fixed this.
>>> https://github.com/fabric8io/kubernetes-client/issues/1587 and
>>> follow the different PR. If you depend on this library also, maybe you 
>>> have
>>> your fix in a recent version.
>>>
>>> Otherwise, IIRC, the eclipse plugin required credentials (or a
>>> token) to connect to openshift server, so in your case, you maybe "just"
>>> need to use them to then get the endpoints.
>>>
>>> Akram
>>>
>>>
>>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim 
>>> a écrit :
>>>
 Hi

 In OpenShift 4.2 "/apis" started only being accessible to
 authorized
 users. This causes troubles for the Eclipse tooling and the java
 client
 library openshift-restclient-java
 (https://github.com/openshift/openshift-restclient-java) which
 tries to
 discover endpoints before authenticating.

 Thus my question(s):

 * Is this the new default?
 * if this restriction is deliberate, what's the reasoning behind it?
 * Is there a workaround?

 Thanks for your answers!
 André

 ___
 dev mailing list
 dev@lists.openshift.redhat.com
 http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>>
>> --
>>
>> Jeff Maury
>>
>> Manager, DevTools
>>
>> Red Hat EMEA 
>>
>> jma...@redhat.com
>> @RedHat    Red Hat
>>   Red Hat
>> 
>> 

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[David Eads]

Yes, this is out of upstream, based on downstream choices we made five
years ago.

This behavior is not considered a bug.  When anonymous authentication is
enabled, you will only get a 401 if presenting an invalid token or expired
certificate.  When connecting anonymously, your connection successfully
authenticated, it is not a 401 condition.  Your successfully authenticated
connection (successful as anonymous), attempted to access a resource which
it did not have access to, it is forbidden, getting a 403.

On Thu, Oct 3, 2019 at 11:18 AM Ben Parees  wrote:

>
>
> On Thu, Oct 3, 2019 at 10:52 AM David Eads  wrote:
>
>> There is no plan to switch to 401.
>>
>
> Would plans be created if a BZ were opened?  Or this is an outright
> rejection of ever changing it because it's not deemed incorrect (or because
> "it's an api now and we can't change it")
>
> (Also i assume this is coming out of upstream?)
>
>
>
>>
>> On Thu, Oct 3, 2019 at 10:44 AM Jean-Francois Maury 
>> wrote:
>>
>>> According to the spec, it's wrong to return 403 in this case. Please re
>>> read my wording from the spec.
>>> Should I understand that there is no plan at all to switch to 401 ?
>>>
>>> Jeff
>>>
>>> On Thu, Oct 3, 2019 at 3:46 PM David Eads  wrote:
>>>
 The 403 is intentional.  The user has been authenticated as anonymous,
 so a 401 isn't returned.  Kubernetes and OpenShift both return 403 when a
 user (even anonymous) attempts to access a forbidden resource regardless of
 whether it even exists.

 On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
 wrote:

> We are trying to adapt our library but found the following problem:
> when we issue a call to /apis or some of the discovery endpoint without
> authentication info; OCP returns 403 instead of 401.
> According to the HTTP spec,403 should not be repeated and
> authentication will not help (see
> https://tools.ietf.org/html/rfc2616#section-10.4.4)
>
> So is it on purpose or is this going to be fixed ?
>
> Jeff
>
> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
> wrote:
>
>> Hi Akram
>>
>> Thanks for the answer. Insightful.
>> For now we can't easily switch libraries given the extent of usage
>> and amount of work to migrate.
>>
>> Cheers
>> André
>> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>>
>> Hi André,
>>
>> indeed this is the new default. And, historically, because of a CVE
>> raising an issue about it, dropping discovery of /api has been removed 
>> but
>> then temporary restored in 4.1 and removed in 4.2.
>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>
>> On the Jenkins plugins we were about to fix similar issues, cause
>> /oapi was deprecated in OCP 4.2 . We depends on kubernetes-client Java
>> library which fixed this.
>> https://github.com/fabric8io/kubernetes-client/issues/1587 and
>> follow the different PR. If you depend on this library also, maybe you 
>> have
>> your fix in a recent version.
>>
>> Otherwise, IIRC, the eclipse plugin required credentials (or a token)
>> to connect to openshift server, so in your case, you maybe "just" need to
>> use them to then get the endpoints.
>>
>> Akram
>>
>>
>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim 
>> a écrit :
>>
>>> Hi
>>>
>>> In OpenShift 4.2 "/apis" started only being accessible to authorized
>>> users. This causes troubles for the Eclipse tooling and the java
>>> client
>>> library openshift-restclient-java
>>> (https://github.com/openshift/openshift-restclient-java) which
>>> tries to
>>> discover endpoints before authenticating.
>>>
>>> Thus my question(s):
>>>
>>> * Is this the new default?
>>> * if this restriction is deliberate, what's the reasoning behind it?
>>> * Is there a workaround?
>>>
>>> Thanks for your answers!
>>> André
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>
>
> --
>
> Jeff Maury
>
> Manager, DevTools
>
> Red Hat EMEA 
>
> jma...@redhat.com
> @RedHat    Red Hat
>   Red Hat
> 
> 
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>

>>>
>>> --
>>>

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[Ben Parees]

On Thu, Oct 3, 2019 at 10:52 AM David Eads  wrote:

> There is no plan to switch to 401.
>

Would plans be created if a BZ were opened?  Or this is an outright
rejection of ever changing it because it's not deemed incorrect (or because
"it's an api now and we can't change it")

(Also i assume this is coming out of upstream?)



>
> On Thu, Oct 3, 2019 at 10:44 AM Jean-Francois Maury 
> wrote:
>
>> According to the spec, it's wrong to return 403 in this case. Please re
>> read my wording from the spec.
>> Should I understand that there is no plan at all to switch to 401 ?
>>
>> Jeff
>>
>> On Thu, Oct 3, 2019 at 3:46 PM David Eads  wrote:
>>
>>> The 403 is intentional.  The user has been authenticated as anonymous,
>>> so a 401 isn't returned.  Kubernetes and OpenShift both return 403 when a
>>> user (even anonymous) attempts to access a forbidden resource regardless of
>>> whether it even exists.
>>>
>>> On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
>>> wrote:
>>>
 We are trying to adapt our library but found the following problem:
 when we issue a call to /apis or some of the discovery endpoint without
 authentication info; OCP returns 403 instead of 401.
 According to the HTTP spec,403 should not be repeated and
 authentication will not help (see
 https://tools.ietf.org/html/rfc2616#section-10.4.4)

 So is it on purpose or is this going to be fixed ?

 Jeff

 On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
 wrote:

> Hi Akram
>
> Thanks for the answer. Insightful.
> For now we can't easily switch libraries given the extent of usage and
> amount of work to migrate.
>
> Cheers
> André
> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>
> Hi André,
>
> indeed this is the new default. And, historically, because of a CVE
> raising an issue about it, dropping discovery of /api has been removed but
> then temporary restored in 4.1 and removed in 4.2.
> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>
> On the Jenkins plugins we were about to fix similar issues, cause
> /oapi was deprecated in OCP 4.2 . We depends on kubernetes-client Java
> library which fixed this.
> https://github.com/fabric8io/kubernetes-client/issues/1587 and follow
> the different PR. If you depend on this library also, maybe you have your
> fix in a recent version.
>
> Otherwise, IIRC, the eclipse plugin required credentials (or a token)
> to connect to openshift server, so in your case, you maybe "just" need to
> use them to then get the endpoints.
>
> Akram
>
>
> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
> écrit :
>
>> Hi
>>
>> In OpenShift 4.2 "/apis" started only being accessible to authorized
>> users. This causes troubles for the Eclipse tooling and the java
>> client
>> library openshift-restclient-java
>> (https://github.com/openshift/openshift-restclient-java) which tries
>> to
>> discover endpoints before authenticating.
>>
>> Thus my question(s):
>>
>> * Is this the new default?
>> * if this restriction is deliberate, what's the reasoning behind it?
>> * Is there a workaround?
>>
>> Thanks for your answers!
>> André
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>


 --

 Jeff Maury

 Manager, DevTools

 Red Hat EMEA 

 jma...@redhat.com
 @RedHat    Red Hat
   Red Hat
 
 
 
 ___
 dev mailing list
 dev@lists.openshift.redhat.com
 http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

>>>
>>
>> --
>>
>> Jeff Maury
>>
>> Manager, DevTools
>>
>> Red Hat EMEA 
>>
>> jma...@redhat.com
>> @RedHat    Red Hat
>>   Red Hat
>> 
>> 
>> 
>>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>


-- 
Ben Parees | OpenShift
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[David Eads]

There is no plan to switch to 401.

On Thu, Oct 3, 2019 at 10:44 AM Jean-Francois Maury 
wrote:

> According to the spec, it's wrong to return 403 in this case. Please re
> read my wording from the spec.
> Should I understand that there is no plan at all to switch to 401 ?
>
> Jeff
>
> On Thu, Oct 3, 2019 at 3:46 PM David Eads  wrote:
>
>> The 403 is intentional.  The user has been authenticated as anonymous, so
>> a 401 isn't returned.  Kubernetes and OpenShift both return 403 when a user
>> (even anonymous) attempts to access a forbidden resource regardless of
>> whether it even exists.
>>
>> On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
>> wrote:
>>
>>> We are trying to adapt our library but found the following problem: when
>>> we issue a call to /apis or some of the discovery endpoint without
>>> authentication info; OCP returns 403 instead of 401.
>>> According to the HTTP spec,403 should not be repeated and authentication
>>> will not help (see https://tools.ietf.org/html/rfc2616#section-10.4.4)
>>>
>>> So is it on purpose or is this going to be fixed ?
>>>
>>> Jeff
>>>
>>> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
>>> wrote:
>>>
 Hi Akram

 Thanks for the answer. Insightful.
 For now we can't easily switch libraries given the extent of usage and
 amount of work to migrate.

 Cheers
 André
 Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:

 Hi André,

 indeed this is the new default. And, historically, because of a CVE
 raising an issue about it, dropping discovery of /api has been removed but
 then temporary restored in 4.1 and removed in 4.2.
 See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533

 On the Jenkins plugins we were about to fix similar issues, cause /oapi
 was deprecated in OCP 4.2 . We depends on kubernetes-client Java library
 which fixed this.
 https://github.com/fabric8io/kubernetes-client/issues/1587 and follow
 the different PR. If you depend on this library also, maybe you have your
 fix in a recent version.

 Otherwise, IIRC, the eclipse plugin required credentials (or a token)
 to connect to openshift server, so in your case, you maybe "just" need to
 use them to then get the endpoints.

 Akram


 Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
 écrit :

> Hi
>
> In OpenShift 4.2 "/apis" started only being accessible to authorized
> users. This causes troubles for the Eclipse tooling and the java
> client
> library openshift-restclient-java
> (https://github.com/openshift/openshift-restclient-java) which tries
> to
> discover endpoints before authenticating.
>
> Thus my question(s):
>
> * Is this the new default?
> * if this restriction is deliberate, what's the reasoning behind it?
> * Is there a workaround?
>
> Thanks for your answers!
> André
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
 ___
 dev mailing list
 dev@lists.openshift.redhat.com
 http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

>>>
>>>
>>> --
>>>
>>> Jeff Maury
>>>
>>> Manager, DevTools
>>>
>>> Red Hat EMEA 
>>>
>>> jma...@redhat.com
>>> @RedHat    Red Hat
>>>   Red Hat
>>> 
>>> 
>>> 
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>
> --
>
> Jeff Maury
>
> Manager, DevTools
>
> Red Hat EMEA 
>
> jma...@redhat.com
> @RedHat    Red Hat
>   Red Hat
> 
> 
> 
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[Jean-Francois Maury]

According to the spec, it's wrong to return 403 in this case. Please re
read my wording from the spec.
Should I understand that there is no plan at all to switch to 401 ?

Jeff

On Thu, Oct 3, 2019 at 3:46 PM David Eads  wrote:

> The 403 is intentional.  The user has been authenticated as anonymous, so
> a 401 isn't returned.  Kubernetes and OpenShift both return 403 when a user
> (even anonymous) attempts to access a forbidden resource regardless of
> whether it even exists.
>
> On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
> wrote:
>
>> We are trying to adapt our library but found the following problem: when
>> we issue a call to /apis or some of the discovery endpoint without
>> authentication info; OCP returns 403 instead of 401.
>> According to the HTTP spec,403 should not be repeated and authentication
>> will not help (see https://tools.ietf.org/html/rfc2616#section-10.4.4)
>>
>> So is it on purpose or is this going to be fixed ?
>>
>> Jeff
>>
>> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
>> wrote:
>>
>>> Hi Akram
>>>
>>> Thanks for the answer. Insightful.
>>> For now we can't easily switch libraries given the extent of usage and
>>> amount of work to migrate.
>>>
>>> Cheers
>>> André
>>> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>>>
>>> Hi André,
>>>
>>> indeed this is the new default. And, historically, because of a CVE
>>> raising an issue about it, dropping discovery of /api has been removed but
>>> then temporary restored in 4.1 and removed in 4.2.
>>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>>
>>> On the Jenkins plugins we were about to fix similar issues, cause /oapi
>>> was deprecated in OCP 4.2 . We depends on kubernetes-client Java library
>>> which fixed this.
>>> https://github.com/fabric8io/kubernetes-client/issues/1587 and follow
>>> the different PR. If you depend on this library also, maybe you have your
>>> fix in a recent version.
>>>
>>> Otherwise, IIRC, the eclipse plugin required credentials (or a token) to
>>> connect to openshift server, so in your case, you maybe "just" need to use
>>> them to then get the endpoints.
>>>
>>> Akram
>>>
>>>
>>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
>>> écrit :
>>>
 Hi

 In OpenShift 4.2 "/apis" started only being accessible to authorized
 users. This causes troubles for the Eclipse tooling and the java client
 library openshift-restclient-java
 (https://github.com/openshift/openshift-restclient-java) which tries
 to
 discover endpoints before authenticating.

 Thus my question(s):

 * Is this the new default?
 * if this restriction is deliberate, what's the reasoning behind it?
 * Is there a workaround?

 Thanks for your answers!
 André

 ___
 dev mailing list
 dev@lists.openshift.redhat.com
 http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>>
>>
>> --
>>
>> Jeff Maury
>>
>> Manager, DevTools
>>
>> Red Hat EMEA 
>>
>> jma...@redhat.com
>> @RedHat    Red Hat
>>   Red Hat
>> 
>> 
>> 
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>

-- 

Jeff Maury

Manager, DevTools

Red Hat EMEA 

jma...@redhat.com
@RedHat    Red Hat
  Red Hat



___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[David Eads]

The 403 is intentional.  The user has been authenticated as anonymous, so a
401 isn't returned.  Kubernetes and OpenShift both return 403 when a user
(even anonymous) attempts to access a forbidden resource regardless of
whether it even exists.

On Wed, Oct 2, 2019 at 4:06 PM Jean-Francois Maury 
wrote:

> We are trying to adapt our library but found the following problem: when
> we issue a call to /apis or some of the discovery endpoint without
> authentication info; OCP returns 403 instead of 401.
> According to the HTTP spec,403 should not be repeated and authentication
> will not help (see https://tools.ietf.org/html/rfc2616#section-10.4.4)
>
> So is it on purpose or is this going to be fixed ?
>
> Jeff
>
> On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim 
> wrote:
>
>> Hi Akram
>>
>> Thanks for the answer. Insightful.
>> For now we can't easily switch libraries given the extent of usage and
>> amount of work to migrate.
>>
>> Cheers
>> André
>> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>>
>> Hi André,
>>
>> indeed this is the new default. And, historically, because of a CVE
>> raising an issue about it, dropping discovery of /api has been removed but
>> then temporary restored in 4.1 and removed in 4.2.
>> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>>
>> On the Jenkins plugins we were about to fix similar issues, cause /oapi
>> was deprecated in OCP 4.2 . We depends on kubernetes-client Java library
>> which fixed this.
>> https://github.com/fabric8io/kubernetes-client/issues/1587 and follow
>> the different PR. If you depend on this library also, maybe you have your
>> fix in a recent version.
>>
>> Otherwise, IIRC, the eclipse plugin required credentials (or a token) to
>> connect to openshift server, so in your case, you maybe "just" need to use
>> them to then get the endpoints.
>>
>> Akram
>>
>>
>> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
>> écrit :
>>
>>> Hi
>>>
>>> In OpenShift 4.2 "/apis" started only being accessible to authorized
>>> users. This causes troubles for the Eclipse tooling and the java client
>>> library openshift-restclient-java
>>> (https://github.com/openshift/openshift-restclient-java) which tries to
>>> discover endpoints before authenticating.
>>>
>>> Thus my question(s):
>>>
>>> * Is this the new default?
>>> * if this restriction is deliberate, what's the reasoning behind it?
>>> * Is there a workaround?
>>>
>>> Thanks for your answers!
>>> André
>>>
>>> ___
>>> dev mailing list
>>> dev@lists.openshift.redhat.com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>
>
> --
>
> Jeff Maury
>
> Manager, DevTools
>
> Red Hat EMEA 
>
> jma...@redhat.com
> @RedHat    Red Hat
>   Red Hat
> 
> 
> 
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[Jean-Francois Maury]

We are trying to adapt our library but found the following problem: when we
issue a call to /apis or some of the discovery endpoint without
authentication info; OCP returns 403 instead of 401.
According to the HTTP spec,403 should not be repeated and authentication
will not help (see https://tools.ietf.org/html/rfc2616#section-10.4.4)

So is it on purpose or is this going to be fixed ?

Jeff

On Tue, Oct 1, 2019 at 5:56 PM Andre Dietisheim  wrote:

> Hi Akram
>
> Thanks for the answer. Insightful.
> For now we can't easily switch libraries given the extent of usage and
> amount of work to migrate.
>
> Cheers
> André
> Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:
>
> Hi André,
>
> indeed this is the new default. And, historically, because of a CVE
> raising an issue about it, dropping discovery of /api has been removed but
> then temporary restored in 4.1 and removed in 4.2.
> See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533
>
> On the Jenkins plugins we were about to fix similar issues, cause /oapi
> was deprecated in OCP 4.2 . We depends on kubernetes-client Java library
> which fixed this.
> https://github.com/fabric8io/kubernetes-client/issues/1587 and follow the
> different PR. If you depend on this library also, maybe you have your fix
> in a recent version.
>
> Otherwise, IIRC, the eclipse plugin required credentials (or a token) to
> connect to openshift server, so in your case, you maybe "just" need to use
> them to then get the endpoints.
>
> Akram
>
>
> Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
> écrit :
>
>> Hi
>>
>> In OpenShift 4.2 "/apis" started only being accessible to authorized
>> users. This causes troubles for the Eclipse tooling and the java client
>> library openshift-restclient-java
>> (https://github.com/openshift/openshift-restclient-java) which tries to
>> discover endpoints before authenticating.
>>
>> Thus my question(s):
>>
>> * Is this the new default?
>> * if this restriction is deliberate, what's the reasoning behind it?
>> * Is there a workaround?
>>
>> Thanks for your answers!
>> André
>>
>> ___
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>


-- 

Jeff Maury

Manager, DevTools

Red Hat EMEA 

jma...@redhat.com
@RedHat    Red Hat
  Red Hat



___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[Andre Dietisheim]

Hi Akram

Thanks for the answer. Insightful.
For now we can't easily switch libraries given the extent of usage and 
amount of work to migrate.


Cheers
André

Am 01.10.19 um 16:34 schrieb Akram Ben Aissi:

Hi André,

indeed this is the new default. And, historically, because of a CVE 
raising an issue about it, dropping discovery of /api has been removed 
but then temporary restored in 4.1 and removed in 4.2.

See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533

On the Jenkins plugins we were about to fix similar issues, cause 
/oapi was deprecated in OCP 4.2 . We depends on kubernetes-client Java 
library which fixed this.
https://github.com/fabric8io/kubernetes-client/issues/1587 and follow 
the different PR. If you depend on this library also, maybe you have 
your fix in a recent version.


Otherwise, IIRC, the eclipse plugin required credentials (or a token) 
to connect to openshift server, so in your case, you maybe "just" need 
to use them to then get the endpoints.


Akram


Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim > a écrit :


Hi

In OpenShift 4.2 "/apis" started only being accessible to authorized
users. This causes troubles for the Eclipse tooling and the java
client
library openshift-restclient-java
(https://github.com/openshift/openshift-restclient-java) which
tries to
discover endpoints before authenticating.

Thus my question(s):

* Is this the new default?
* if this restriction is deliberate, what's the reasoning behind it?
* Is there a workaround?

Thanks for your answers!
André

___
dev mailing list
dev@lists.openshift.redhat.com 
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Re: in OpenShift 4.2, /apis is not accessible to anonymous users. Workarounds?

[Akram Ben Aissi]

Hi André,

indeed this is the new default. And, historically, because of a CVE raising
an issue about it, dropping discovery of /api has been removed but then
temporary restored in 4.1 and removed in 4.2.
See this https://bugzilla.redhat.com/show_bug.cgi?id=1711533

On the Jenkins plugins we were about to fix similar issues, cause /oapi was
deprecated in OCP 4.2 . We depends on kubernetes-client Java library which
fixed this.
https://github.com/fabric8io/kubernetes-client/issues/1587 and follow the
different PR. If you depend on this library also, maybe you have your fix
in a recent version.

Otherwise, IIRC, the eclipse plugin required credentials (or a token) to
connect to openshift server, so in your case, you maybe "just" need to use
them to then get the endpoints.

Akram


Le mar. 1 oct. 2019 à 15:38, Andre Dietisheim  a
écrit :

> Hi
>
> In OpenShift 4.2 "/apis" started only being accessible to authorized
> users. This causes troubles for the Eclipse tooling and the java client
> library openshift-restclient-java
> (https://github.com/openshift/openshift-restclient-java) which tries to
> discover endpoints before authenticating.
>
> Thus my question(s):
>
> * Is this the new default?
> * if this restriction is deliberate, what's the reasoning behind it?
> * Is there a workaround?
>
> Thanks for your answers!
> André
>
> ___
> dev mailing list
> dev@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
___
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev