Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Basic Authenticator response to OPTIONS request with 401

Yes, disabling authentication for OPTIONS does work to make the CORS header appear, of course.

Somehow it feels not right to solve it this way. Although the spec doesn't explicitly mention this at any point, but I believe CORS header params should always be present, not matter what http status code the response is returning. with the current CORS implementation in jetty, this cannot be achieved.   

------ Original Message ------
From: "Greg Wilkins" <gregw@xxxxxxxxxxx>
To: "Gregor Jarisch" <gregor@xxxxxxxxxxx>
Cc: "JETTY user mailing list" <jetty-users@xxxxxxxxxxx>; "Joakim Erdfelt" <joakim@xxxxxxxxxxx>
Sent: 05/21/2019 9:08:25 AM
Subject: Re: Re[3]: [jetty-users] Basic Authenticator response to OPTIONS request with 401

Gregor,

Have you tried using http-method and/or http-method-omission to avoid applying your security constraint to the OPTION method?
That is the only way that we can allow an OPTION method to hit the filter, because filters are after security.

The other approach is to port the behaviour from the filter into a handler that can be applied before the context.  I'm not exactly sure if this is general purpose enough for us to do, at least not until we understand why the option above is not possible.    It is something that you could do and perhaps contribute in a PR.

Either way, please do open an issue for this, so we can record the issue and whatever solution.

regards











On Mon, 20 May 2019 at 11:57, Gregor Jarisch <gregor@xxxxxxxxxxx> wrote:
Any further thoughts here?

Certainly this is a problem that should be fixed. 

Options:
*) you guys fix it. should I open a issue for it?
*) I fix it on my side only. What is the best approach to do that?

Thanks
Gregor

------ Original Message ------
From: "Gregor Jarisch" <gregor@xxxxxxxxxxx>
To: "Greg Wilkins" <gregw@xxxxxxxxxxx>; "JETTY user mailing list" <jetty-users@xxxxxxxxxxx>
Cc: "Joakim Erdfelt" <joakim@xxxxxxxxxxx>
Sent: 05/15/2019 11:49:04 AM
Subject: Re[2]: [jetty-users] Basic Authenticator response to OPTIONS request with 401

Hi Greg,

well, as a developer, when I want my server to have CORS enabled, I want them to be enabled and communicated back to the client on ANY request.
So, I agree, cors setting should be one of the first things to happen before security is executed.

How can we accomplish this the best?

Thanks
Gregor

------ Original Message ------
From: "Greg Wilkins" <gregw@xxxxxxxxxxx>
To: "Gregor Jarisch" <gregor@xxxxxxxxxxx>; "JETTY user mailing list" <jetty-users@xxxxxxxxxxx>
Cc: "Joakim Erdfelt" <joakim@xxxxxxxxxxx>
Sent: 05/14/2019 4:14:41 PM
Subject: Re: [jetty-users] Basic Authenticator response to OPTIONS request with 401

According to the spec, if auth fails, the request is not forwarded to any filters or servlets.
So if just excluding OPTIONs from auth does not work (I think it's worth trying that), then you (or we) need to move CO logic to before filters.  Either in a handler or perhaps even a request customiser??



On Mon, 13 May 2019 at 12:10, Gregor Jarisch <gregor@xxxxxxxxxxx> wrote:
Hi,

I am not sure if that will solve my problem entirely. I don't want to disable authentication for any of the methods (this is what the config does, if I understood correctly). 
Want I need is the CrossOriginFilter to be executed all the time, no matter if authentication has succeeded or not. 
Without the Cors header added to the response, browser blocks the request all together and thus no prompting the user for credentials.

Is there a way on how I can achieve this? 

Gregor

------ Original Message ------
From: "Joakim Erdfelt" <joakim@xxxxxxxxxxx>
To: "Gregor Jarisch" <gregor@xxxxxxxxxxx>
Cc: "JETTY user mailing list" <jetty-users@xxxxxxxxxxx>
Sent: 05/12/2019 5:50:30 PM
Subject: Re: Re[2]: [jetty-users] Basic Authenticator response to OPTIONS request with 401

You'll use the <security-constraint> section in your WEB-INF/web.xml, specifically the <web-resource-collection> and one of (or a combination of) the two options <http-method> or <http-method-omission>.

Here's an example from the Jetty webdefault.xml for disabling TRACE, but enabling everything other http method.

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Disable TRACE</web-resource-name>
      <url-pattern>/</url-pattern>
      <http-method>TRACE</http-method>
    </web-resource-collection>
    <auth-constraint/>
  </security-constraint>
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Enable everything but TRACE</web-resource-name>
      <url-pattern>/</url-pattern>
      <http-method-omission>TRACE</http-method-omission>
    </web-resource-collection>
  </security-constraint>

Joakim Erdfelt / joakim@xxxxxxxxxxx


On Sat, May 11, 2019 at 5:23 AM Gregor Jarisch <gregor@xxxxxxxxxxx> wrote:
Hi Joakim,

yes, I had the same thought, it would be great to avoid running through the Authenticator on OPTIONS, but how? 
I haven't found an option to do that in jetty.

Gregor

Gregor Jarisch
Head of Research & Development
Labs.ai Technology GmbH
m: +43 699 1 822 74 47

------ Original Message ------
From: "Joakim Erdfelt" <joakim@xxxxxxxxxxx>
To: "Gregor Jarisch" <gregor@xxxxxxxxxxx>; "JETTY user mailing list" <jetty-users@xxxxxxxxxxx>
Sent: 05/10/2019 5:25:19 PM
Subject: Re: [jetty-users] Basic Authenticator response to OPTIONS request with 401

Perhaps its best to not have OPTIONS covered by Authentication?

The problem is that standard Servlet Authentication is early, super early, before any filter or servlet is called early.

Joakim Erdfelt / joakim@xxxxxxxxxxx


On Fri, May 10, 2019 at 10:20 AM Gregor Jarisch <gregor@xxxxxxxxxxx> wrote:
Hi,

when using the CORS Filter + Basic Authentication, jetty returns a 401 when a client makes an OPTIONS call.
Within the CORS Filter the preflight handling is done correctly, however, it never gets there because jetty returns the 401 before hand.

Is there any way to let the CORS Filter handle the request first?

My current workaround is overriding the verify method and exclude the setting of 401 if method is OPTIONS. This workaround feels not right though..

Gregor
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
_______________________________________________
jetty-users mailing list
jetty-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users


--


--

Back to the top