Re: [jetty-users] shibboleth idp webapp under jetty 12.0.7

2024-03-26 Thread Greg Wilkins via jetty-users
Paul,

Jetty will extract from to a temp web-inf directory to avoid the jar inside
war class loading issues when a war file is not unpacked.   It should not
be doing this if the webapp is unpacked.  It should definitely not put both
on the classpath.

I think we may have a bug here.  We will investigate.  To better track
this, can you open an issue 
and paste your message in as the description.

regards



On Tue, 26 Mar 2024 at 04:54, Paul B. Henson via jetty-users <
jetty-users@eclipse.org> wrote:

> I'm currently running the shibboleth idp webapp 4 under jetty 9, and
> trying to migrate to idp 5 using jetty 12. I've run into an odd problem,
> I get the following error:
>
> Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'flowRegistry' defined in class path resource
> [net/shibboleth/idp/conf/webflow-config.xml]: Illegal attempt to register
> pre-existing flow ID 'authn/DuoOIDC'via resource: URL
> [jar:file:/var/lib/jetty/tmp/jetty-127_0_0_1-80-idp_war-_idp-any-10824638488520165161/webapp/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar!/META-INF/net/shibboleth/idp/flows/authn/DuoOIDC/duo-oidc-authn-flow.xml]
>
> This generally occurs if there are multiple copies of the jar on the
> classpath, such as if the war accidentally included more than one (which
> isn't the case here).
>
> The deployment descriptor for the idp app is:
>
> 
> /opt/shibboleth-idp/war/idp.war
> /idp
> false
> false
> true
> 
>
> which is the recommended config per the idp documentation. With this
> config, I see two separate copies of the jar in the jetty tmp directory,
> one in webapp and one in webinf:
>
> # find | grep duo
>
> ./webapp/WEB-INF/lib/idp-plugin-duo-nimbus-client-impl-2.0.0.jar
>
> ./webapp/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar
>
> ./webapp/WEB-INF/lib/idp-plugin-duo-api-2.0.0.jar
>
> ./webinf/WEB-INF/lib/idp-plugin-duo-nimbus-client-impl-2.0.0.jar
>
> ./webinf/WEB-INF/lib/idp-plugin-duo-impl-2.0.0.jar
>
> ./webinf/WEB-INF/lib/idp-plugin-duo-api-2.0.0.jar
>
>
> If I update the config and set copyWebInf=false, there's only one copy
> of the jar in the tmp directory (in webapp) and everything works fine.
>
> Looking at my existing jetty 9 deployment, there's only the webinf
> directory in the tmp dir, not the webapp one. If I update my jetty 9
> config and set extractWAR=true, then I get the same multiple copies (one
> in webapp, one in webinf) as I do with extractWAR=false in jetty 12,
> although this doesn't cause an error under jetty 9. If I set
> extractWAR=true under jetty 12, I see no change in the content of the
> tmp directory as compared to extractWAR=false.
>
> So I'm confused. Why is jetty 12 apparently extracting the war when
> extractWAR=false? And when it does, how come the same jar file seems to
> get processed twice, when that doesn't occur under jetty 9 with
> extractWAR=true?
>
> I'm not sure if I'm hitting a bug or have something misconfigured. It
> seems to be working now with copyWebInf=false, but that also seems more
> of a workaround than a resolution. This feels buggy, that jetty is
> extracting the war when it shouldn't be, and also loading the same jars
> from two different places when the war is extracted *and* copyWebInf=true.
> But I'm far from a jetty expert :).
>
> Thanks for any hints...
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Greg Wilkins  CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users


Re: [jetty-users] Problem reading POST body with embedded Jetty 12.0.x

2023-09-11 Thread Greg Wilkins via jetty-users
Silvio,

Let's get your existing code working but then I'd really like to show
you how you can use jetty-12 handlers to do that expansion for you prior to
any buffering and/or blocking input streams.

cheers






On Tue, 12 Sept 2023 at 03:47, Simone Bordet via jetty-users <
jetty-users@eclipse.org> wrote:

> Hi,
>
> On Mon, Sep 11, 2023 at 2:16 PM Silvio Bierman via jetty-users
>  wrote:
> >
> > It appears that all handling of POST requests with ZIP-content as
> > payload in our application is broken with Jetty 12 (I tried both 12.0.0
> > and 12.0.1). We use an embedded Jetty-12 with ee10 and http/2.
> >
> > Using Jetty 11 the code works as expected.
> >
> > We post a ZIP-file from the command line using Curl to the application.
> > The handling code wraps request.getInputStream in a BufferedInputStream
> > wrapped in a ZipInputStream and starts reading ZipEntry objects with
> > getNextEntry until this returns null. With Jetty 12 this code only
> > manages to read the first part of the POST-body and then blocks
> > indefinitely. This is not a multi-part request, the ZIP-content is
> > simply used as the request payload.
> >
> > We have similar handling of ZIP-files posted from inside HTML pages
> > (using JS FormData and XmlHttpRequest) and the same thing happens there.
> > In this case the FormData is used to create a multi-part POST.
> >
> > Each time the first parts of the payload seems to be handled correctly.
> > The initial entries are expanded and written to server side files
> > correctly.
> >
> > No exceptions occur. The code just seems to block indefinitely with no
> > CPU activity.
> >
> > Any ideas? Perhaps there is something wrong with our embedding code?
>
> Please open an issue with the code example, where it throws, and the
> stack trace.
> GH issues are better for this kind of analysis.
>
> Thanks!
>
> --
> Simone Bordet
> 
> http://cometd.org
> http://webtide.com
> Developer advice, training, services and support
> from the Jetty & CometD experts.
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Greg Wilkins  CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users


Re: [jetty-users] Exception in Jetty 12.0.1

2023-09-05 Thread Greg Wilkins via jetty-users
I've done a draft PR to potentially fix this:
https://github.com/eclipse/jetty.project/pull/10479
But we need to actually write a test to confirm the diagnosis first.

On Tue, 5 Sept 2023 at 17:44, Jan Bartel via jetty-users <
jetty-users@eclipse.org> wrote:

> Silvio,
>
>
> This looks like a url with the sessionid encoded in the url, but it is
> incomplete. It looks like the url just contains JSESSIONID, whereas it
> should be JSESSIONID=.
>
> I don't think we changed the way we parse the sessionid from the url since
> at least jetty 10, but I could be wrong, I don't have my computer in front
> of me.
>
> Will look into it.
>
>
> Jan
>
> On Mon, 4 Sept 2023, 22:10 Silvio Bierman via jetty-users, <
> jetty-users@eclipse.org> wrote:
>
>> I do not know exactly which request causes the issue since I have not yet
>> debugged that. There may be a UUID in the parameter list but these have
>> length 36. The issue only occurs in 12.0.1 so I doubt the URL-paramaters
>> are encoded incorrectly. We never use application character data in URL
>> parameters so it is unlikely that any special characters are in there.
>>
>>
>> On 04-09-2023 13:58, Bill Ross via jetty-users wrote:
>>
>> I wonder if this could be a string encoding issue? Can you think of any
>> strings/params that are this long?
>>
>> 1234567890123456789012345678901234
>>
>>
>> 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError:
>> status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out
>> of bounds for length 34,
>> response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1
>> java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for
>> length 34
>> at
>> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
>> at
>> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
>> at
>> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
>> at
>> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
>> at
>> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
>> at
>> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
>> at
>> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
>> at java.base/java.lang.String.checkIndex(String.java:4575)
>> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46)
>> at java.base/java.lang.String.charAt(String.java:1535)
>>
>>
>> ---
>> --
>>
>> Phobrain.com
>>
>>
>> On 2023-09-04 04:45, Silvio Bierman via jetty-users wrote:
>>
>> I get a runtime exception when using Jetty 12.0.1 in embedded mode
>> (http/2). I have to add that i call SessionIdManager.setWorkerName(null) to
>> get rid of the node id in the session ID (which has always worked for
>> previous versions).
>>
>> 2023-09-04 13:39:27.421:WARN :oejs.Response:qtp105374791-42: writeError:
>> status=500, message=java.lang.StringIndexOutOfBoundsException: Index 34 out
>> of bounds for length 34,
>> response=org.eclipse.jetty.ee10.servlet.ServletContextResponse@77c7bf1
>> java.lang.StringIndexOutOfBoundsException: Index 34 out of bounds for
>> length 34
>> at
>> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
>> at
>> java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
>> at
>> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
>> at
>> java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
>> at
>> java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
>> at
>> java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
>> at
>> java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
>> at java.base/java.lang.String.checkIndex(String.java:4575)
>> at java.base/java.lang.StringLatin1.charAt(StringLatin1.java:46)
>> at java.base/java.lang.String.charAt(String.java:1535)
>> at
>> org.eclipse.jetty.session.AbstractSessionManager.resolveRequestedSessionId(AbstractSessionManager.java:1261)
>> at
>> org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:652)
>> at
>> org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:811)
>> at
>> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:177)
>> at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:712)
>> at org.eclipse.jetty.server.Server.handle(Server.java:176)
>> at
>> org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:648)
>> at
>> org.eclipse.jetty.util.thread.Invocable$ReadyTask.run(Invocable.java:105)
>> at
>> org.eclipse.jetty.http2.server.internal.HttpStreamOverHTTP2$1.run(HttpStreamOverHTTP2.java:129)
>> at
>> 

