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 <de...@redhat.com> 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 <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 <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 <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 <https://www.redhat.com>
>>
>> jma...@redhat.com
>> @RedHat <https://twitter.com/redhat>   Red Hat
>> <https://www.linkedin.com/company/red-hat>  Red Hat
>> <https://www.facebook.com/RedHatInc>
>> <https://www.redhat.com>
>> <https://redhat.com/summit>
>> _______________________________________________
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>

-- 

Jeff Maury

Manager, DevTools

Red Hat EMEA <https://www.redhat.com>

jma...@redhat.com
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
<https://redhat.com/summit>
_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to