From arjan.tijms at gmail.com Wed Oct 1 05:45:52 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 1 Oct 2014 11:45:52 +0200 Subject: [undertow-dev] Undertow forwards too early when handling error page, causing many issues Message-ID: Hi, Contrary to other servers (Tomcat, JBoss AS 7/EAP 6, GlassFish and probably all others), Undertow immediately performs a forward when HttpServletResponse#sendError() is invoked instead of waiting until all servlets and filters of the application are finished. In case the error page happens to be a Facelets page, this forward causes the FacesServlet to be invoked once again, basically creating another FacesContext inside the same thread. This overrides the previous FacesContext. After that is released, the "original" FacesContext is never put back. In OmniFaces we created a workaround for this, see https://github.com/omnifaces/omnifaces/commit/b9badb86cb2112fd87485e060db21262de58887c Unfortunately, this OmniFaces workaround isn't bulletproof. In case of an HTTP 400, PrimeFaces loses its RequestContext as well and OmniFaces can't help setting it back. This results in exceptions like the following: java.lang.NullPointerException at org.primefaces.context.PrimeFacesContext.release(PrimeFacesContext.java:26) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665) Although not confirmed, this behaviour from Undertow is the likely cause of a large number of other exceptions as well. Kind regards, Arjan Tijms From sdouglas at redhat.com Wed Oct 1 18:36:36 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 02 Oct 2014 08:36:36 +1000 Subject: [undertow-dev] Undertow forwards too early when handling error page, causing many issues In-Reply-To: References: Message-ID: <542C81F4.2070908@redhat.com> I can't see anything in the servlet spec that indicates that the behaviour of Undertow is incorrect. Can you file a JIRA in the Undertow JIRA, and also in the Servlet Spec JIRA asking for a clarification in the spec? If this is how all other containers handle the sendRedirect then I will change Undertow to match, however it would be better if this was explicitly specified in the spec. Stuart arjan tijms wrote: > Hi, > > Contrary to other servers (Tomcat, JBoss AS 7/EAP 6, GlassFish and > probably all others), Undertow immediately performs a forward when > HttpServletResponse#sendError() is invoked instead of waiting until > all servlets and filters of the application are finished. > > In case the error page happens to be a Facelets page, this forward > causes the FacesServlet to be invoked once again, basically creating > another FacesContext inside the same thread. This overrides the > previous FacesContext. After that is released, the "original" > FacesContext is never put back. > > In OmniFaces we created a workaround for this, see > https://github.com/omnifaces/omnifaces/commit/b9badb86cb2112fd87485e060db21262de58887c > > > > Unfortunately, this OmniFaces workaround isn't bulletproof. In case of > an HTTP 400, PrimeFaces loses its RequestContext as well and OmniFaces > can't help setting it back. > > This results in exceptions like the following: > > java.lang.NullPointerException > at > org.primefaces.context.PrimeFacesContext.release(PrimeFacesContext.java:26) > > > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665) > > Although not confirmed, this behaviour from Undertow is the likely > cause of a large number of other exceptions as well. > > Kind regards, > Arjan Tijms > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From arjan.tijms at gmail.com Thu Oct 2 10:01:49 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 2 Oct 2014 16:01:49 +0200 Subject: [undertow-dev] Undertow forwards too early when handling error page, causing many issues In-Reply-To: <542C81F4.2070908@redhat.com> References: <542C81F4.2070908@redhat.com> Message-ID: Hi, On Thu, Oct 2, 2014 at 12:36 AM, Stuart Douglas wrote: > I can't see anything in the servlet spec that indicates that the behaviour > of Undertow is incorrect. > > Can you file a JIRA in the Undertow JIRA, and also in the Servlet Spec JIRA > asking for a clarification in the spec? There seems to be something in the Servlet spec that indicates it should be done last. We created a JIRA issue for this here: https://issues.jboss.org/browse/UNDERTOW-322 Thanks in advance for looking into this. Kind regards, Arjan Tijms From marc.boorshtein at tremolosecurity.com Wed Oct 15 14:00:26 2014 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Wed, 15 Oct 2014 14:00:26 -0400 Subject: [undertow-dev] How to do custom authentication? Message-ID: Undertow team, I'm trying to integrate our integration with JBoss into Wildfy 8.x. Its a reverse proxy that generates a token in a header that is then decoded and the context is set. It works in JBoss 7.x using a combination of a Valve and a JAAS LoginModule but am struggling to figure out what the replacement of the Valve would be. Doing some googling I found http://undertow.io/documentation/core/security.html but it doesn't point out how to configure this without writing custom code to add mechanism to the chain. I found a stacktrace article about setting up a servlet extension that creates the mechanism, but I don't feel like thats the *best* solution. When I did the JBoss 7 integration I used PicketLink's SAML integration as an example but it looks like it isn't yet working for Wildfly 8.x and won't work until 9? I know this isn't a JBoss list but my post on the JBoss forums isn't going anywhere so I thought I'd ask here. If someone could point me to an example (I usually start with an example of authenticating based on a username in a header) I'd really appreciate it. Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141015/196e6540/attachment.html From arjan.tijms at gmail.com Wed Oct 15 15:42:20 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Wed, 15 Oct 2014 21:42:20 +0200 Subject: [undertow-dev] How to do custom authentication? In-Reply-To: References: Message-ID: Hi Marc, >I know this isn't a JBoss list but my post on the JBoss forums isn't going anywhere so I thought I'd ask here. If someone could point me to an example (I usually start with an example of authenticating based on a username in a header) I'd really appreciate it. If you're looking for custom authentication then there's a standardized SPI/API for that: JASPIC. It's supported relatively well by WildFly 8.x. There's an example of building a simple module here: http://www.trajano.net/2014/06/creating-a-simple-jaspic-auth-module and somewhat more complex one by the same author here: http://www.trajano.net/2014/07/oauth-2-0-jaspic-implementation I've posted about the background of JASPIC here: http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html and created several tests that demonstrate a variety of behaviors here: https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic (see also https://github.com/javaee-samples/javaee7-samples/issues/243) Another example can be found here: https://github.com/arjantijms/two-factor-sam This should hopefully be enough to start with an example where you authenticate based on a header. Kind regards, Arjan On Wed, Oct 15, 2014 at 8:00 PM, Marc Boorshtein wrote: > Undertow team, > > I'm trying to integrate our integration with JBoss into Wildfy 8.x. Its a > reverse proxy that generates a token in a header that is then decoded and > the context is set. It works in JBoss 7.x using a combination of a Valve > and a JAAS LoginModule but am struggling to figure out what the replacement > of the Valve would be. > > Doing some googling I found > http://undertow.io/documentation/core/security.html but it doesn't point out > how to configure this without writing custom code to add mechanism to the > chain. I found a stacktrace article about setting up a servlet extension > that creates the mechanism, but I don't feel like thats the *best* solution. > When I did the JBoss 7 integration I used PicketLink's SAML integration as > an example but it looks like it isn't yet working for Wildfly 8.x and won't > work until 9? > > I know this isn't a JBoss list but my post on the JBoss forums isn't going > anywhere so I thought I'd ask here. If someone could point me to an example > (I usually start with an example of authenticating based on a username in a > header) I'd really appreciate it. > > Thanks > > > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sdouglas at redhat.com Wed Oct 15 18:47:13 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 15 Oct 2014 18:47:13 -0400 (EDT) Subject: [undertow-dev] How to do custom authentication? In-Reply-To: References: Message-ID: <1915396760.5845611.1413413233680.JavaMail.zimbra@redhat.com> The equivalent of a valve is a HttpHandler, you can wire them up programatically via jboss-web.xml, something like: org.jboss.as.test.integration.web.handlers.SetHeaderHandler name MyHeader value MyValue Stuart ----- Original Message ----- > From: "Marc Boorshtein" > To: "undertow-dev at lists jboss. org" > Sent: Thursday, 16 October, 2014 5:00:26 AM > Subject: [undertow-dev] How to do custom authentication? > > Undertow team, > > I'm trying to integrate our integration with JBoss into Wildfy 8.x. Its a > reverse proxy that generates a token in a header that is then decoded and > the context is set. It works in JBoss 7.x using a combination of a Valve and > a JAAS LoginModule but am struggling to figure out what the replacement of > the Valve would be. > > Doing some googling I found > http://undertow.io/documentation/core/security.html but it doesn't point out > how to configure this without writing custom code to add mechanism to the > chain. I found a stacktrace article about setting up a servlet extension > that creates the mechanism, but I don't feel like thats the *best* solution. > When I did the JBoss 7 integration I used PicketLink's SAML integration as > an example but it looks like it isn't yet working for Wildfly 8.x and won't > work until 9? > > I know this isn't a JBoss list but my post on the JBoss forums isn't going > anywhere so I thought I'd ask here. If someone could point me to an example > (I usually start with an example of authenticating based on a username in a > header) I'd really appreciate it. > > Thanks > > > Marc Boorshtein > CTO Tremolo Security > marc.boorshtein at tremolosecurity.com > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From tomaz.cerar at gmail.com Thu Oct 16 07:16:43 2014 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 16 Oct 2014 13:16:43 +0200 Subject: [undertow-dev] How to do custom authentication? In-Reply-To: <1915396760.5845611.1413413233680.JavaMail.zimbra@redhat.com> References: <1915396760.5845611.1413413233680.JavaMail.zimbra@redhat.com> Message-ID: On Thu, Oct 16, 2014 at 12:47 AM, Stuart Douglas wrote: > The equivalent of a valve is a HttpHandler, you can wire them up > programatically via jboss-web.xml, something like: Or since upcoming wildfly 8.2 and 9 it is also possible as global configuration in undertow subsystem .... .... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141016/82a71857/attachment-0001.html From jeffw at wherethebitsroam.com Thu Oct 16 07:54:11 2014 From: jeffw at wherethebitsroam.com (Jeff Williams) Date: Thu, 16 Oct 2014 13:54:11 +0200 Subject: [undertow-dev] Response Wrappers Message-ID: Hi, I am testing an undertow server for doing on-the-fly encryption (AES CTR) of responses from a reverse proxy. I have currently implemented this by implementing a StreamSinkConduit and adding this as a wrapper using exchange.addResponseWrapper. I have a few questions: 1) The StreamSinkConduit interface is pretty big and I'm not sure I've implemented all of it correctly. Is there an easier way? At the end of the day, I'm really only doing anything interesting in the write method. I've been looking at the DeflatingStreamSinkConduit, but that is a fair bit more complex than I need. Is there any documentation about when the different methods are called? 2) To initialise the cipher, I need some information about the response, i.e. the offset from the start for Range requests. Currently I intialise the cipher the first time it is requested (in write) using the response code and response headers. Is this a reasonable approach? 3) Can you point me towards some information on logging configuration? Thanks! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141016/db3ad124/attachment.html From marc.boorshtein at tremolosecurity.com Thu Oct 16 08:04:06 2014 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Thu, 16 Oct 2014 08:04:06 -0400 Subject: [undertow-dev] How to do custom authentication? In-Reply-To: References: <1915396760.5845611.1413413233680.JavaMail.zimbra@redhat.com> Message-ID: Thanks everyone. So would the beat approach be to use a http and let to invoke a jaspic class or to invoke an undertow authentication class? Thanks Marc On Oct 16, 2014 7:16 AM, "Toma? Cerar" wrote: > > On Thu, Oct 16, 2014 at 12:47 AM, Stuart Douglas > wrote: > >> The equivalent of a valve is a HttpHandler, you can wire them up >> programatically via jboss-web.xml, something like: > > > > Or since upcoming wildfly 8.2 and 9 it is also possible as global > configuration in undertow subsystem > > default-web-module="something.war"> > > > .... > > .... > > > class-name="io.undertow.server.handlers.HttpTraceHandler" > module="io.undertow.core" /> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141016/5f347299/attachment.html From arjan.tijms at gmail.com Thu Oct 16 08:36:56 2014 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 16 Oct 2014 14:36:56 +0200 Subject: [undertow-dev] How to do custom authentication? In-Reply-To: References: <1915396760.5845611.1413413233680.JavaMail.zimbra@redhat.com> Message-ID: Hi, On Thu, Oct 16, 2014 at 2:04 PM, Marc Boorshtein wrote: > Thanks everyone. So would the beat approach be to use a http and let to > invoke a jaspic class or to invoke an undertow authentication class? I'd personally say JASPIC. The advantage it that it's a standardized SPI/API, which means it very likely won't suddenly change in a major incompatible way between JBoss versions. Also note that the HttpHandler (and before that a Valve) is not an authentication class perse, but a general mechanism. Using an HttpHandler though gives you access to some very low-level Undertow mechanics, that you won't be able to access from higher level and more general JASPIC authentication modules. As a middle ground; I've seen a couple of JASPIC authentication modules that casted the HTTPServletRequest to a JBoss specific one and then did some things with it that the plain Servlet API doesn't allow, and ones that were combined with a Valve (JBoss EAP 6 and before). JBoss themselves have published 3 JASPIC authentication modules where they use this hybrid approach, see e.g. http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.2.0.Final/org/jboss/as/web/security/jaspi/modules/HTTPBasicServerAuthModule.java?av=f But I'd suggest starting with the plain JASPIC/Servlet APIs first and only going JBoss specific when really needed. Regards, Arjan > > Thanks > Marc > > On Oct 16, 2014 7:16 AM, "Toma? Cerar" wrote: >> >> >> On Thu, Oct 16, 2014 at 12:47 AM, Stuart Douglas >> wrote: >>> >>> The equivalent of a valve is a HttpHandler, you can wire them up >>> programatically via jboss-web.xml, something like: >> >> >> >> Or since upcoming wildfly 8.2 and 9 it is also possible as global >> configuration in undertow subsystem >> >> > default-web-module="something.war"> >> >> >> .... >> >> .... >> >> >> > class-name="io.undertow.server.handlers.HttpTraceHandler" >> module="io.undertow.core" /> >> >> >> > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From flushdia at gmail.com Mon Oct 20 16:20:54 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Mon, 20 Oct 2014 23:20:54 +0300 Subject: [undertow-dev] Handling termination of WebSocket connection Message-ID: Let's imagine user closed browser tab and thus terminated WebSocket connection. Is there any way to run a callback method on the server-side to handle this case? The requirement is to perform necessary cleanup actions when connection is closed, regardless of the type of disconnect (normal, forced termination, etc.). (Ideally using lower level API, and not JSR 356) -- Vladimir Tsukur Software Architect, Design Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141020/a8378b77/attachment.html From sdouglas at redhat.com Mon Oct 20 19:08:54 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Mon, 20 Oct 2014 19:08:54 -0400 (EDT) Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: References: Message-ID: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> WebsocketChannel.addCloseTask() should do what you are after (this is actually provided by the base AbstractFramedChannel class). Stuart ----- Original Message ----- > From: "Vladimir Tsukur" > To: undertow-dev at lists.jboss.org > Sent: Tuesday, 21 October, 2014 7:20:54 AM > Subject: [undertow-dev] Handling termination of WebSocket connection > > Let's imagine user closed browser tab and thus terminated WebSocket > connection. Is there any way to run a callback method on the server-side to > handle this case? > > The requirement is to perform necessary cleanup actions when connection is > closed, regardless of the type of disconnect (normal, forced termination, > etc.). > > (Ideally using lower level API, and not JSR 356) > > -- > Vladimir Tsukur > Software Architect, Design Engineer > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From flushdia at gmail.com Tue Oct 21 09:10:49 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Tue, 21 Oct 2014 16:10:49 +0300 Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> References: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> Message-ID: Thanks Stuart, Did not see this method in 1.0.x since it was added at a later release - tried with latest version and it works well. However, I figured out that connection termination works well iif receive setter is set: WebSocketChannel channel = ...; channel.getReceiveSetter().set(new AbstractReceiveListener() {}); channel.addCloseTask(new ChannelListener() { @Override public void handleEvent(WebSocketChannel channel) { ... } }); If receive setter is not set, then close task will not be called. In my case there was no intent to receive messages from the client and just push them from the server. Receive setter was not set => connection was not closed. It seems obligatory to set receive setter all the time to make the thing work. Is it intended? While it is not a big deal really, I would imagine that Undertow should handle connection termination without explicit receive setter call made by the API client. On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas wrote: > WebsocketChannel.addCloseTask() should do what you are after (this is > actually provided by the base AbstractFramedChannel class). > > Stuart > > ----- Original Message ----- > > From: "Vladimir Tsukur" > > To: undertow-dev at lists.jboss.org > > Sent: Tuesday, 21 October, 2014 7:20:54 AM > > Subject: [undertow-dev] Handling termination of WebSocket connection > > > > Let's imagine user closed browser tab and thus terminated WebSocket > > connection. Is there any way to run a callback method on the server-side > to > > handle this case? > > > > The requirement is to perform necessary cleanup actions when connection > is > > closed, regardless of the type of disconnect (normal, forced termination, > > etc.). > > > > (Ideally using lower level API, and not JSR 356) > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- Vladimir Tsukur Software Architect, Design Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141021/f910508b/attachment.html From flushdia at gmail.com Tue Oct 21 11:07:10 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Tue, 21 Oct 2014 18:07:10 +0300 Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: References: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> Message-ID: One more observation - in case network connection is completely lost in between client and server, "close" notifiers are not invoked at all (tried by shutting down network connection on the client machine keeping browser tab opened). In this case there is no opportunity for a client to send a close frame to the server. Is it a bug then? Using Undertow 1.2.0.Beta1 On Tue, Oct 21, 2014 at 4:10 PM, Vladimir Tsukur wrote: > Thanks Stuart, > > Did not see this method in 1.0.x since it was added at a later release - > tried with latest version and it works well. > > However, I figured out that connection termination works well iif receive > setter is set: > > WebSocketChannel channel = ...; > channel.getReceiveSetter().set(new AbstractReceiveListener() {}); > channel.addCloseTask(new ChannelListener() { > @Override > public void handleEvent(WebSocketChannel channel) { > ... > } > }); > > If receive setter is not set, then close task will not be called. In my > case there was no intent to receive messages from the client and just push > them from the server. Receive setter was not set => connection was not > closed. > > It seems obligatory to set receive setter all the time to make the thing > work. Is it intended? While it is not a big deal really, I would imagine > that Undertow should handle connection termination without explicit receive > setter call made by the API client. > > > On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas > wrote: > >> WebsocketChannel.addCloseTask() should do what you are after (this is >> actually provided by the base AbstractFramedChannel class). >> >> Stuart >> >> ----- Original Message ----- >> > From: "Vladimir Tsukur" >> > To: undertow-dev at lists.jboss.org >> > Sent: Tuesday, 21 October, 2014 7:20:54 AM >> > Subject: [undertow-dev] Handling termination of WebSocket connection >> > >> > Let's imagine user closed browser tab and thus terminated WebSocket >> > connection. Is there any way to run a callback method on the >> server-side to >> > handle this case? >> > >> > The requirement is to perform necessary cleanup actions when connection >> is >> > closed, regardless of the type of disconnect (normal, forced >> termination, >> > etc.). >> > >> > (Ideally using lower level API, and not JSR 356) >> > >> > -- >> > Vladimir Tsukur >> > Software Architect, Design Engineer >> > >> > _______________________________________________ >> > undertow-dev mailing list >> > undertow-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/undertow-dev >> > > > > -- > Vladimir Tsukur > Software Architect, Design Engineer > -- Vladimir Tsukur Software Architect, Design Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141021/3ce9c344/attachment-0001.html From cody.lerum at gmail.com Tue Oct 21 14:10:44 2014 From: cody.lerum at gmail.com (Cody Lerum) Date: Tue, 21 Oct 2014 12:10:44 -0600 Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: References: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> Message-ID: This also happens in Wildfly 8.1 (Undertow 1.0.15) and can happen if the browser doesn't close the connection when the tab is closed. Chrome and IE both do this. https://issues.jboss.org/browse/WFLY-3704 Supposedly fixed in later versions but I haven't upgraded yet to verify. On Tue, Oct 21, 2014 at 9:07 AM, Vladimir Tsukur wrote: > One more observation - in case network connection is completely lost in > between client and server, "close" notifiers are not invoked at all (tried > by shutting down network connection on the client machine keeping browser > tab opened). In this case there is no opportunity for a client to send a > close frame to the server. Is it a bug then? Using Undertow 1.2.0.Beta1 > > On Tue, Oct 21, 2014 at 4:10 PM, Vladimir Tsukur wrote: >> >> Thanks Stuart, >> >> Did not see this method in 1.0.x since it was added at a later release - >> tried with latest version and it works well. >> >> However, I figured out that connection termination works well iif receive >> setter is set: >> >> WebSocketChannel channel = ...; >> channel.getReceiveSetter().set(new AbstractReceiveListener() {}); >> channel.addCloseTask(new ChannelListener() { >> @Override >> public void handleEvent(WebSocketChannel channel) { >> ... >> } >> }); >> >> If receive setter is not set, then close task will not be called. In my >> case there was no intent to receive messages from the client and just push >> them from the server. Receive setter was not set => connection was not >> closed. >> >> It seems obligatory to set receive setter all the time to make the thing >> work. Is it intended? While it is not a big deal really, I would imagine >> that Undertow should handle connection termination without explicit receive >> setter call made by the API client. >> >> >> On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas >> wrote: >>> >>> WebsocketChannel.addCloseTask() should do what you are after (this is >>> actually provided by the base AbstractFramedChannel class). >>> >>> Stuart >>> >>> ----- Original Message ----- >>> > From: "Vladimir Tsukur" >>> > To: undertow-dev at lists.jboss.org >>> > Sent: Tuesday, 21 October, 2014 7:20:54 AM >>> > Subject: [undertow-dev] Handling termination of WebSocket connection >>> > >>> > Let's imagine user closed browser tab and thus terminated WebSocket >>> > connection. Is there any way to run a callback method on the >>> > server-side to >>> > handle this case? >>> > >>> > The requirement is to perform necessary cleanup actions when connection >>> > is >>> > closed, regardless of the type of disconnect (normal, forced >>> > termination, >>> > etc.). >>> > >>> > (Ideally using lower level API, and not JSR 356) >>> > >>> > -- >>> > Vladimir Tsukur >>> > Software Architect, Design Engineer >>> > >>> > _______________________________________________ >>> > undertow-dev mailing list >>> > undertow-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/undertow-dev >> >> >> >> >> -- >> Vladimir Tsukur >> Software Architect, Design Engineer > > > > > -- > Vladimir Tsukur > Software Architect, Design Engineer > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From flushdia at gmail.com Tue Oct 21 15:02:49 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Tue, 21 Oct 2014 22:02:49 +0300 Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: References: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> Message-ID: I am trying with Undertow 1.2.0.Beta1 which is available in Maven Central and physical connection termination does not lead to calling "close" listeners. On Tue, Oct 21, 2014 at 9:10 PM, Cody Lerum wrote: > This also happens in Wildfly 8.1 (Undertow 1.0.15) and can happen if > the browser doesn't close the connection when the tab is closed. > Chrome and IE both do this. > > https://issues.jboss.org/browse/WFLY-3704 > > Supposedly fixed in later versions but I haven't upgraded yet to verify. > > On Tue, Oct 21, 2014 at 9:07 AM, Vladimir Tsukur > wrote: > > One more observation - in case network connection is completely lost in > > between client and server, "close" notifiers are not invoked at all > (tried > > by shutting down network connection on the client machine keeping browser > > tab opened). In this case there is no opportunity for a client to send a > > close frame to the server. Is it a bug then? Using Undertow 1.2.0.Beta1 > > > > On Tue, Oct 21, 2014 at 4:10 PM, Vladimir Tsukur > wrote: > >> > >> Thanks Stuart, > >> > >> Did not see this method in 1.0.x since it was added at a later release - > >> tried with latest version and it works well. > >> > >> However, I figured out that connection termination works well iif > receive > >> setter is set: > >> > >> WebSocketChannel channel = ...; > >> channel.getReceiveSetter().set(new AbstractReceiveListener() {}); > >> channel.addCloseTask(new ChannelListener() { > >> @Override > >> public void handleEvent(WebSocketChannel channel) { > >> ... > >> } > >> }); > >> > >> If receive setter is not set, then close task will not be called. In my > >> case there was no intent to receive messages from the client and just > push > >> them from the server. Receive setter was not set => connection was not > >> closed. > >> > >> It seems obligatory to set receive setter all the time to make the thing > >> work. Is it intended? While it is not a big deal really, I would imagine > >> that Undertow should handle connection termination without explicit > receive > >> setter call made by the API client. > >> > >> > >> On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas > >> wrote: > >>> > >>> WebsocketChannel.addCloseTask() should do what you are after (this is > >>> actually provided by the base AbstractFramedChannel class). > >>> > >>> Stuart > >>> > >>> ----- Original Message ----- > >>> > From: "Vladimir Tsukur" > >>> > To: undertow-dev at lists.jboss.org > >>> > Sent: Tuesday, 21 October, 2014 7:20:54 AM > >>> > Subject: [undertow-dev] Handling termination of WebSocket connection > >>> > > >>> > Let's imagine user closed browser tab and thus terminated WebSocket > >>> > connection. Is there any way to run a callback method on the > >>> > server-side to > >>> > handle this case? > >>> > > >>> > The requirement is to perform necessary cleanup actions when > connection > >>> > is > >>> > closed, regardless of the type of disconnect (normal, forced > >>> > termination, > >>> > etc.). > >>> > > >>> > (Ideally using lower level API, and not JSR 356) > >>> > > >>> > -- > >>> > Vladimir Tsukur > >>> > Software Architect, Design Engineer > >>> > > >>> > _______________________________________________ > >>> > undertow-dev mailing list > >>> > undertow-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/undertow-dev > >> > >> > >> > >> > >> -- > >> Vladimir Tsukur > >> Software Architect, Design Engineer > > > > > > > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer > > > > _______________________________________________ > > undertow-dev mailing list > > undertow-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/undertow-dev > -- Vladimir Tsukur Software Architect, Design Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141021/e41ae331/attachment.html From sdouglas at redhat.com Tue Oct 21 16:29:53 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 21 Oct 2014 16:29:53 -0400 (EDT) Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: References: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> Message-ID: <1544007494.9515977.1413923393893.JavaMail.zimbra@redhat.com> So what you are probably seeing is that without receives resumed Undertow does not get notification of the underlying connection failure (i.e. it does not receive the close message or does not see read() returning -1). Unfortunately I am not sure if there is much we can do here. I guess we could just read anyway and discard all the messages, but that seems silly. Stuart ----- Original Message ----- > From: "Vladimir Tsukur" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 22 October, 2014 12:10:49 AM > Subject: Re: [undertow-dev] Handling termination of WebSocket connection > > Thanks Stuart, > > Did not see this method in 1.0.x since it was added at a later release - > tried with latest version and it works well. > > However, I figured out that connection termination works well iif receive > setter is set: > > WebSocketChannel channel = ...; > channel.getReceiveSetter().set(new AbstractReceiveListener() {}); > channel.addCloseTask(new ChannelListener() { > @Override > public void handleEvent(WebSocketChannel channel) { > ... > } > }); > > If receive setter is not set, then close task will not be called. In my > case there was no intent to receive messages from the client and just push > them from the server. Receive setter was not set => connection was not > closed. > > It seems obligatory to set receive setter all the time to make the thing > work. Is it intended? While it is not a big deal really, I would imagine > that Undertow should handle connection termination without explicit receive > setter call made by the API client. > > > On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas wrote: > > > WebsocketChannel.addCloseTask() should do what you are after (this is > > actually provided by the base AbstractFramedChannel class). > > > > Stuart > > > > ----- Original Message ----- > > > From: "Vladimir Tsukur" > > > To: undertow-dev at lists.jboss.org > > > Sent: Tuesday, 21 October, 2014 7:20:54 AM > > > Subject: [undertow-dev] Handling termination of WebSocket connection > > > > > > Let's imagine user closed browser tab and thus terminated WebSocket > > > connection. Is there any way to run a callback method on the server-side > > to > > > handle this case? > > > > > > The requirement is to perform necessary cleanup actions when connection > > is > > > closed, regardless of the type of disconnect (normal, forced termination, > > > etc.). > > > > > > (Ideally using lower level API, and not JSR 356) > > > > > > -- > > > Vladimir Tsukur > > > Software Architect, Design Engineer > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > -- > Vladimir Tsukur > Software Architect, Design Engineer > From sdouglas at redhat.com Tue Oct 21 16:32:30 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Tue, 21 Oct 2014 16:32:30 -0400 (EDT) Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: References: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> Message-ID: <1258338499.9517227.1413923550132.JavaMail.zimbra@redhat.com> How long did you wait? the close listener should still be torn down, but it may take a while for Undertow to be aware of the underlying network failure. If you try and send a ping message intermittently that will force the issue, as sending will fail, which will result in the connection being town down. Another option is to set an idle timeout. Stuart ----- Original Message ----- > From: "Vladimir Tsukur" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Wednesday, 22 October, 2014 2:07:10 AM > Subject: Re: [undertow-dev] Handling termination of WebSocket connection > > One more observation - in case network connection is completely lost in > between client and server, "close" notifiers are not invoked at all (tried > by shutting down network connection on the client machine keeping browser > tab opened). In this case there is no opportunity for a client to send a > close frame to the server. Is it a bug then? Using Undertow 1.2.0.Beta1 > > On Tue, Oct 21, 2014 at 4:10 PM, Vladimir Tsukur wrote: > > > Thanks Stuart, > > > > Did not see this method in 1.0.x since it was added at a later release - > > tried with latest version and it works well. > > > > However, I figured out that connection termination works well iif receive > > setter is set: > > > > WebSocketChannel channel = ...; > > channel.getReceiveSetter().set(new AbstractReceiveListener() {}); > > channel.addCloseTask(new ChannelListener() { > > @Override > > public void handleEvent(WebSocketChannel channel) { > > ... > > } > > }); > > > > If receive setter is not set, then close task will not be called. In my > > case there was no intent to receive messages from the client and just push > > them from the server. Receive setter was not set => connection was not > > closed. > > > > It seems obligatory to set receive setter all the time to make the thing > > work. Is it intended? While it is not a big deal really, I would imagine > > that Undertow should handle connection termination without explicit receive > > setter call made by the API client. > > > > > > On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas > > wrote: > > > >> WebsocketChannel.addCloseTask() should do what you are after (this is > >> actually provided by the base AbstractFramedChannel class). > >> > >> Stuart > >> > >> ----- Original Message ----- > >> > From: "Vladimir Tsukur" > >> > To: undertow-dev at lists.jboss.org > >> > Sent: Tuesday, 21 October, 2014 7:20:54 AM > >> > Subject: [undertow-dev] Handling termination of WebSocket connection > >> > > >> > Let's imagine user closed browser tab and thus terminated WebSocket > >> > connection. Is there any way to run a callback method on the > >> server-side to > >> > handle this case? > >> > > >> > The requirement is to perform necessary cleanup actions when connection > >> is > >> > closed, regardless of the type of disconnect (normal, forced > >> termination, > >> > etc.). > >> > > >> > (Ideally using lower level API, and not JSR 356) > >> > > >> > -- > >> > Vladimir Tsukur > >> > Software Architect, Design Engineer > >> > > >> > _______________________________________________ > >> > undertow-dev mailing list > >> > undertow-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/undertow-dev > >> > > > > > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer > > > > > > -- > Vladimir Tsukur > Software Architect, Design Engineer > From flushdia at gmail.com Tue Oct 21 17:55:47 2014 From: flushdia at gmail.com (Vladimir Tsukur) Date: Wed, 22 Oct 2014 00:55:47 +0300 Subject: [undertow-dev] Handling termination of WebSocket connection In-Reply-To: <1258338499.9517227.1413923550132.JavaMail.zimbra@redhat.com> References: <1204984673.8785968.1413846534548.JavaMail.zimbra@redhat.com> <1258338499.9517227.1413923550132.JavaMail.zimbra@redhat.com> Message-ID: > > How long did you wait? the close listener should still be torn down, but > it may take a while for Undertow to be aware of the underlying network > failure. I did not wait long but I guess it was more than a couple of minutes. What is the anticipated timeout value that are referring to? AFAIU problem boils down to the need to write to a socket to actually find out if it s still there or was [abruptly] disconnected. Using ping message in a ping / pong flow seems to be a solution in this case. On Tue, Oct 21, 2014 at 11:32 PM, Stuart Douglas wrote: > How long did you wait? the close listener should still be torn down, but > it may take a while for Undertow to be aware of the underlying network > failure. If you try and send a ping message intermittently that will force > the issue, as sending will fail, which will result in the connection being > town down. > > Another option is to set an idle timeout. > > Stuart > > ----- Original Message ----- > > From: "Vladimir Tsukur" > > To: "Stuart Douglas" > > Cc: undertow-dev at lists.jboss.org > > Sent: Wednesday, 22 October, 2014 2:07:10 AM > > Subject: Re: [undertow-dev] Handling termination of WebSocket connection > > > > One more observation - in case network connection is completely lost in > > between client and server, "close" notifiers are not invoked at all > (tried > > by shutting down network connection on the client machine keeping browser > > tab opened). In this case there is no opportunity for a client to send a > > close frame to the server. Is it a bug then? Using Undertow 1.2.0.Beta1 > > > > On Tue, Oct 21, 2014 at 4:10 PM, Vladimir Tsukur > wrote: > > > > > Thanks Stuart, > > > > > > Did not see this method in 1.0.x since it was added at a later release > - > > > tried with latest version and it works well. > > > > > > However, I figured out that connection termination works well iif > receive > > > setter is set: > > > > > > WebSocketChannel channel = ...; > > > channel.getReceiveSetter().set(new AbstractReceiveListener() {}); > > > channel.addCloseTask(new ChannelListener() { > > > @Override > > > public void handleEvent(WebSocketChannel channel) { > > > ... > > > } > > > }); > > > > > > If receive setter is not set, then close task will not be called. In my > > > case there was no intent to receive messages from the client and just > push > > > them from the server. Receive setter was not set => connection was not > > > closed. > > > > > > It seems obligatory to set receive setter all the time to make the > thing > > > work. Is it intended? While it is not a big deal really, I would > imagine > > > that Undertow should handle connection termination without explicit > receive > > > setter call made by the API client. > > > > > > > > > On Tue, Oct 21, 2014 at 2:08 AM, Stuart Douglas > > > wrote: > > > > > >> WebsocketChannel.addCloseTask() should do what you are after (this is > > >> actually provided by the base AbstractFramedChannel class). > > >> > > >> Stuart > > >> > > >> ----- Original Message ----- > > >> > From: "Vladimir Tsukur" > > >> > To: undertow-dev at lists.jboss.org > > >> > Sent: Tuesday, 21 October, 2014 7:20:54 AM > > >> > Subject: [undertow-dev] Handling termination of WebSocket connection > > >> > > > >> > Let's imagine user closed browser tab and thus terminated WebSocket > > >> > connection. Is there any way to run a callback method on the > > >> server-side to > > >> > handle this case? > > >> > > > >> > The requirement is to perform necessary cleanup actions when > connection > > >> is > > >> > closed, regardless of the type of disconnect (normal, forced > > >> termination, > > >> > etc.). > > >> > > > >> > (Ideally using lower level API, and not JSR 356) > > >> > > > >> > -- > > >> > Vladimir Tsukur > > >> > Software Architect, Design Engineer > > >> > > > >> > _______________________________________________ > > >> > undertow-dev mailing list > > >> > undertow-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/undertow-dev > > >> > > > > > > > > > > > > -- > > > Vladimir Tsukur > > > Software Architect, Design Engineer > > > > > > > > > > > -- > > Vladimir Tsukur > > Software Architect, Design Engineer > > > -- Vladimir Tsukur Software Architect, Design Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141022/395206c6/attachment-0001.html From michaelremond at gmail.com Wed Oct 29 05:28:53 2014 From: michaelremond at gmail.com (=?UTF-8?Q?Micha=C3=ABl_REMOND?=) Date: Wed, 29 Oct 2014 10:28:53 +0100 Subject: [undertow-dev] CAS / OAuth / OpenID / HTTP / SAML client protocol support? In-Reply-To: References: <5372179B.8080006@redhat.com> Message-ID: Hello, I make a follow-up on this thread as I received no feedback on my pac4j binding proposal. Are you interested in this authentication library? Can we improve its design? Thank you for your help Regards, Micha?l 2014-05-27 20:02 GMT+02:00 Micha?l REMOND : > Hello dear Community, > > I made a first draft of what could be a pac4j binding for Undertow. You > can find our standard demo application here > https://github.com/pac4j/undertow-pac4j-demo. You can test several > different authentication providers (facebook, twitter, form, CAS, SAML...). > > I'd like to share some implementation details with you: > - I implemented a new AuthenticationMechanism delegating the > authentication to a pac4j client; so this mechanism is rather "generic" in > regards to what you got in undertow (one for basic auth, one for form...) > - pac4j needs a session mechanism so I used the Undertow SessionManager > to store some attributes but also the User Profile once the user is > successfully authenticated > - pac4j also needs a callback url to finish the authentication process so > I developped a dedicated handler > - finally I used the EagerFormParsingHandler to grab the required POSTed > data > > To conclude I have to say I really appreciated the maturity of the > framework because it was pretty straightforward to play with all the > concepts and the ability to change from the IO thread to the dispatcher is > really powerfull. > > J?r?me and I are really interrested to get your feedback on this work. > Does this binding makes sense to you? How can we improve this work to fit > perfectly in Undertow and how can we extract a viable library from the demo? > > Thank you for your help, > > Regards, > Micha?l > > > > 2014-05-13 15:01 GMT+02:00 Stuart Douglas : > >> This does sound pretty cool. I would start by looking at the existing >> authenticator implementations and the security docs at >> >> http://undertow.io/documentation/core/security.html >> >> Stuart >> >> Micha?l REMOND wrote: >> >>> Hi, >>> >>> I currently contribute to a Java library from Jerome Leleu, able to >>> protect applications and delegate authentications to various identity >>> providers. It currently supports 5 different protocols: CAS, OAuth, >>> OpenID, HTTP and SAML and 18 identity providers (Facebook, Twitter, >>> Google, Yahoo...) through a very simple and unified API accross >>> protocols/JVM frameworks: https://github.com/leleuj/pac4j. >>> >>> The pac4j librairies are used in various JVM frameworks with the >>> appropriate implementations: Spring Security, Shiro, CAS, J2E and Play. >>> Although the core pac4j librairies gathers "a lot of" code (300 classes, >>> 26000 lines of source code), the implementations to specific JVM >>> frameworks are pretty straigtforward: from 4 classes for Spring Security >>> to 11 classes for Play Framework 2.x. >>> >>> We are currently targeting new plateforms and especially async one; we >>> got an implementation from ratpack (http://www.ratpack.io/) and we >>> discussed also with the guys from vert.x. They gave us some ideas in >>> order to improve our library by becoming more "reactive". >>> >>> I think that pac4j could be helpful for the Undertow community too by >>> bringing client multi-protocols support. >>> >>> I looked at the security model from Undertow and I start to think about >>> a possible integration by developing a "Pac4jAuthenticationMechanism". >>> >>> What do you think about such development? Are you interested in a demo >>> app showing how this could work? Do you have suggestions? >>> >>> Thanks. >>> Best regards, >>> Michael Remond >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141029/a197f17a/attachment.html From sdouglas at redhat.com Wed Oct 29 20:04:41 2014 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 29 Oct 2014 20:04:41 -0400 (EDT) Subject: [undertow-dev] CAS / OAuth / OpenID / HTTP / SAML client protocol support? In-Reply-To: References: <5372179B.8080006@redhat.com> Message-ID: <664454881.2082857.1414627481096.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Micha?l REMOND" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org, "J?r?me LELEU" > Sent: Wednesday, 29 October, 2014 8:28:53 PM > Subject: Re: [undertow-dev] CAS / OAuth / OpenID / HTTP / SAML client protocol support? > > Hello, > > I make a follow-up on this thread as I received no feedback on my pac4j > binding proposal. Sorry, I mean't to look at this but it slipped through the cracks. > > Are you interested in this authentication library? Can we improve its > design? I had a quick look through the code and for the most part it looks good. One thing that I would suggest changing is removing the static configuration, as it does not generally work very well in an application server environment where multiple deployments would be using it. I don't think something like this really belongs in Undertow core though. Maybe I should add a related projects section to the undertow.io site and link it there? Stuart > > Thank you for your help > > Regards, > Micha?l > > 2014-05-27 20:02 GMT+02:00 Micha?l REMOND : > > > Hello dear Community, > > > > I made a first draft of what could be a pac4j binding for Undertow. You > > can find our standard demo application here > > https://github.com/pac4j/undertow-pac4j-demo. You can test several > > different authentication providers (facebook, twitter, form, CAS, SAML...). > > > > I'd like to share some implementation details with you: > > - I implemented a new AuthenticationMechanism delegating the > > authentication to a pac4j client; so this mechanism is rather "generic" in > > regards to what you got in undertow (one for basic auth, one for form...) > > - pac4j needs a session mechanism so I used the Undertow SessionManager > > to store some attributes but also the User Profile once the user is > > successfully authenticated > > - pac4j also needs a callback url to finish the authentication process so > > I developped a dedicated handler > > - finally I used the EagerFormParsingHandler to grab the required POSTed > > data > > > > To conclude I have to say I really appreciated the maturity of the > > framework because it was pretty straightforward to play with all the > > concepts and the ability to change from the IO thread to the dispatcher is > > really powerfull. > > > > J?r?me and I are really interrested to get your feedback on this work. > > Does this binding makes sense to you? How can we improve this work to fit > > perfectly in Undertow and how can we extract a viable library from the > > demo? > > > > Thank you for your help, > > > > Regards, > > Micha?l > > > > > > > > 2014-05-13 15:01 GMT+02:00 Stuart Douglas : > > > >> This does sound pretty cool. I would start by looking at the existing > >> authenticator implementations and the security docs at > >> > >> http://undertow.io/documentation/core/security.html > >> > >> Stuart > >> > >> Micha?l REMOND wrote: > >> > >>> Hi, > >>> > >>> I currently contribute to a Java library from Jerome Leleu, able to > >>> protect applications and delegate authentications to various identity > >>> providers. It currently supports 5 different protocols: CAS, OAuth, > >>> OpenID, HTTP and SAML and 18 identity providers (Facebook, Twitter, > >>> Google, Yahoo...) through a very simple and unified API accross > >>> protocols/JVM frameworks: https://github.com/leleuj/pac4j. > >>> > >>> The pac4j librairies are used in various JVM frameworks with the > >>> appropriate implementations: Spring Security, Shiro, CAS, J2E and Play. > >>> Although the core pac4j librairies gathers "a lot of" code (300 classes, > >>> 26000 lines of source code), the implementations to specific JVM > >>> frameworks are pretty straigtforward: from 4 classes for Spring Security > >>> to 11 classes for Play Framework 2.x. > >>> > >>> We are currently targeting new plateforms and especially async one; we > >>> got an implementation from ratpack (http://www.ratpack.io/) and we > >>> discussed also with the guys from vert.x. They gave us some ideas in > >>> order to improve our library by becoming more "reactive". > >>> > >>> I think that pac4j could be helpful for the Undertow community too by > >>> bringing client multi-protocols support. > >>> > >>> I looked at the security model from Undertow and I start to think about > >>> a possible integration by developing a "Pac4jAuthenticationMechanism". > >>> > >>> What do you think about such development? Are you interested in a demo > >>> app showing how this could work? Do you have suggestions? > >>> > >>> Thanks. > >>> Best regards, > >>> Michael Remond > >>> > >>> _______________________________________________ > >>> undertow-dev mailing list > >>> undertow-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/undertow-dev > >>> > >> > > > From _c.c at mail.com Fri Oct 31 07:50:58 2014 From: _c.c at mail.com (Chris Christo) Date: Fri, 31 Oct 2014 19:50:58 +0800 Subject: [undertow-dev] Undertow with Docker Port issue Message-ID: Hi, Has anyone managed to get undertow working with docker (on CoreOS)? I have a very basic jar that starts up an undertow server on (localhost at port 80) and has a single HttpHandler at the endpoint ?/hello?. I?ve tested the jar locally and the endpoint works fine. I have a docker file along the lines of: --------------- FROM dockerfile/java:oracle-java8 ## wget the app from a server CMD java -jar my-app.jar EXPOSE 80 --------------- I then run the container (after building it from the above docker file) as follows: docker run -d -p 80:80 my-app (Yes I made sure the server did start and is running before the following:) I see that the iptables are as follows (which is identical to what dockerfiles/nginx produces): --------------- Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere 172.17.0.65 tcp dpt:http ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination --------------- Finally I try to curl at the ?/hello? endpoint but I just get a connection refused. I try the curl request to localhost from within the same server and it doesn?t work. I also try from a different computer using the public IP of the machine and it does?t work. The dockerfile/nginx works perfect when I curl at it at port 80. I?m stumped for ideas, please help! Thanks, Chris From ecki at zusammenkunft.net Fri Oct 31 07:55:52 2014 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 31 Oct 2014 12:55:52 +0100 Subject: [undertow-dev] Undertow with Docker Port issue In-Reply-To: References: Message-ID: Your iptables do not contain 127.0.0.1 and ::1 as destination? I would try it without a packet filter first. Am 31.10.2014 12:51 schrieb "Chris Christo" <_c.c at mail.com>: > Hi, > > Has anyone managed to get undertow working with docker (on CoreOS)? > > I have a very basic jar that starts up an undertow server on (localhost at > port 80) and has a single HttpHandler at the endpoint ?/hello?. I?ve tested > the jar locally and the endpoint works fine. > > I have a docker file along the lines of: > > --------------- > FROM dockerfile/java:oracle-java8 > > ## wget the app from a server > > CMD java -jar my-app.jar > > EXPOSE 80 > --------------- > > I then run the container (after building it from the above docker file) as > follows: > > docker run -d -p 80:80 my-app > > (Yes I made sure the server did start and is running before the following:) > > I see that the iptables are as follows (which is identical to what > dockerfiles/nginx produces): > > --------------- > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > ACCEPT tcp -- anywhere 172.17.0.65 tcp dpt:http > ACCEPT all -- anywhere anywhere ctstate > RELATED,ESTABLISHED > ACCEPT all -- anywhere anywhere > ACCEPT all -- anywhere anywhere > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > --------------- > > Finally I try to curl at the ?/hello? endpoint but I just get a connection > refused. I try the curl request to localhost from within the same server > and it doesn?t work. I also try from a different computer using the public > IP of the machine and it does?t work. > > The dockerfile/nginx works perfect when I curl at it at port 80. > > I?m stumped for ideas, please help! > > Thanks, > > Chris > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141031/d76f91fa/attachment.html From lanabe.lanabe at gmail.com Fri Oct 31 08:44:54 2014 From: lanabe.lanabe at gmail.com (lanabe) Date: Fri, 31 Oct 2014 21:44:54 +0900 Subject: [undertow-dev] Undertow with Docker Port issue In-Reply-To: References: Message-ID: Hi, Chris. > localhost at port 80 Could you change localhost to 0.0.0.0(or youe Docker container IP Address) at addHttpLIstner in your app? On Fri, Oct 31, 2014 at 8:55 PM, Bernd wrote: > Your iptables do not contain 127.0.0.1 and ::1 as destination? > > I would try it without a packet filter first. > Am 31.10.2014 12:51 schrieb "Chris Christo" <_c.c at mail.com>: > > Hi, >> >> Has anyone managed to get undertow working with docker (on CoreOS)? >> >> I have a very basic jar that starts up an undertow server on (localhost >> at port 80) and has a single HttpHandler at the endpoint ?/hello?. I?ve >> tested the jar locally and the endpoint works fine. >> >> I have a docker file along the lines of: >> >> --------------- >> FROM dockerfile/java:oracle-java8 >> >> ## wget the app from a server >> >> CMD java -jar my-app.jar >> >> EXPOSE 80 >> --------------- >> >> I then run the container (after building it from the above docker file) >> as follows: >> >> docker run -d -p 80:80 my-app >> >> (Yes I made sure the server did start and is running before the >> following:) >> >> I see that the iptables are as follows (which is identical to what >> dockerfiles/nginx produces): >> >> --------------- >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> ACCEPT tcp -- anywhere 172.17.0.65 tcp dpt:http >> ACCEPT all -- anywhere anywhere ctstate >> RELATED,ESTABLISHED >> ACCEPT all -- anywhere anywhere >> ACCEPT all -- anywhere anywhere >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> --------------- >> >> Finally I try to curl at the ?/hello? endpoint but I just get a >> connection refused. I try the curl request to localhost from within the >> same server and it doesn?t work. I also try from a different computer using >> the public IP of the machine and it does?t work. >> >> The dockerfile/nginx works perfect when I curl at it at port 80. >> >> I?m stumped for ideas, please help! >> >> Thanks, >> >> Chris >> >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141031/7a1d6989/attachment-0001.html From _c.c at mail.com Fri Oct 31 08:51:43 2014 From: _c.c at mail.com (Chris Christo) Date: Fri, 31 Oct 2014 20:51:43 +0800 Subject: [undertow-dev] Undertow with Docker Port issue In-Reply-To: References: Message-ID: Hi yeah I managed to get it to work. I set undertow server as 172.17.0.65 and it worked. To my understanding, this IP is something docker comes up with and is an internal IP (it's different every time you run a docker container). The external IP is something completely different. So in summary you must set the host server for undertow as the Internal IP in the Iptables created by docker. > On 31 Oct 2014, at 19:55, Bernd wrote: > > Your iptables do not contain 127.0.0.1 and ::1 as destination? > > I would try it without a packet filter first. > > Am 31.10.2014 12:51 schrieb "Chris Christo" <_c.c at mail.com>: >> Hi, >> >> Has anyone managed to get undertow working with docker (on CoreOS)? >> >> I have a very basic jar that starts up an undertow server on (localhost at port 80) and has a single HttpHandler at the endpoint ?/hello?. I?ve tested the jar locally and the endpoint works fine. >> >> I have a docker file along the lines of: >> >> --------------- >> FROM dockerfile/java:oracle-java8 >> >> ## wget the app from a server >> >> CMD java -jar my-app.jar >> >> EXPOSE 80 >> --------------- >> >> I then run the container (after building it from the above docker file) as follows: >> >> docker run -d -p 80:80 my-app >> >> (Yes I made sure the server did start and is running before the following:) >> >> I see that the iptables are as follows (which is identical to what dockerfiles/nginx produces): >> >> --------------- >> Chain INPUT (policy ACCEPT) >> target prot opt source destination >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> ACCEPT tcp -- anywhere 172.17.0.65 tcp dpt:http >> ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED >> ACCEPT all -- anywhere anywhere >> ACCEPT all -- anywhere anywhere >> >> Chain OUTPUT (policy ACCEPT) >> target prot opt source destination >> --------------- >> >> Finally I try to curl at the ?/hello? endpoint but I just get a connection refused. I try the curl request to localhost from within the same server and it doesn?t work. I also try from a different computer using the public IP of the machine and it does?t work. >> >> The dockerfile/nginx works perfect when I curl at it at port 80. >> >> I?m stumped for ideas, please help! >> >> Thanks, >> >> Chris >> >> >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141031/d6ab0c37/attachment.html From jeffw at wherethebitsroam.com Fri Oct 31 09:43:38 2014 From: jeffw at wherethebitsroam.com (Jeff Williams) Date: Fri, 31 Oct 2014 14:43:38 +0100 Subject: [undertow-dev] Changing headers on proxy response Message-ID: Hi, I am currently using a customer handler wrapping the proxy handler. I want to set some response headers from my handler, but if they exist in the response from the proxy's backend, they are overridden. Example code: Undertow.builder() .addHttpListener(8080, "localhost") .setHandler(new MyHandler(new ProxyHandler(proxy, 30000, ResponseCodeHandler.HANDLE_404))).build(); class MyHandler extends HttpHandler { private static final HttpString ACCESS_CONTROL_EXPOSE_HEADERS = new HttpString("Access-Control-Expose-Headers"); private HTTPHandler next; public MyHandler(HttpHandler next) { this.next = next; } public void handleRequest(HttpServerExchange exchange) throws Exception { exchange.getResponseHeaders().put(ACCESS_CONTROL_EXPOSE_HEADERS, "new ACEH"); } } The problem here is that the backend server responds with an Access-Control-Expose-Headers header and that replaces the one I set in MyHandler. Is there any way I can change headers after proxy has received the response from backend and before it starts sending the response to the client? Regards, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141031/bd1c1915/attachment.html From leleuj at gmail.com Fri Oct 31 10:42:17 2014 From: leleuj at gmail.com (=?UTF-8?B?SsOpcsO0bWUgTEVMRVU=?=) Date: Fri, 31 Oct 2014 15:42:17 +0100 Subject: [undertow-dev] CAS / OAuth / OpenID / HTTP / SAML client protocol support? In-Reply-To: <664454881.2082857.1414627481096.JavaMail.zimbra@redhat.com> References: <5372179B.8080006@redhat.com> <664454881.2082857.1414627481096.JavaMail.zimbra@redhat.com> Message-ID: Hi, Thanks for the feedback. I'm sure this static configuration can be improved. Being integrated into the core project or not is really a matter of the Undertow community: on one hand, pac4j is an official module for Shiro, CAS and Ratpack, on the other hand, it's a separate project for Vertx, J2E, Spring Security and Play. It's up to you. Once again, I'd like to publicly thank Micha?l for his great work on Undertow and on SAML as well. Thanks. Best regards, J?r?me LELEU Founder of CAS in the cloud: www.casinthecloud.com | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas | Creator of pac4j: www.pac4j.org 2014-10-30 1:04 GMT+01:00 Stuart Douglas : > > > ----- Original Message ----- > > From: "Micha?l REMOND" > > To: "Stuart Douglas" > > Cc: undertow-dev at lists.jboss.org, "J?r?me LELEU" > > Sent: Wednesday, 29 October, 2014 8:28:53 PM > > Subject: Re: [undertow-dev] CAS / OAuth / OpenID / HTTP / SAML client > protocol support? > > > > Hello, > > > > I make a follow-up on this thread as I received no feedback on my pac4j > > binding proposal. > > Sorry, I mean't to look at this but it slipped through the cracks. > > > > > Are you interested in this authentication library? Can we improve its > > design? > > I had a quick look through the code and for the most part it looks good. > One thing that I would suggest changing is removing the static > configuration, as it does not generally work very well in an application > server environment where multiple deployments would be using it. > > I don't think something like this really belongs in Undertow core though. > Maybe I should add a related projects section to the undertow.io site and > link it there? > > Stuart > > > > > Thank you for your help > > > > Regards, > > Micha?l > > > > 2014-05-27 20:02 GMT+02:00 Micha?l REMOND : > > > > > Hello dear Community, > > > > > > I made a first draft of what could be a pac4j binding for Undertow. You > > > can find our standard demo application here > > > https://github.com/pac4j/undertow-pac4j-demo. You can test several > > > different authentication providers (facebook, twitter, form, CAS, > SAML...). > > > > > > I'd like to share some implementation details with you: > > > - I implemented a new AuthenticationMechanism delegating the > > > authentication to a pac4j client; so this mechanism is rather > "generic" in > > > regards to what you got in undertow (one for basic auth, one for > form...) > > > - pac4j needs a session mechanism so I used the Undertow > SessionManager > > > to store some attributes but also the User Profile once the user is > > > successfully authenticated > > > - pac4j also needs a callback url to finish the authentication > process so > > > I developped a dedicated handler > > > - finally I used the EagerFormParsingHandler to grab the required > POSTed > > > data > > > > > > To conclude I have to say I really appreciated the maturity of the > > > framework because it was pretty straightforward to play with all the > > > concepts and the ability to change from the IO thread to the > dispatcher is > > > really powerfull. > > > > > > J?r?me and I are really interrested to get your feedback on this work. > > > Does this binding makes sense to you? How can we improve this work to > fit > > > perfectly in Undertow and how can we extract a viable library from the > > > demo? > > > > > > Thank you for your help, > > > > > > Regards, > > > Micha?l > > > > > > > > > > > > 2014-05-13 15:01 GMT+02:00 Stuart Douglas : > > > > > >> This does sound pretty cool. I would start by looking at the existing > > >> authenticator implementations and the security docs at > > >> > > >> http://undertow.io/documentation/core/security.html > > >> > > >> Stuart > > >> > > >> Micha?l REMOND wrote: > > >> > > >>> Hi, > > >>> > > >>> I currently contribute to a Java library from Jerome Leleu, able to > > >>> protect applications and delegate authentications to various identity > > >>> providers. It currently supports 5 different protocols: CAS, OAuth, > > >>> OpenID, HTTP and SAML and 18 identity providers (Facebook, Twitter, > > >>> Google, Yahoo...) through a very simple and unified API accross > > >>> protocols/JVM frameworks: https://github.com/leleuj/pac4j. > > >>> > > >>> The pac4j librairies are used in various JVM frameworks with the > > >>> appropriate implementations: Spring Security, Shiro, CAS, J2E and > Play. > > >>> Although the core pac4j librairies gathers "a lot of" code (300 > classes, > > >>> 26000 lines of source code), the implementations to specific JVM > > >>> frameworks are pretty straigtforward: from 4 classes for Spring > Security > > >>> to 11 classes for Play Framework 2.x. > > >>> > > >>> We are currently targeting new plateforms and especially async one; > we > > >>> got an implementation from ratpack (http://www.ratpack.io/) and we > > >>> discussed also with the guys from vert.x. They gave us some ideas in > > >>> order to improve our library by becoming more "reactive". > > >>> > > >>> I think that pac4j could be helpful for the Undertow community too by > > >>> bringing client multi-protocols support. > > >>> > > >>> I looked at the security model from Undertow and I start to think > about > > >>> a possible integration by developing a > "Pac4jAuthenticationMechanism". > > >>> > > >>> What do you think about such development? Are you interested in a > demo > > >>> app showing how this could work? Do you have suggestions? > > >>> > > >>> Thanks. > > >>> Best regards, > > >>> Michael Remond > > >>> > > >>> _______________________________________________ > > >>> undertow-dev mailing list > > >>> undertow-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/undertow-dev > > >>> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20141031/97bc434c/attachment-0001.html From _c.c at mail.com Fri Oct 31 07:50:58 2014 From: _c.c at mail.com (Chris Christo) Date: Fri, 31 Oct 2014 19:50:58 +0800 Subject: [undertow-dev] Undertow with Docker Port issue Message-ID: Hi, Has anyone managed to get undertow working with docker (on CoreOS)? I have a very basic jar that starts up an undertow server on (localhost at port 80) and has a single HttpHandler at the endpoint ?/hello?. I?ve tested the jar locally and the endpoint works fine. I have a docker file along the lines of: --------------- FROM dockerfile/java:oracle-java8 ## wget the app from a server CMD java -jar my-app.jar EXPOSE 80 --------------- I then run the container (after building it from the above docker file) as follows: docker run -d -p 80:80 my-app (Yes I made sure the server did start and is running before the following:) I see that the iptables are as follows (which is identical to what dockerfiles/nginx produces): --------------- Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT tcp -- anywhere 172.17.0.65 tcp dpt:http ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination --------------- Finally I try to curl at the ?/hello? endpoint but I just get a connection refused. I try the curl request to localhost from within the same server and it doesn?t work. I also try from a different computer using the public IP of the machine and it does?t work. The dockerfile/nginx works perfect when I curl at it at port 80. I?m stumped for ideas, please help! Thanks, Chris