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 <[email protected]> wrote: > > > On Thu, Oct 3, 2019 at 10:52 AM David Eads <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 >>>>>>> [email protected] >>>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>>>>>> >>>>>> _______________________________________________ >>>>>> dev mailing list >>>>>> [email protected] >>>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Jeff Maury >>>>> >>>>> Manager, DevTools >>>>> >>>>> Red Hat EMEA <https://www.redhat.com> >>>>> >>>>> [email protected] >>>>> @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 >>>>> [email protected] >>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >>>>> >>>> >>> >>> -- >>> >>> Jeff Maury >>> >>> Manager, DevTools >>> >>> Red Hat EMEA <https://www.redhat.com> >>> >>> [email protected] >>> @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 >> [email protected] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> > > > -- > Ben Parees | OpenShift > >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
