Re: How to identify OpenShift v4?

Cool glad it helped. On Thu, Oct 3, 2019 at 4:31 PM Andre Dietisheim wrote: > Hi Gabe > > great pointers, exactly what I needed, thanks a lot! > > Cheers > Andre > Am 03.10.19 um 18:44 schrieb Gabe Montero: > > > > On Thu, Oct 3, 2019 at 11:47 AM Andre Dietisheim > wrote: > >> Hi >> >> Since

Re: How to identify OpenShift v4?

Hi Gabe great pointers, exactly what I needed, thanks a lot! Cheers Andre Am 03.10.19 um 18:44 schrieb Gabe Montero: On Thu, Oct 3, 2019 at 11:47 AM Andre Dietisheim > wrote: Hi Since the endpoint "/version/openshift" is gone, how can a client

Re: How to identify OpenShift v4?

On Thu, Oct 3, 2019 at 11:47 AM Andre Dietisheim wrote: > Hi > > Since the endpoint "/version/openshift" is gone, how can a client > library identify the OpenShift version it deals with? > I believe "/version" still exists, just not "/version/openshift". Here is how the openshift jenkins login

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

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

How to identify OpenShift v4?

Hi Since the endpoint "/version/openshift" is gone, how can a client library identify the OpenShift version it deals with? Thanks for your pointers! Cheers André ___ dev mailing list dev@lists.openshift.redhat.com

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

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 >

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

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

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

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

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

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

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

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

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

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