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 <de...@redhat.com > <mailto: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 <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 > <adiet...@redhat.com <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 >> <adiet...@redhat.com <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 >> <mailto:dev@lists.openshift.redhat.com> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> > _______________________________________________ > dev mailing list > dev@lists.openshift.redhat.com > <mailto: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 <mailto: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 > <mailto: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 <mailto: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 > _______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