Re: [jetty-users] Jetty 12 return wrong Host header?

2023-08-12 Thread Greg Wilkins via jetty-users
Actually,

I think Uwe's and Silvio's problems are similar but different.

Silvio, you have no forwarded request customizer headers and a real
"demo.jambo.software:8443" as the host header value.  This could be a http2
issue in recreating that header.
Uwe's issue is more about the customizer.

So Silvio, perhaps open a second issue?

cheers

P.S. We expect at least a monthly cadence of 12.0.x releases.



On Sun, 13 Aug 2023 at 08:52, Greg Wilkins  wrote:

> Silvio,
>
> I'll respond more in Uwe's issue.  Please post your details there to help
> the triage.
>
> cheers
>
>
>
> On Sun, 13 Aug 2023 at 05:19, Uwe Schindler via jetty-users <
> jetty-users@eclipse.org> wrote:
>
>> I opened: https://github.com/eclipse/jetty.project/issues/10304
>> Am 12.08.2023 um 19:30 schrieb Uwe Schindler via jetty-users:
>>
>> I have seen the same after upgrading my project to Java 12. The problem
>> is that all Customizers are not able to correctly set the port number.
>>
>> This is a blocker issue, because it makes it impossible to setup this
>> common setup:
>>
>>- NGINX as user facing web server with HTTPS enabled
>>- NGINX forwarding the requests to jetty listen only on localhost
>>with some arbitrary port number (in my case 8081). NGINX sets the 
>> following
>>headers: X-Forwarded-For, X-Forwarded-Proto, original "Host" header as 
>> sent
>>by client (no rewriting)
>>- Jetty with: http_config.addCustomizer(new
>>ForwardedRequestCustomizer());
>>- Jetty 10 works fine it reads the clien't IP address and all other
>>information from X-Forwarded-For, the scheme is read from
>>X-Forwarded-Proto, and host header is coming from "Host" header. It also
>>extracts the port number from the host.
>>- Jetty 12 is setup in same way, it successfully extracts the
>>client's IP address and also it returns secure=true and uses "https://;
>>for javax.servlet.HttServletRequest#getRequestURL(). But it always adds 
>> its
>>own private port number. I also tried to use setForcedHost("xyz:443") to
>>make sure it sees a port number. It still constructs all URLs with port
>>number 8081 where it listens on.
>>
>> I will open a bug report. From my experience the "customize()" method in
>> the RequestCustomizer does everything right also also returns the port
>> number, but the javax.servlet API seems to still use the port number used
>> by the connector's channel.
>>
>> I reverted back to Jetty 10. This won't work here. If you have any
>> suggestion to get the port corrcet, tell me, everything like subclassing
>> and implementing my own cutsomizer did not work. I was not able to debug
>> through everything and figure out where the listener port gets injected
>> again.
>>
>> I can say: With current status Jetty 12 is unuseable with the common
>> proxy setup using ForwardedRequestCustomizer as it tried to always inject
>> its own hidden/private port number instead of the default for the port as
>> negotiated by client/proxy with the Host header.
>>
>> --
>> Uwe schindleruschind...@apache.org
>> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
>> Bremen, Germanyhttps://lucene.apache.org/https://solr.apache.org/
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
> --
> Greg Wilkins  CTO http://webtide.com
>


