On Thu, Oct 3, 2019 at 11:30 AM David Eads <de...@redhat.com> 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 <bpar...@redhat.com> wrote: > >> >> >> On Thu, Oct 3, 2019 at 10:52 AM David Eads <de...@redhat.com> 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 <jma...@redhat.com> >>> 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 <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 >>> >> >> >> -- >> Ben Parees | OpenShift >> >> -- Ben Parees | OpenShift
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
