Correctly shutting down a websocket handler
by Robin Anil
When a client disconnects, I see that onClose is not being fired. The only
way this seems to be firing if client sents a close frame.
Is there any way to detect disconnection and immediately close all the
opened resources.
Robin
Robin Anil | Software Engineer
6 days, 3 hours
Undertow changelog and latest features
by Girish Sharma
Hi all,
I have been (not so frequently) visiting the github repository to find that
new versions of undertow have been released. But when I visit undertow.io
site, there is no information on what's new in the latest version.
Thus, this post.
Is there any changelog or what's new blog for Undertow 1.2, 1.3, 1.4 and/or
2.0?
Regards
--
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
7 years, 7 months
Compiling Undertow
by Erhard Siegl
Hi,
I’m trying to compile Undertow having some problems.
When I use Oracle jdk1.8.0_31, I get compile-errors, with jdk1.8.0_71, last week the test WebSocketClient13TestCase got stuck, with the latest updates I get the test-failure:
Tests in error:
io.undertow.websockets.client.version13.WebSocketClient13TestCase.testMessageViaWssProxy(io.undertow.websockets.client.version13.WebSocketClient13TestCase)
Run 1: PASS
Run 2: WebSocketClient13TestCase.testMessageViaWssProxy » Runtime Buffer Leak io.unde...
in ./target/surefire-reports/io.undertow.websockets.client.version13.WebSocketClient13TestCase-output.txt:
java.nio.channels.ClosedChannelException
at io.undertow.protocols.ssl.SslConduit.read(SslConduit.java:528)
at io.undertow.conduits.IdleTimeoutConduit.read(IdleTimeoutConduit.java:202)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:357)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:38)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:33)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:884)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:865)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1059)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)
java.lang.RuntimeException: java.nio.DirectByteBuffer[pos=0 lim=17408 cap=17408] NO: 178 [NO_CONTEXT]
at io.undertow.testutils.DebuggingSlicePool$DebuggingBuffer.<init>(DebuggingSlicePool.java:67)
at io.undertow.testutils.DebuggingSlicePool.allocate(DebuggingSlicePool.java:38)
at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:654)
at io.undertow.protocols.ssl.SslConduit.read(SslConduit.java:530)
at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
…
But when I execute “mvn install” again, I get no errors.
A colleague uses jdk1.8.0_60 apparently with no problems. Are there known problems with certain JDKs? Anybody tried HotSpot 1.8.0_71 successfully?
Regards
Erhard
7 years, 7 months
Compiling Undertow
by Erhard Siegl
Hi,
I’m trying to compile Undertow having some problems.
When I use Oracle jdk1.8.0_31, I get compile-errors, with jdk1.8.0_71, last week the test WebSocketClient13TestCase got stuck, with the latest updates I get the test-failure:
Tests in error:
io.undertow.websockets.client.version13.WebSocketClient13TestCase.testMessageViaWssProxy(io.undertow.websockets.client.version13.WebSocketClient13TestCase)
Run 1: PASS
Run 2: WebSocketClient13TestCase.testMessageViaWssProxy » Runtime Buffer Leak io.unde...
in ./target/surefire-reports/io.undertow.websockets.client.version13.WebSocketClient13TestCase-output.txt:
java.nio.channels.ClosedChannelException
at io.undertow.protocols.ssl.SslConduit.read(SslConduit.java:528)
at io.undertow.conduits.IdleTimeoutConduit.read(IdleTimeoutConduit.java:202)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127)
at io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:357)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:38)
at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:33)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:884)
at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:865)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1059)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)
java.lang.RuntimeException: java.nio.DirectByteBuffer[pos=0 lim=17408 cap=17408] NO: 178 [NO_CONTEXT]
at io.undertow.testutils.DebuggingSlicePool$DebuggingBuffer.<init>(DebuggingSlicePool.java:67)
at io.undertow.testutils.DebuggingSlicePool.allocate(DebuggingSlicePool.java:38)
at io.undertow.protocols.ssl.SslConduit.doUnwrap(SslConduit.java:654)
at io.undertow.protocols.ssl.SslConduit.read(SslConduit.java:530)
at org.xnio.conduits.AbstractStreamSourceConduit.read(AbstractStreamSourceConduit.java:51)
…
But when I execute “mvn install” again, I get no errors.
A colleague uses jdk1.8.0_60 apparently with no problems. Are there known problems with certain JDKs? Anybody tried HotSpot 1.8.0_71 successfully?
Regards
Erhard
7 years, 7 months
sessionId changes between requests?
by Bill Burke
Does a HttpSession ID change between requests? We are storing the
current HttpSession ID at our IDP after login, then transmitting back to
the app in a background HTTP request, looking up the session and then
invalidating it. This used to work on Wildfly 8 and 9, in 10, looks like
it is not the same http session.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
7 years, 8 months
Reverse-Proxy: Consuming InputStream before delegating to proxy target
by Jaeckle Thomas (INST/ECS1)
Hi.
I have following scenario in which I currently face a problem with Undertow:
I use Undertow as a Reverse-Proxy (via SimpleProxyClientProvider).
I want to enable a Signature-based authentication where the client can sign the HTTP request with its private key and the Reverse-Proxy (implemented with Undertow) can check with the client's public key if it was signed correctly.
I do not only want to include HTTP headers (Host, Date, ..) and Method/Path, but also the request body.
For that I need to consume the HttpServerExchange's InputStream:
if (isHttpMethodWithBody(method))
{
exchange.startBlocking();
final String body = new Scanner(exchange.getInputStream(), "UTF-8").useDelimiter("\\A<file:///\\A>").next();
..
Unfortunately in this scenario, the Exchange's "getRequestChannel()" returns null as "another party already acquired the channel".
I found "Connectors.resetRequestChannel(exchange)";
But just calling this results after the InputStream was consumed results in a "IOException : UT001000: Connection closed".
Is there any way to "consume" the request's payload, but afterwards simply forward to the proxy target?
Any help is really appreciated, Thanks!
--
Thomas Jäckle
7 years, 8 months
New security library for Undertow: undertow-pac4j v1.1
by Jérôme LELEU
Hi,
I'm proud to announce the release of undertow-pac4j v1.1 (based on pac4j
v1.8.5) for Undertow 1.3. It's now a full security library, easy and
powerful, which supports authentication and authorization, but also
application logout and advanced features like CSRF protection.
It supports most authentication mechanisms: OAuth (Facebook, Twitter,
Google, Yahoo...), CAS, HTTP (form, basic auth...), OpenID, SAML, Google
App Engine, OpenID Connect, JWT, LDAP, RDBMS, MongoDB and Stormpath and
authorization checks (role / permission, CSRF token...)
Read the documentation: https://github.com/pac4j/undertow-pac4j
And see the demo: https://github.com/pac4j/undertow-pac4j-demo
Thanks.
Best regards,
Jérôme
7 years, 8 months
Reverse-Proxy: Consuming InputStream before delegating to proxy target
by Jaeckle Thomas (INST/ECS1)
Hi.
I have following scenario in which I currently face a problem with Undertow:
I use Undertow as a Reverse-Proxy (via SimpleProxyClientProvider).
I want to enable a Signature-based authentication where the client can sign the HTTP request with its private key and the Reverse-Proxy (implemented with Undertow) can check with the client's public key if it was signed correctly.
I do not only want to include HTTP headers (Host, Date, ..) and Method/Path, but also the request body.
For that I need to consume the HttpServerExchange's InputStream:
if (isHttpMethodWithBody(method))
{
exchange.startBlocking();
final String body = new Scanner(exchange.getInputStream(), "UTF-8").useDelimiter("\\A").next();
..
Unfortunately in this scenario, the Exchange's "getRequestChannel()" returns null as "another party already acquired the channel".
I found "Connectors.resetRequestChannel(exchange)";
But just calling this results after the InputStream was consumed results in a "IOException : UT001000: Connection closed".
Is there any way to "consume" the request's payload, but afterwards simply forward to the proxy target?
Any help is really appreciated, Thanks!
--
Thomas Jäckle
7 years, 8 months
How to get the remote socket address of a javax.websocket.Session ?
by Salvadè Angelo
Hi all
I'd like to get the remote socket address (the address of the client of the session) of a javax.websocket.Session.
There seems to be no official way in the Java WebSocket API for this.
Is there a solution for this with Undertow ?
BTW, Jetty adds it to javax.websocket.Session.getUserProperties() with the key org.eclipse.jetty.websocket.jsr356.server.JsrCreator.PROP_REMOTE_ADDRESS.
Regards,
Angelo
________________________________
Disclaimer:
Aufgrund der bisherigen E-Mail-Korrespondenz bzw. der getroffenen Absprache, betrachtet sich die Zürcher Kantonalbank als berechtigt, mit Ihnen per E-Mail zu kommunizieren. Die Zürcher Kantonalbank geht davon aus, dass Sie die Risiken von E-Mails kennen und in Kauf nehmen (insbesondere fehlende Vertraulichkeit, Manipulation oder Missbrauch durch Dritte, Fehlleitung, verzögerte Übermittlung oder Bearbeitung, Viren, etc.). Die Zürcher Kantonalbank lehnt jede Haftung für Schäden im Zusammenhang mit der Verwendung von E-Mails ab, sofern die Bank die geschäftsübliche Sorgfalt nicht verletzt hat.
E-Mails werden nur während den üblichen Geschäftszeiten der Bank bearbeitet. Sie können nicht von der sofortigen Kenntnisnahme Ihrer E-Mails ausgehen. E-Mail eignet sich daher nicht für die Übermittlung von Handelsaufträgen und wertverschiebenden oder zeitkritischen Aufträgen (z.B. Zahlungsaufträge).
Sollten Sie dieses E-Mail irrtümlicherweise erhalten haben, bitten wir Sie, das E-Mail an die Zürcher Kantonalbank zurückzusenden und das E-Mail anschliessend mitsamt allen Anhängen von ihrem System zu löschen. Der Gebrauch der im E-Mail enthaltenen Information ist verboten.
Based on previous e-mail correspondence or an arrangement we have reached with you, Zürcher Kantonalbank considers itself to be entitled to communicate with you via e-mail. Zürcher Kantonalbank assumes that you know the risks associated with e-mails and that you accept them (in particular, the lack of confidentiality, manipulation or misuse by third parties, misdirection, delayed transmission or processing, viruses, etc.). Zürcher Kantonalbank accepts no liability whatsoever for damage caused in connection with the use of e-mail, provided that the Bank has not failed to exercise customary due care.
E-mails are processed only during the Bank’s normal business hours. You cannot assume that your e-mails will be read immediately. E-mails are therefore not suitable for sending trading orders and orders that change the value of an account or are time-critical (e.g. payment orders).
If you have received this e-mail in error, please respond to Zürcher Kantonalbank and then delete this e-mail and your response together with all attachments from your system. The use of the information contained in the e-mail is prohibited.
7 years, 8 months