-- 
Greg Wilkins  CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users


Re: [jetty-users] Jetty 12 return wrong Host header?

2023-08-12 Thread Greg Wilkins via jetty-users
Silvio,

I'll respond more in Uwe's issue.  Please post your details there to help
the triage.

cheers



On Sun, 13 Aug 2023 at 05:19, Uwe Schindler via jetty-users <
jetty-users@eclipse.org> wrote:

> I opened: https://github.com/eclipse/jetty.project/issues/10304
> Am 12.08.2023 um 19:30 schrieb Uwe Schindler via jetty-users:
>
> I have seen the same after upgrading my project to Java 12. The problem is
> that all Customizers are not able to correctly set the port number.
>
> This is a blocker issue, because it makes it impossible to setup this
> common setup:
>
>- NGINX as user facing web server with HTTPS enabled
>- NGINX forwarding the requests to jetty listen only on localhost with
>some arbitrary port number (in my case 8081). NGINX sets the following
>headers: X-Forwarded-For, X-Forwarded-Proto, original "Host" header as sent
>by client (no rewriting)
>- Jetty with: http_config.addCustomizer(new
>ForwardedRequestCustomizer());
>- Jetty 10 works fine it reads the clien't IP address and all other
>information from X-Forwarded-For, the scheme is read from
>X-Forwarded-Proto, and host header is coming from "Host" header. It also
>extracts the port number from the host.
>- Jetty 12 is setup in same way, it successfully extracts the client's
>IP address and also it returns secure=true and uses "https://; for
>javax.servlet.HttServletRequest#getRequestURL(). But it always adds its own
>private port number. I also tried to use setForcedHost("xyz:443") to make
>sure it sees a port number. It still constructs all URLs with port number
>8081 where it listens on.
>
> I will open a bug report. From my experience the "customize()" method in
> the RequestCustomizer does everything right also also returns the port
> number, but the javax.servlet API seems to still use the port number used
> by the connector's channel.
>
> I reverted back to Jetty 10. This won't work here. If you have any
> suggestion to get the port corrcet, tell me, everything like subclassing
> and implementing my own cutsomizer did not work. I was not able to debug
> through everything and figure out where the listener port gets injected
> again.
>
> I can say: With current status Jetty 12 is unuseable with the common proxy
> setup using ForwardedRequestCustomizer as it tried to always inject its own
> hidden/private port number instead of the default for the port as
> negotiated by client/proxy with the Host header.
>
> --
> Uwe schindleruschind...@apache.org
> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
> Bremen, Germanyhttps://lucene.apache.org/https://solr.apache.org/
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>


-- 
Greg Wilkins  CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users


Re: [jetty-users] Jetty 12 return wrong Host header?

2023-08-11 Thread Greg Wilkins via jetty-users
Silvio,

The host header should contain the host and port as used by the client.
Thus if the request goes to the default port and is forward you a different
port, the host header should not have the port in it, or at least only the
default port.

Are you sure the client is using the default port and not going direct you
the server?

Can you give us a bit more info:
 + Uri and headers as sent by the client
 + Uri and headers as received by jetty
 + The actual values you get from the various request methods

Cheers


On Fri, Aug 11, 2023, 21:34 Silvio Bierman via jetty-users <
jetty-users@eclipse.org> wrote:

> Hello all,
>
> I have encountered what I think is a bug in Jetty 12 but I would like to
> check here if that is actually true.
>
> I use port forwarding to forward HTTP requests from port 443 to 8443.
> Requests arrive at the default port without an explicit port number in
> the URL so
>
> request.getRequestURL().toString
>
> does not show a port number. But
>
> request.getHeader("Host")
>
> returns the host name including the port number. This makes it
> impossible to distinguish requests with explicit ports from requests
> without these. Jetty 11 does not show this same behaviour.
>
> Cheers,
>
> Silvio
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users