From sdouglas at redhat.com Sun Jan 3 18:42:54 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 3 Jan 2016 18:42:54 -0500 (EST) Subject: [undertow-dev] UNDERTOW-577 - response code from SAM In-Reply-To: References: <1364207675.2200437.1450918836903.JavaMail.zimbra@redhat.com> Message-ID: <2074871984.4252795.1451864574698.JavaMail.zimbra@redhat.com> It was cherry-picked back to 1.3.x Stuart ----- Original Message ----- > From: "arjan tijms" > To: "Stuart Douglas" > Cc: "undertow-dev" > Sent: Thursday, 24 December, 2015 11:28:23 PM > Subject: Re: [undertow-dev] UNDERTOW-577 - response code from SAM > > Hi, > > On Thu, Dec 24, 2015 at 2:00 AM, Stuart Douglas wrote: > > > Looks like I made a mistake in the JIRA, it should already be in Wildfly. > > Can you test it out? > > > > I just did the check again and lo and behold, the fix is indeed already > there. I'm not really sure what went wrong with my quick test the other day > but it clearly works now. Double checked the source of > undertow-servlet-1.3.11.Final and the fix is really there, so this is > absolutely great. Thanks again! > > One question about the commit though, when it was committed here: > https://github.com/undertow-io/undertow/commit/6e9663576fcaaa14f5a9cedf4ae1a144b20fd09e > > It was committed in the master, but master was already 1.4.x at Nov 6, or > did I miss something here? Doesn't matter much for the end result but just > curious. > > Kind regards, > Arjan Tijms > > > > > > > > Stuart > > > > ----- Original Message ----- > > > From: "arjan tijms" > > > To: "undertow-dev" > > > Sent: Wednesday, 23 December, 2015 11:24:57 PM > > > Subject: [undertow-dev] UNDERTOW-577 - response code from SAM > > > > > > Hi, > > > > > > I wonder if it would make sense to port the (small) fix for UNDERTOW-577 > > back > > > to Undertow 1.3.x, and hopefully still include this with WF 10 final. > > > > > > This concerns one of the last (known) larger bugs with JASPIC in WildFly. > > > Without this being fixed, something like the 403 or 404 from a SAM is not > > > possible, Returning a 403 is specifically needed for the BASIC scheme. > > > > > > For instance, the following JSR 375 authentication mechanism now works on > > > GlassFish, but throws a "UT010019: Response already commited" on WildFly > > > 10rc4/Undertow 1.3.11: > > > > > > public AuthStatus validateRequest(HttpServletRequest request, > > > HttpServletResponse response, HttpMsgContext httpMsgContext) throws > > > AuthException { > > > String[] credentials = getCredentials(request); > > > if (!isEmpty(credentials)) { > > > IdentityStore identityStore = > > > CDI.current().select(IdentityStore.class).get(); > > > CredentialValidationResult result = identityStore.validate( > > > new UsernamePasswordCredential(credentials[0], new > > > Password(credentials[1]))); > > > > > > if (result.getStatus() == VALID) { > > > return httpMsgContext.notifyContainerAboutLogin( > > > result.getCallerName(), result.getCallerGroups()); > > > } > > > } > > > if (httpMsgContext.isProtected()) { > > > response.setHeader("WWW-Authenticate", basicHeaderValue); > > > return httpMsgContext.responseUnAuthorized(); > > > } > > > return httpMsgContext.doNothing(); > > > } > > > > > > The problem is the "httpMsgContext.responseUnAuthorized();" which does: > > > > > > try { > > > getResponse().sendError(SC_UNAUTHORIZED); > > > } catch (IOException e) { > > > throw new IllegalStateException(e); > > > } > > > return SEND_FAILURE; > > > > > > I'm not really sure what the schedule is for Undertow 1.4 vs a potential > > WF > > > 11 and/or EAP 7. If WF 11 is still far away and EAP 7 will be based on WF > > > 10, then it would really be great if this small but rather important fix > > > could still be included in WF 10. > > > > > > Kind regards, > > > Arjan Tijms > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > undertow-dev mailing list > > > undertow-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > From sdouglas at redhat.com Sun Jan 3 19:02:35 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 3 Jan 2016 19:02:35 -0500 (EST) Subject: [undertow-dev] embedded undertow async hello world In-Reply-To: References: Message-ID: <490099381.4254007.1451865755635.JavaMail.zimbra@redhat.com> I am not 100% sure what you are trying to test here. I have answered your questions but in terms of providing a meaningful performance test I think the code looks pretty wrong. The global state protected by a sync lock will not perform very well, and does not in any way represent the way the majority of web applications manage their state. What sort of real world situation you are trying to simulate here? Stuart ----- Original Message ----- > From: "seth/nqzero" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 30 December, 2015 3:05:05 PM > Subject: [undertow-dev] embedded undertow async hello world > > i'm doing a quick survey of java webserver performance baselines, with a > focus on async, inspired somewhat by the Techempower plaintext benchmark. > i've already done jetty (both sync and async), jetty-comsat (ie quasar), the > kilim (another bytecode based fiber implementation) http server, and sync > undertow (copied from the techempower github impl). i'd like to add an > undertow async > > for jetty i've used the servlet api for async, since i didn't see any other > option. but i'd prefer the non-servlet api for undertow. the docs for > undertow seem limited, esp for async. so i wanted to vet my solution. i'm > more interested in being canonical than squeezing the last bit of > performance (because eg: all the solutions are plenty fast, it's a terrible > benchmark, ease of implementation is a bigger factor than absolute > performance) > > open to any general comments, but specifically wondering: > - is my use of dispatch() correct This is correct. > - do i need to be calling isInIoThread() No, as you are not doing any blocking work. > - is it safe to access the exchange directly in reply() ? ie, in a > non-undertow thread In general yes, as long as you don't start modifying it in an Undertow thread at the same time. Your code should be changed to: exchange.dispatch(SameThreadExecutor.INSTANCE, () -> store(exchange)); This means the Undertow thread won't be published to another thread until after the Undertow thread has finished working with it. > > this is a somewhat simplified example that gets 75-80k req/s vs 85-90 for the > more verbose version, but the use of the async api is the same > > > ____my code is below___ > > import io.undertow.Handlers; > import io.undertow.Undertow; > import io.undertow.server.HttpHandler; > import io.undertow.server.HttpServerExchange; > import io.undertow.util.Headers; > import java.nio.ByteBuffer; > import java.util.Timer; > import java.util.TimerTask; > > public final class UtowAsync implements HttpHandler { > > public static void main(String[] args) throws Exception { > Undertow.builder() > .addHttpListener(9097,"0.0.0.0") > .setHandler(Handlers.path().addPrefixPath("/hello",new UtowAsync())) > .build() > .start(); > } > > int num = 0; > HttpServerExchange acv[] = new HttpServerExchange[10000]; > byte [] bytes = "hello world".getBytes(); > ByteBuffer buf = ByteBuffer.allocate(bytes.length).put(bytes); > { buf.flip(); } > > synchronized void store(HttpServerExchange async) { > if (async==null) while (num > 0) { > reply(acv[--num]); > acv[num] = null; > } > else acv[num++] = async; > } > > void reply(HttpServerExchange exchange) { > exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain"); > exchange.getResponseSender().send(buf.duplicate()); > } > > public void handleRequest(final HttpServerExchange exchange) throws Exception > { > store(exchange); > exchange.dispatch(); > } > > { > new Timer().schedule(new TimerTask() { public void run() { > UtowAsync.this.store(null); > } },10,10); > } > } > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From sony.abraham at ibsplc.com Tue Jan 5 03:18:18 2016 From: sony.abraham at ibsplc.com (Sony Abraham) Date: Tue, 5 Jan 2016 08:18:18 +0000 Subject: [undertow-dev] Multiple logins under same user id in Wildfly 9.0.2 uses same subject Message-ID: <092D38BA9CC1BC458B02A1C22960CFBC01BF2E0999@PBOX2.ibsplc.com> Hi, I am trying to port our existing application (in weblogic) to Jboss wildfly. Our application supports multiple logins under same user id but each logins need to be treated in different security context. For this we invoke the login modules by invoking j_security_check for each logins attempts. We use a custome Jaas login module from where the subject is created with a unique user token and set as name of the Principal after successful login. But when using wildfly, the login module is invoked only the first time and for the subsequent login attempts, the user subject is looked up from the domain cache inside JBossCachedAuthenticationManager. Further debugging into the issue i noticed below 1. After jaas login completes, the org.wildfly.extension.undertow.security.AccountImpl in exchange of ServletRequest gets updated with the new Principal (token set during jaas login) and the OriginalPrincipal remains the same as the user id. This is fine as expected (I hope). 2. org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(final AccountImpl account, final Object credential) uses the OriginalPrincipal to send to authenticationManager for validation. Since this is not updated, it will always be the original user id. Below source code from jboss.as uses account.getPrincipal() for getting the incomingPrincipal. But this is now changed to getOriginalPrincipal. I think this should be the principal (not the OriginalPrincipal). [cid:image001.png at 01D147BF.BB5A7BD0] 3. org.jboss.security.authentication.JBossCachedAuthenticationManager caches the subject info against the OriginalPrincipal. Therefor it always returns from the cache after the first successful authentication for a user id and JAAS login module is never invoked after that. Shouldn't the caching happen against the authenticated principal set in the subject (CallerPrincipal). Can anyone please let me know whether this behavior change is possible ? Or is there any way I can configure custom class for org.wildfly.extension.undertow.security.JAASIdentityManagerImpl and org.jboss.security.authentication.JBossCachedAuthenticationManager in wildfly 9.0.2. Regards Sony DISCLAIMER: "The information in this e-mail and any attachment is intended only for the person to whom it is addressed and may contain confidential and/or privileged material. If you have received this e-mail in error, kindly contact the sender and destroy all copies of the original communication. IBS makes no warranty, express or implied, nor guarantees the accuracy, adequacy or completeness of the information contained in this email or any attachment and is not liable for any errors, defects, omissions, viruses or for resultant loss or damage, if any, direct or indirect." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160105/909a9d79/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 16652 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160105/909a9d79/attachment-0001.png From arjan.tijms at gmail.com Tue Jan 5 12:32:41 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Tue, 5 Jan 2016 18:32:41 +0100 Subject: [undertow-dev] Multiple logins under same user id in Wildfly 9.0.2 uses same subject In-Reply-To: <092D38BA9CC1BC458B02A1C22960CFBC01BF2E0999@PBOX2.ibsplc.com> References: <092D38BA9CC1BC458B02A1C22960CFBC01BF2E0999@PBOX2.ibsplc.com> Message-ID: Hi, I remember that in older versions of JBoss there always was a (proprietary) API to explicitly clear the authentication cache. Maybe this could be of help here if that API is still there. An other option would be to try using the Java EE standard API for custom authentication modules. This is called JASPIC and WildFly has excellent support for those. Support is best in the latest version of WildFly, which is 10cr5. Kind regards, Arjan Tijms On Tue, Jan 5, 2016 at 9:18 AM, Sony Abraham wrote: > Hi, > > > > I am trying to port our existing application (in weblogic) to Jboss > wildfly. > > > > Our application supports multiple logins under same user id but each > logins need to be treated in different security context. For this we invoke > the login modules by invoking j_security_check for each logins attempts. We > use a custome Jaas login module from where the subject is created with a > unique user token and set as name of the Principal after successful login. > But when using wildfly, the login module is invoked only the first time and > for the subsequent login attempts, the user subject is looked up from the > domain cache inside JBossCachedAuthenticationManager. > > > > Further debugging into the issue i noticed below > > 1. After jaas login completes, the > org.wildfly.extension.undertow.security.AccountImpl in exchange of > ServletRequest gets updated with the new Principal (token set during jaas > login) and the OriginalPrincipal remains the same as the user id. This is > fine as expected (I hope). > > 2. org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(final > AccountImpl account, final Object credential) uses the OriginalPrincipal to > send to authenticationManager for validation. Since this is not updated, it > will always be the original user id. Below source code from jboss.as uses > account.getPrincipal() for getting the incomingPrincipal. But this is > now changed to getOriginalPrincipal. I think this should be the > principal (not the OriginalPrincipal). > > 3. org.jboss.security.authentication.JBossCachedAuthenticationManager > caches the subject info against the OriginalPrincipal. Therefor it always > returns from the cache after the first successful authentication for a user > id and JAAS login module is never invoked after that. Shouldn't the caching > happen against the authenticated principal set in the subject > (CallerPrincipal). > > > > Can anyone please let me know whether this behavior change is possible ? > Or is there any way I can configure custom class for > org.wildfly.extension.undertow.security.JAASIdentityManagerImpl and > org.jboss.security.authentication.JBossCachedAuthenticationManager in > wildfly 9.0.2. > > > > Regards > > Sony > > > > > DISCLAIMER: "The information in this e-mail and any attachment is > intended only for the person to whom it is addressed and may contain > confidential and/or privileged material. If you have received this e-mail > in error, kindly contact the sender and destroy all copies of the original > communication. IBS makes no warranty, express or implied, nor guarantees > the accuracy, adequacy or completeness of the information contained in this > email or any attachment and is not liable for any errors, defects, > omissions, viruses or for resultant loss or damage, if any, direct or > indirect." > > _______________________________________________ > 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/20160105/db6cff65/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 16652 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160105/db6cff65/attachment-0001.png From arjan.tijms at gmail.com Thu Jan 7 10:38:23 2016 From: arjan.tijms at gmail.com (arjan tijms) Date: Thu, 7 Jan 2016 16:38:23 +0100 Subject: [undertow-dev] Multiple logins under same user id in Wildfly 9.0.2 uses same subject In-Reply-To: <092D38BA9CC1BC458B02A1C22960CFBC01BF2E22E9@PBOX2.ibsplc.com> References: <092D38BA9CC1BC458B02A1C22960CFBC01BF2E0999@PBOX2.ibsplc.com> <092D38BA9CC1BC458B02A1C22960CFBC01BF2E1FD7@PBOX2.ibsplc.com> <092D38BA9CC1BC458B02A1C22960CFBC01BF2E22E9@PBOX2.ibsplc.com> Message-ID: Hi, On Thu, Jan 7, 2016 at 3:51 PM, Sony Abraham wrote: > Hi Arjan, > > > > Thanks again for your support and guidance. > > > > I have put my SAM module (jar) inside ear/lib. > If the SAM resides within the application then modifying standalone.xml is not needed. A reference to a SAM in standalone.xml is only really needed if the SAM is separate from the application, e.g. resides in a jar that you put somewhere in the /modules folder of WildFly. In this case you can just as well use the programmatic registration via a listener as demonstrated by the samples. > Also I am facing the below issues, when I try to access a protected > resource, I want redirect to my login page. For this I have mentioned the > login.jsp in the web.xml as below > > > > > FORM > > > > > > /login.jsp > > > /login.jsp > > > > > > But this is not happening automatically, I had to explicitly do > response.sendRedirect to get my login page (otherwise ?Unauthorized? error > was coming). Is this the right thing to do ? > This is unfortunately not correct. A SAM is an authenticated mechanism, not an identity store. So it replaces FORM. In other words the entire login-config element can be removed here as its overridden when using a SAM. > After I provide my username / password and do j_security_check I am > getting below error. Can you please let me know what I would had done wrong > j_security_check is the name in the URL that the build-in FORM authentication mechanism happens to be listening to. j_security_check is not some general mechanism by which security in Java EE is activated. There is clearly a mismatch in Java EE security. There are build-in authentication mechanisms and a standard API for custom authentication mechanisms, but no standard API for the identity store (the artifact that only focuses on {credentials in, caller data out}). What's typical though here is building a SAM that only redirects to a login page when a protected resource is requested and the user is not authenticated, and otherwise relies on Servlet's programmatic authenticate feature. So on /login.jsp you don't postback to a special URL, but post back to /login.jsp. Then backing code of /login.jsp sets the credentials as a request attribute and then calls HttpServletRequest.authenticate(). The SAM can then do the authentication as shown in the samples. Another option would be to re-use an existing authentication module that implements FORM and then modify the part where it calls to the server specific identity store. See e.g. https://github.com/eclipse/jetty.project/blob/master/jetty-jaspi/src/main/java/org/eclipse/jetty/security/jaspi/modules/FormAuthModule.java of http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.as/jboss-as-web/7.2.0.Final/org/jboss/as/web/security/jaspi/modules/HTTPFormServerAuthModule.java (do take the license into account of these and take note that you may have to do your own scrutiny of how secure those are) If you absolutely want or need to use the existing build-in FORM, then unfortunately JASPIC would not be the best option here. Unfortunately setting up (custom) security in Java EE is currently not entirely trivial. Kind regards, Arjan Tijms > *HTTP method POST is not supported by this URL* > > > > Regards > > Sony > > > > *From:* arjan tijms [mailto:arjan.tijms at gmail.com] > *Sent:* 07 January 2016 18:29 > *To:* Sony Abraham > > *Subject:* Re: [undertow-dev] Multiple logins under same user id in > Wildfly 9.0.2 uses same subject > > > > Hi, > > > > On Thu, Jan 7, 2016 at 8:10 AM, Sony Abraham > wrote: > > > > Thank you for your reply. I am complete new to SAMPIC, do you have any > sample implementation for custom JASPIC on wildfly that I can refer to ? > > > > Yes, there about 12 categories of samples for JASPIC here: > https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic > > > > The simplest sample can be found in > https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic/basic-authentication > > > > A very basic but fully working standalone application can be found here: > https://github.com/arjantijms/mechanism-to-store > > > > > > I read though your blog > http://arjan-tijms.omnifaces.org/2012/11/implementing-container-authentication.html > and > http://arjan-tijms.omnifaces.org/2013/04/whats-new-in-java-ee-7s-authentication.html > , but configuring the SAM module alone in standalone.xml and mentioning > that in jboss-web.xml invoked my login module. Could not exactly understand > why the factory and context classes were required ( I assume those > implementations are provided by jboss itself) > > > > The factory/config/context classes are there for when a fully in-app > portable application archive is needed. The only standardised way to > register a SAM is the programmatic way. The initial factory doesn't have a > method that just takes a SAM, but instead wants all these wrapper classes. > In hindsight this was perhaps not the most ideal decision and we hope to be > able to rectify this in the Java EE security EG. > > > > The non-standard way, in this case the JBoss specific way via > standalone.xml, does accept just a SAM. In that case the wrappers are > indeed provided by JBoss. > > > > > > But it?s been invoked for all resources (even non secure resources) > > > > That's correct. JASPIC authentication modules are invoked for every > resource, both secured (protected) and non-secured (public). Authentication > is also not automatically tied to a session. Coming from some other > proprietary mechanisms this may seem controversial, but it actually makes > it really flexible and makes the creation of e.g. stateless header based > authentication mechanisms trivial. See e.g. > http://arjan-tijms.omnifaces.org/2014/11/header-based-stateless-token.html > > > > You can check whether the SAM *must* do authentication (which includes > being called for a secured resource) via a helper method such as: > > > > public static boolean isProtectedResource(MessageInfo messageInfo) { > > return Boolean.valueOf((String) messageInfo.getMap().get(IS_MANDATORY)); > > } > > > > > > and the values in the handler and MessagePolicy are all coming as null. > > > > That doesn't seem right. Perhaps this is a bug when registering a SAM via > the standalone.xml method. Where did you put > the com.test.TestServerAuthModule class? Is it inside a .jar that you put > in your WildFly install (and if so, where?), or is this class inside your > application archive (.war)? > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > How can I configure the container not to invoke the SAM for non-secure > resources and why is the handler and MessagePolicy coming as null ? > > > > My standalone.xml entry is as below > > > > > > code="com.test.TestServerAuthModule" flag="optional"/> > > > > > > > > And jboss-web.xml as below > > > > > > test > > > > > > Regards, > > Sony > > > > *From:* arjan tijms [mailto:arjan.tijms at gmail.com] > *Sent:* 05 January 2016 23:03 > *To:* Sony Abraham > *Cc:* undertow-dev at lists.jboss.org > *Subject:* Re: [undertow-dev] Multiple logins under same user id in > Wildfly 9.0.2 uses same subject > > > > Hi, > > > > I remember that in older versions of JBoss there always was a > (proprietary) API to explicitly clear the authentication cache. Maybe this > could be of help here if that API is still there. > > > > An other option would be to try using the Java EE standard API for custom > authentication modules. This is called JASPIC and WildFly has excellent > support for those. Support is best in the latest version of WildFly, which > is 10cr5. > > > > Kind regards, > > Arjan Tijms > > > > > > > > > > > > On Tue, Jan 5, 2016 at 9:18 AM, Sony Abraham > wrote: > > Hi, > > > > I am trying to port our existing application (in weblogic) to Jboss > wildfly. > > > > Our application supports multiple logins under same user id but each > logins need to be treated in different security context. For this we invoke > the login modules by invoking j_security_check for each logins attempts. We > use a custome Jaas login module from where the subject is created with a > unique user token and set as name of the Principal after successful login. > But when using wildfly, the login module is invoked only the first time and > for the subsequent login attempts, the user subject is looked up from the > domain cache inside JBossCachedAuthenticationManager. > > > > Further debugging into the issue i noticed below > > 1. After jaas login completes, the > org.wildfly.extension.undertow.security.AccountImpl in exchange of > ServletRequest gets updated with the new Principal (token set during jaas > login) and the OriginalPrincipal remains the same as the user id. This is > fine as expected (I hope). > > 2. org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(final > AccountImpl account, final Object credential) uses the OriginalPrincipal to > send to authenticationManager for validation. Since this is not updated, it > will always be the original user id. Below source code from jboss.as > uses account.getPrincipal() for getting the incomingPrincipal. But this > is now changed to getOriginalPrincipal. I think this should be the > principal (not the OriginalPrincipal). > > 3. org.jboss.security.authentication.JBossCachedAuthenticationManager > caches the subject info against the OriginalPrincipal. Therefor it always > returns from the cache after the first successful authentication for a user > id and JAAS login module is never invoked after that. Shouldn't the caching > happen against the authenticated principal set in the subject > (CallerPrincipal). > > > > Can anyone please let me know whether this behavior change is possible ? > Or is there any way I can configure custom class for > org.wildfly.extension.undertow.security.JAASIdentityManagerImpl and > org.jboss.security.authentication.JBossCachedAuthenticationManager in > wildfly 9.0.2. > > > > Regards > > Sony > > > > > > DISCLAIMER: "The information in this e-mail and any attachment is > intended only for the person to whom it is addressed and may contain > confidential and/or privileged material. If you have received this e-mail > in error, kindly contact the sender and destroy all copies of the original > communication. IBS makes no warranty, express or implied, nor guarantees > the accuracy, adequacy or completeness of the information contained in this > email or any attachment and is not liable for any errors, defects, > omissions, viruses or for resultant loss or damage, if any, direct or > indirect." > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > > > > > > DISCLAIMER: "The information in this e-mail and any attachment is > intended only for the person to whom it is addressed and may contain > confidential and/or privileged material. If you have received this e-mail > in error, kindly contact the sender and destroy all copies of the original > communication. IBS makes no warranty, express or implied, nor guarantees > the accuracy, adequacy or completeness of the information contained in this > email or any attachment and is not liable for any errors, defects, > omissions, viruses or for resultant loss or damage, if any, direct or > indirect." > > > > > DISCLAIMER: "The information in this e-mail and any attachment is > intended only for the person to whom it is addressed and may contain > confidential and/or privileged material. If you have received this e-mail > in error, kindly contact the sender and destroy all copies of the original > communication. IBS makes no warranty, express or implied, nor guarantees > the accuracy, adequacy or completeness of the information contained in this > email or any attachment and is not liable for any errors, defects, > omissions, viruses or for resultant loss or damage, if any, direct or > indirect." > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160107/2b35a416/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 16652 bytes Desc: not available Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160107/2b35a416/attachment-0001.png From blue at nqzero.com Thu Jan 7 16:47:51 2016 From: blue at nqzero.com (seth/nqzero) Date: Thu, 7 Jan 2016 16:47:51 -0500 Subject: [undertow-dev] embedded undertow async hello world In-Reply-To: <490099381.4254007.1451865755635.JavaMail.zimbra@redhat.com> References: <490099381.4254007.1451865755635.JavaMail.zimbra@redhat.com> Message-ID: > I am not 100% sure what you are trying to test here > The global state protected by a sync lock will not perform very well, > and does not in any way represent the way the majority of web applications manage their state. > > What sort of real world situation you are trying to simulate here? i've written a java database engine - the sync lock is simulating this database. initially i'm focusing on low-end VPS hosts, so i'm more interested in efficiency than peak performance. i'm just trying to get a baseline (as opposed to a benchmark) of what async is capable of on various platforms my database is (kilim) fiber-based and can handle far more concurrent queries than the OS can support threads, so my motivation is to verify that the web server can support a comparable number of open connections. this isn't apples to apples - in the real case there could be many more connections and much more delay, but this seems like a good start here's the faster version: https://github.com/nqzero/jempower/blob/master/utow/src/main/java/UtowAsync2.java it still has the global lock, but does the actual processing in multiple threads. the repository has versions for some other platforms as well (jetty, comsat and kilim) comparing the 3 undertow handlers 124k req/s - sync (from TechEmpower benchmark) 92k req/s - async (reply inside lock) 118k req/s - async2 (with 3 threads) this is on an i3, and i'm testing with ab (2 instances are required to saturate the sync and async2 versions) at various concurrency levels (mostly 1000 - 10000), and the TechEmpower version results in some receive errors at lower concurrencies than the async versions i also need an example of asynchronous usage so i can tell people how to build a webapp using my database with undertow, so i want to be doing the "right" things - hence the simple async version. thanks for the feedback to my questions. if you can point me to a simpler example of async undertow (that doesn't involve a thread-per-connection), i'm happy to use that instead my conclusion is that for undertow, using async adds at most an insignificant overhead, perhaps something on the order of 5% throughput and can be implemented easily, using the dispatch/getResponseSender pair does this sound right to you ? any idea how much memory is allocated for each outstanding request ? i'm assuming it is much less than the memory needed for an OS thread (using top i see a 40k concurrency delta -> a delta of 300M in resident memory usage, but realize that this is a crude technique) if you'd like to see any changes or want to add a caveat so i don't misrepresent undertow, add a pull request or just let me know - my goal is to advocate for async while being (reasonably) platform agnostic -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160107/b4f44bc4/attachment.html From marc.boorshtein at tremolosecurity.com Fri Jan 8 02:41:40 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Fri, 8 Jan 2016 02:41:40 -0500 Subject: [undertow-dev] Help embedding undertow and TLS Message-ID: I'm trying to replace Jetty 7 with with Undertow 1.3.11.Final. In Jetty 7 I was able to create an org.eclipse.jetty.util.ssl.SslContextFactory that let me: 1. determine if client auth is needed, allowed or required 2. disable sslv3 3. enable only certain ciphers Looking at undertow I see that I can use Undertow.addHttpsListener with an SSLContext but I don't see how set client auth, ciphers, etc. Any help would be greatly appreciated. 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/20160108/f00024d6/attachment.html From fabian.mager at tu-dresden.de Tue Jan 12 07:46:48 2016 From: fabian.mager at tu-dresden.de (Fabian Mager) Date: Tue, 12 Jan 2016 13:46:48 +0100 Subject: [undertow-dev] SSE Close Task Message-ID: <5694F5B8.3060707@tu-dresden.de> Hey, I am using Undertow 1.3.11.Final and have problems with SSE connections closed by the client. I already found https://issues.jboss.org/browse/UNDERTOW-589 but I cannot observe that behavior. It doesn't matter how many messages I send after the client closed the connection, the close task is never called. Another issue is the send(String data, EventCallback callback) function from ServerSentEventConnection. The callback allows me to specify a done(...) and failed(...) method that is called either when the data was successfully submitted or not. In case it was, done(...) gets correctly called but in case the client already closed the connection then I assume failed(...) should be called but it gets never called. I would appreciate any help in case I missed some things. Cheers, Fabian From sdouglas at redhat.com Thu Jan 14 02:37:02 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 14 Jan 2016 02:37:02 -0500 (EST) Subject: [undertow-dev] SSE Close Task In-Reply-To: <5694F5B8.3060707@tu-dresden.de> References: <5694F5B8.3060707@tu-dresden.de> Message-ID: <1386530231.9353112.1452757022311.JavaMail.zimbra@redhat.com> This sounds like a bug, can you file a JIRA? Stuart ----- Original Message ----- > From: "Fabian Mager" > To: undertow-dev at lists.jboss.org > Sent: Tuesday, 12 January, 2016 9:46:48 PM > Subject: [undertow-dev] SSE Close Task > > Hey, > > I am using Undertow 1.3.11.Final and have problems with SSE connections > closed by the client. I already found > https://issues.jboss.org/browse/UNDERTOW-589 but I cannot observe that > behavior. It doesn't matter how many messages I send after the client > closed the connection, the close task is never called. > > Another issue is the send(String data, EventCallback callback) function > from ServerSentEventConnection. The callback allows me to specify a > done(...) and failed(...) method that is called either when the data was > successfully submitted or not. In case it was, done(...) gets correctly > called but in case the client already closed the connection then I > assume failed(...) should be called but it gets never called. > > I would appreciate any help in case I missed some things. > > Cheers, > Fabian > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From sdouglas at redhat.com Thu Jan 14 02:49:58 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 14 Jan 2016 02:49:58 -0500 (EST) Subject: [undertow-dev] Help embedding undertow and TLS In-Reply-To: References: Message-ID: <362126315.9354350.1452757798427.JavaMail.zimbra@redhat.com> You control this via XNIO Options (e.g. org.xnio.Options#SSL_CLIENT_AUTH_MODE). You can specify them using io.undertow.Undertow.Builder#setSocketOption In your case you need: SSL_CLIENT_AUTH_MODE: controls client auth SSL_ENABLED_PROTOCOLS: control allows SSL/TLS versions SSL_ENABLED_CIPHER_SUITES: control ciphers Stuart ----- Original Message ----- > From: "Marc Boorshtein" > To: "undertow-dev at lists jboss. org" > Sent: Friday, 8 January, 2016 4:41:40 PM > Subject: [undertow-dev] Help embedding undertow and TLS > > I'm trying to replace Jetty 7 with with Undertow 1.3.11.Final. In Jetty 7 I > was able to create an > org.eclipse.jetty.util.ssl.SslContextFactory that let me: > > 1. determine if client auth is needed, allowed or required > 2. disable sslv3 > 3. enable only certain ciphers > > Looking at undertow I see that I can use Undertow.addHttpsListener with an > SSLContext but I don't see how set client auth, ciphers, etc. > > Any help would be greatly appreciated. > > 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 marc.boorshtein at tremolosecurity.com Thu Jan 14 10:11:35 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Thu, 14 Jan 2016 10:11:35 -0500 Subject: [undertow-dev] Memory leak in undertow 1.3.11.Final Message-ID: I have undertow embedded into my application and for the most part its working great, but unfortunately I've found a memory leak. The application its self creates an Undertow server using SSL and then adds servlets and filters. There are no custom handlers. Throughout the logs I get the following NPEs: 2016-01-14 09:50:04,681][XNIO-2 task-28] ERROR request - UT005071: Undertow request failed HttpServerExchange{ GET /wp-content/themes/Nexus/style.css request {Accept=[text/css, */*], Connection=[Keep-Alive], Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], Cookie=[nowwwsession=eyJpdiI6Ik5hV0xCWWR5VExzUEEzRTBVNUFKUkFcdTAwM2RcdTAwM2QiLCJlbmNyeXB0ZWRSZXF1ZXN0IjoiS2t0TENaVGZFb1NWNjlyVXB4aUxuQ2RHRmlTZzVDWm0veTFXLytXWlBQMEhpMDZKK3FaQWpQYnBGY0RnMW15RCJ9; nvers-prod-session=eyJpdiI6Ikd2Wk5oTDVGbjdSTElGejlQSzFsalFcdTAwM2RcdTAwM2QiLCJlbmNyeXB0ZWRSZXF1ZXN0IjoiN2VldzBiT1lIWkZNaVgwTzV5b2tUSVNnaWwzTC9tRHpmeEdDOFZiQzh2a1RZN29ScElqbHFyZys3dmZMWUNhRSJ9], Referer=[https://www.nvers.org/the-team/], User-Agent=[Mozilla/5.0 (Windows NT 10.0; Trident/7.0; MALC; rv:11.0) like Gecko], Host=[www.nvers.org]} response {Connection=[close], Last-Modified=[Thu, 26 Mar 2015 18:45:16 GMT], Server=[Apache/2.2.15 (CentOS)], Content-Type=[text/css], Content-Language=[en-US], Accept-Ranges=[bytes], Date=[Thu, 14 Jan 2016 14:37:10 GMT]}} java.lang.NullPointerException at io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:713) at io.undertow.conduits.FinishableStreamSinkConduit.flush(FinishableStreamSinkConduit.java:83) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119) at org.xnio.channels.Channels.flushBlocking(Channels.java:63) at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:609) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:476) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:560) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Also, I see the following in System.out: Exception in thread "XNIO-2 task-18" java.lang.NullPointerException at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:605) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:267) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119) at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:226) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) After taking a heap dump and analyzing, I'm finding that a single thread is holding all the objects: The thread *org.xnio.nio.WorkerThread @ 0xc48cac70 XNIO-2 I/O-4* keeps local variables with total size *578,543,888 (95.77%)* bytes. The memory is accumulated in one instance of *"java.lang.Object[]"* loaded by *""*. XNIO-2 I/O-4 at sun.security.ssl.SSLEngineImpl.unwrap(Ljava/nio/ByteBuffer;[Ljava/nio/ByteBuffer;II)Ljavax/net/ssl/SSLEngineResult; (SSLEngineImpl.java:781) at io.undertow.protocols.ssl.SslConduit.doUnwrap([Ljava/nio/ByteBuffer;II)J (SslConduit.java:682) at io.undertow.protocols.ssl.SslConduit.read(Ljava/nio/ByteBuffer;)I (SslConduit.java:525) at org.xnio.conduits.ConduitStreamSourceChannel.read(Ljava/nio/ByteBuffer;)I (ConduitStreamSourceChannel.java:127) at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(Lorg/xnio/conduits/ConduitStreamSourceChannel;)V (HttpReadListener.java:149) at io.undertow.server.protocol.http.HttpReadListener.handleEvent(Lorg/xnio/conduits/ConduitStreamSourceChannel;)V (HttpReadListener.java:127) at io.undertow.server.protocol.http.HttpReadListener.handleEvent(Ljava/nio/channels/Channel;)V (HttpReadListener.java:56) at org.xnio.ChannelListeners.invokeChannelListener(Ljava/nio/channels/Channel;Lorg/xnio/ChannelListener;)Z (ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady()V (ReadReadyHandler.java:66) at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady()V (SslConduit.java:1054) at io.undertow.protocols.ssl.SslConduit$1.run()V (SslConduit.java:225) at org.xnio.nio.WorkerThread.safeRun(Ljava/lang/Runnable;)V (WorkerThread.java:580) at org.xnio.nio.WorkerThread.run()V (WorkerThread.java:464) Any help would be appreciated. We didn't have any memory leak issues with Jetty which is what we used prior so I don't think its an issue with our internal code triggering this. 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/20160114/c28bedcf/attachment-0001.html From sdouglas at redhat.com Fri Jan 15 04:09:38 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 15 Jan 2016 04:09:38 -0500 (EST) Subject: [undertow-dev] Memory leak in undertow 1.3.11.Final In-Reply-To: References: Message-ID: <1246501905.9956855.1452848978175.JavaMail.zimbra@redhat.com> Can you try with 1.3.12.Final? I think this should already be fixed. Stuart ----- Original Message ----- > From: "Marc Boorshtein" > To: "undertow-dev at lists jboss. org" > Sent: Friday, 15 January, 2016 12:11:35 AM > Subject: [undertow-dev] Memory leak in undertow 1.3.11.Final > > I have undertow embedded into my application and for the most part its > working great, but unfortunately I've found a memory leak. The application > its self creates an Undertow server using SSL and then adds servlets and > filters. There are no custom handlers. > > Throughout the logs I get the following NPEs: > > 2016-01-14 09:50:04,681][XNIO-2 task-28] ERROR request - UT005071: Undertow > request failed HttpServerExchange{ GET /wp-content/themes/Nexus/style.css > request {Accept=[text/css, */*], Connection=[Keep-Alive], > Accept-Language=[en-US,en;q=0.5], Accept-Encoding=[gzip, deflate], > Cookie=[nowwwsession=eyJpdiI6Ik5hV0xCWWR5VExzUEEzRTBVNUFKUkFcdTAwM2RcdTAwM2QiLCJlbmNyeXB0ZWRSZXF1ZXN0IjoiS2t0TENaVGZFb1NWNjlyVXB4aUxuQ2RHRmlTZzVDWm0veTFXLytXWlBQMEhpMDZKK3FaQWpQYnBGY0RnMW15RCJ9; > nvers-prod-session=eyJpdiI6Ikd2Wk5oTDVGbjdSTElGejlQSzFsalFcdTAwM2RcdTAwM2QiLCJlbmNyeXB0ZWRSZXF1ZXN0IjoiN2VldzBiT1lIWkZNaVgwTzV5b2tUSVNnaWwzTC9tRHpmeEdDOFZiQzh2a1RZN29ScElqbHFyZys3dmZMWUNhRSJ9], > Referer=[ https://www.nvers.org/the-team/ ], User-Agent=[Mozilla/5.0 > (Windows NT 10.0; Trident/7.0; MALC; rv:11.0) like Gecko], Host=[ > www.nvers.org ]} response {Connection=[close], Last-Modified=[Thu, 26 Mar > 2015 18:45:16 GMT], Server=[Apache/2.2.15 (CentOS)], > Content-Type=[text/css], Content-Language=[en-US], Accept-Ranges=[bytes], > Date=[Thu, 14 Jan 2016 14:37:10 GMT]}} > java.lang.NullPointerException > at > io.undertow.server.protocol.http.HttpResponseConduit.flush(HttpResponseConduit.java:713) > at > io.undertow.conduits.FinishableStreamSinkConduit.flush(FinishableStreamSinkConduit.java:83) > at > org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) > at > io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119) > at org.xnio.channels.Channels.flushBlocking(Channels.java:63) > at > io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:609) > at > io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:476) > at > io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:560) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > > Also, I see the following in System.out: > Exception in thread "XNIO-2 task-18" java.lang.NullPointerException > at > io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:605) > at > io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:267) > at > org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) > at > io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:119) > at > io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1652) > at > io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1630) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:226) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > After taking a heap dump and analyzing, I'm finding that a single thread is > holding all the objects: > > > The thread org.xnio.nio.WorkerThread @ 0xc48cac70 XNIO-2 I/O-4 keeps local > variables with total size 578,543,888 (95.77%) bytes. > > > > The memory is accumulated in one instance of "java.lang.Object[]" loaded by > "" . > > XNIO-2 I/O-4 > > at > sun.security.ssl.SSLEngineImpl.unwrap(Ljava/nio/ByteBuffer;[Ljava/nio/ByteBuffer;II)Ljavax/net/ssl/SSLEngineResult; > (SSLEngineImpl.java:781) > > at io.undertow.protocols.ssl.SslConduit.doUnwrap([Ljava/nio/ByteBuffer;II)J > (SslConduit.java:682) > > at io.undertow.protocols.ssl.SslConduit.read(Ljava/nio/ByteBuffer;)I > (SslConduit.java:525) > > at org.xnio.conduits.ConduitStreamSourceChannel.read(Ljava/nio/ByteBuffer;)I > (ConduitStreamSourceChannel.java:127) > > at > io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(Lorg/xnio/conduits/ConduitStreamSourceChannel;)V > (HttpReadListener.java:149) > > at > io.undertow.server.protocol.http.HttpReadListener.handleEvent(Lorg/xnio/conduits/ConduitStreamSourceChannel;)V > (HttpReadListener.java:127) > > at > io.undertow.server.protocol.http.HttpReadListener.handleEvent(Ljava/nio/channels/Channel;)V > (HttpReadListener.java:56) > > at > org.xnio.ChannelListeners.invokeChannelListener(Ljava/nio/channels/Channel;Lorg/xnio/ChannelListener;)Z > (ChannelListeners.java:92) > > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady()V > (ReadReadyHandler.java:66) > > at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady()V > (SslConduit.java:1054) > > at io.undertow.protocols.ssl.SslConduit$1.run()V (SslConduit.java:225) > > at org.xnio.nio.WorkerThread.safeRun(Ljava/lang/Runnable;)V > (WorkerThread.java:580) > > at org.xnio.nio.WorkerThread.run()V (WorkerThread.java:464) > > > Any help would be appreciated. We didn't have any memory leak issues with > Jetty which is what we used prior so I don't think its an issue with our > internal code triggering this. > > 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 Angelo.Salvade at zkb.ch Fri Jan 15 06:19:11 2016 From: Angelo.Salvade at zkb.ch (=?utf-8?B?U2FsdmFkw6ggQW5nZWxv?=) Date: Fri, 15 Jan 2016 11:19:11 +0000 Subject: [undertow-dev] How to get the remote socket address of a javax.websocket.Session ? Message-ID: <554e6a6c306d4152aa037875cfc3bdbb@WIN1145-PAPPL.prod.zkb.ch> 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. From marc.boorshtein at tremolosecurity.com Fri Jan 15 08:56:04 2016 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Fri, 15 Jan 2016 08:56:04 -0500 Subject: [undertow-dev] Memory leak in undertow 1.3.11.Final In-Reply-To: <1246501905.9956855.1452848978175.JavaMail.zimbra@redhat.com> References: <1246501905.9956855.1452848978175.JavaMail.zimbra@redhat.com> Message-ID: > > Can you try with 1.3.12.Final? I think this should already be fixed. > > I have and it does look to have fixed the issue. I'm not seeing the exceptions anymore and memory seems steady. I'll continue to monitor. BTW - GREAT system! Integration was mostly painless (considering I was ripping out a really old version of Jetty) and the docs were spot on. The performance difference was instant. Its great how easy it is to create webapps programaticly, making it that much easier to control the configuration. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160115/e4639feb/attachment.html From sdouglas at redhat.com Sat Jan 16 02:31:55 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Sat, 16 Jan 2016 02:31:55 -0500 (EST) Subject: [undertow-dev] How to get the remote socket address of a javax.websocket.Session ? In-Reply-To: <554e6a6c306d4152aa037875cfc3bdbb@WIN1145-PAPPL.prod.zkb.ch> References: <554e6a6c306d4152aa037875cfc3bdbb@WIN1145-PAPPL.prod.zkb.ch> Message-ID: <1295400383.10357511.1452929515614.JavaMail.zimbra@redhat.com> You would need to cast it to io.undertow.websockets.jsr.UndertowSession and then get getWebSocketChannel(). You can then get this via getSourceAddress(). Stuart ----- Original Message ----- > From: "Salvad? Angelo" > To: undertow-dev at lists.jboss.org > Sent: Friday, 15 January, 2016 8:19:11 PM > Subject: [undertow-dev] How to get the remote socket address of a javax.websocket.Session ? > > 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. > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From angelo.salvade at gmail.com Sat Jan 16 09:18:38 2016 From: angelo.salvade at gmail.com (Angelo Salvade) Date: Sat, 16 Jan 2016 15:18:38 +0100 Subject: [undertow-dev] How to get the remote socket address of a javax.websocket.Session ? Message-ID: Thanks for the quick reply. Sorry, I should have been able to find this out by myself. From scrapmachines at gmail.com Tue Jan 19 01:49:07 2016 From: scrapmachines at gmail.com (Girish Sharma) Date: Tue, 19 Jan 2016 12:19:07 +0530 Subject: [undertow-dev] Undertow changelog and latest features Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160119/f8d1abd5/attachment.html From Thomas.Jaeckle at bosch-si.com Tue Jan 19 05:50:00 2016 From: Thomas.Jaeckle at bosch-si.com (Jaeckle Thomas (INST/ECS1)) Date: Tue, 19 Jan 2016 10:50:00 +0000 Subject: [undertow-dev] Reverse-Proxy: Consuming InputStream before delegating to proxy target Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160119/45049444/attachment-0001.html From Thomas.Jaeckle at bosch-si.com Wed Jan 20 04:48:49 2016 From: Thomas.Jaeckle at bosch-si.com (Jaeckle Thomas (INST/ECS1)) Date: Wed, 20 Jan 2016 09:48:49 +0000 Subject: [undertow-dev] Reverse-Proxy: Consuming InputStream before delegating to proxy target Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160120/d2bccf43/attachment.html From leleuj at gmail.com Thu Jan 21 13:22:10 2016 From: leleuj at gmail.com (=?UTF-8?B?SsOpcsO0bWUgTEVMRVU=?=) Date: Thu, 21 Jan 2016 19:22:10 +0100 Subject: [undertow-dev] New security library for Undertow: undertow-pac4j v1.1 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160121/82633bf4/attachment.html From bburke at redhat.com Thu Jan 21 18:10:41 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 21 Jan 2016 18:10:41 -0500 Subject: [undertow-dev] sessionId changes between requests? Message-ID: <56A16571.5060304@redhat.com> 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 From bburke at redhat.com Thu Jan 21 19:44:53 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 21 Jan 2016 19:44:53 -0500 Subject: [undertow-dev] sessionId changes between requests? In-Reply-To: <56A16571.5060304@redhat.com> References: <56A16571.5060304@redhat.com> Message-ID: <56A17B85.7060907@redhat.com> Ok, found it. setChangeSessionIdOnLogin() Can I ask why this is done? Security reasons? To change the cookie? If it is to change the cookie, would be really good in the future to decouple the session cookie value from the session id so that plugins, like Keycloak, that are remotely managing and monitoring sessions can still do so without creating a security hole. On 1/21/2016 6:10 PM, Bill Burke wrote: > 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 From sdouglas at redhat.com Thu Jan 21 22:28:19 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 21 Jan 2016 22:28:19 -0500 (EST) Subject: [undertow-dev] sessionId changes between requests? In-Reply-To: <56A17B85.7060907@redhat.com> References: <56A16571.5060304@redhat.com> <56A17B85.7060907@redhat.com> Message-ID: <1681713971.13540920.1453433299249.JavaMail.zimbra@redhat.com> This was done for security reasons (see https://issues.jboss.org/browse/UNDERTOW-579). I don't know how practical it would be to de-couple the cookie value from the session ID. Could you just use a javax.servlet.http.HttpSessionIdListener to monitor session ID changes? Stuart ----- Original Message ----- > From: "Bill Burke" > To: undertow-dev at lists.jboss.org > Sent: Friday, 22 January, 2016 11:44:53 AM > Subject: Re: [undertow-dev] sessionId changes between requests? > > Ok, found it. setChangeSessionIdOnLogin() > > Can I ask why this is done? Security reasons? To change the cookie? > If it is to change the cookie, would be really good in the future to > decouple the session cookie value from the session id so that plugins, > like Keycloak, that are remotely managing and monitoring sessions can > still do so without creating a security hole. > > On 1/21/2016 6:10 PM, Bill Burke wrote: > > 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 > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev > From sdouglas at redhat.com Thu Jan 21 22:33:03 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 21 Jan 2016 22:33:03 -0500 (EST) Subject: [undertow-dev] Reverse-Proxy: Consuming InputStream before delegating to proxy target In-Reply-To: References: Message-ID: <2019780819.13541543.1453433583019.JavaMail.zimbra@redhat.com> Have a look at the code in io.undertow.server.handlers.RequestBufferingHandler This basically fully reads the request (assuming it fits in the buffers), then uses Connectors.ungetRequestBytes(exchange, bufferedData); to restore the data. You could do something similar. Stuart ----- Original Message ----- > From: "Jaeckle Thomas (INST/ECS1)" > To: undertow-dev at lists.jboss.org > Sent: Wednesday, 20 January, 2016 8:48:49 PM > Subject: [undertow-dev] Reverse-Proxy: Consuming InputStream before delegating to proxy target > > > > 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 > > > > > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev From bburke at redhat.com Thu Jan 21 23:29:29 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 21 Jan 2016 23:29:29 -0500 Subject: [undertow-dev] sessionId changes between requests? In-Reply-To: <1681713971.13540920.1453433299249.JavaMail.zimbra@redhat.com> References: <56A16571.5060304@redhat.com> <56A17B85.7060907@redhat.com> <1681713971.13540920.1453433299249.JavaMail.zimbra@redhat.com> Message-ID: <56A1B029.9000307@redhat.com> Maybe a decoupling of cookie from session ID isn't very feasible...I guess I can just turn off the "changeSessionIdOnLogin" switch and change the ID within the authenticator instead. On 1/21/2016 10:28 PM, Stuart Douglas wrote: > This was done for security reasons (see https://issues.jboss.org/browse/UNDERTOW-579). > > I don't know how practical it would be to de-couple the cookie value from the session ID. Could you just use a javax.servlet.http.HttpSessionIdListener to monitor session ID changes? > > Stuart > > ----- Original Message ----- >> From: "Bill Burke" >> To: undertow-dev at lists.jboss.org >> Sent: Friday, 22 January, 2016 11:44:53 AM >> Subject: Re: [undertow-dev] sessionId changes between requests? >> >> Ok, found it. setChangeSessionIdOnLogin() >> >> Can I ask why this is done? Security reasons? To change the cookie? >> If it is to change the cookie, would be really good in the future to >> decouple the session cookie value from the session id so that plugins, >> like Keycloak, that are remotely managing and monitoring sessions can >> still do so without creating a security hole. >> >> On 1/21/2016 6:10 PM, Bill Burke wrote: >>> 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 >> >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sdouglas at redhat.com Fri Jan 22 00:14:41 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 22 Jan 2016 00:14:41 -0500 (EST) Subject: [undertow-dev] sessionId changes between requests? In-Reply-To: <56A1B029.9000307@redhat.com> References: <56A16571.5060304@redhat.com> <56A17B85.7060907@redhat.com> <1681713971.13540920.1453433299249.JavaMail.zimbra@redhat.com> <56A1B029.9000307@redhat.com> Message-ID: <1700011502.13558547.1453439681340.JavaMail.zimbra@redhat.com> Something to be aware of is that in Servlet 3.1 users can also trigger this change by calling javax.servlet.http.HttpServletRequest.changeSessionId(). Not sure if that will also cause issues for you or not. Stuart ----- Original Message ----- > From: "Bill Burke" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Friday, 22 January, 2016 3:29:29 PM > Subject: Re: [undertow-dev] sessionId changes between requests? > > Maybe a decoupling of cookie from session ID isn't very feasible...I > guess I can just turn off the "changeSessionIdOnLogin" switch and change > the ID within the authenticator instead. > > On 1/21/2016 10:28 PM, Stuart Douglas wrote: > > This was done for security reasons (see > > https://issues.jboss.org/browse/UNDERTOW-579). > > > > I don't know how practical it would be to de-couple the cookie value from > > the session ID. Could you just use a > > javax.servlet.http.HttpSessionIdListener to monitor session ID changes? > > > > Stuart > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: undertow-dev at lists.jboss.org > >> Sent: Friday, 22 January, 2016 11:44:53 AM > >> Subject: Re: [undertow-dev] sessionId changes between requests? > >> > >> Ok, found it. setChangeSessionIdOnLogin() > >> > >> Can I ask why this is done? Security reasons? To change the cookie? > >> If it is to change the cookie, would be really good in the future to > >> decouple the session cookie value from the session id so that plugins, > >> like Keycloak, that are remotely managing and monitoring sessions can > >> still do so without creating a security hole. > >> > >> On 1/21/2016 6:10 PM, Bill Burke wrote: > >>> 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 > >> > >> _______________________________________________ > >> undertow-dev mailing list > >> undertow-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/undertow-dev > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > From bburke at redhat.com Fri Jan 22 08:50:30 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 22 Jan 2016 08:50:30 -0500 Subject: [undertow-dev] sessionId changes between requests? In-Reply-To: <1700011502.13558547.1453439681340.JavaMail.zimbra@redhat.com> References: <56A16571.5060304@redhat.com> <56A17B85.7060907@redhat.com> <1681713971.13540920.1453433299249.JavaMail.zimbra@redhat.com> <56A1B029.9000307@redhat.com> <1700011502.13558547.1453439681340.JavaMail.zimbra@redhat.com> Message-ID: <56A233A6.9060804@redhat.com> Is this safe for load balancers and sticky sessions? On 1/22/2016 12:14 AM, Stuart Douglas wrote: > Something to be aware of is that in Servlet 3.1 users can also trigger this change by calling javax.servlet.http.HttpServletRequest.changeSessionId(). > > Not sure if that will also cause issues for you or not. > > Stuart > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stuart Douglas" >> Cc: undertow-dev at lists.jboss.org >> Sent: Friday, 22 January, 2016 3:29:29 PM >> Subject: Re: [undertow-dev] sessionId changes between requests? >> >> Maybe a decoupling of cookie from session ID isn't very feasible...I >> guess I can just turn off the "changeSessionIdOnLogin" switch and change >> the ID within the authenticator instead. >> >> On 1/21/2016 10:28 PM, Stuart Douglas wrote: >>> This was done for security reasons (see >>> https://issues.jboss.org/browse/UNDERTOW-579). >>> >>> I don't know how practical it would be to de-couple the cookie value from >>> the session ID. Could you just use a >>> javax.servlet.http.HttpSessionIdListener to monitor session ID changes? >>> >>> Stuart >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: undertow-dev at lists.jboss.org >>>> Sent: Friday, 22 January, 2016 11:44:53 AM >>>> Subject: Re: [undertow-dev] sessionId changes between requests? >>>> >>>> Ok, found it. setChangeSessionIdOnLogin() >>>> >>>> Can I ask why this is done? Security reasons? To change the cookie? >>>> If it is to change the cookie, would be really good in the future to >>>> decouple the session cookie value from the session id so that plugins, >>>> like Keycloak, that are remotely managing and monitoring sessions can >>>> still do so without creating a security hole. >>>> >>>> On 1/21/2016 6:10 PM, Bill Burke wrote: >>>>> 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 >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sdouglas at redhat.com Fri Jan 22 17:33:54 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Fri, 22 Jan 2016 17:33:54 -0500 (EST) Subject: [undertow-dev] sessionId changes between requests? In-Reply-To: <56A233A6.9060804@redhat.com> References: <56A16571.5060304@redhat.com> <56A17B85.7060907@redhat.com> <1681713971.13540920.1453433299249.JavaMail.zimbra@redhat.com> <56A1B029.9000307@redhat.com> <1700011502.13558547.1453439681340.JavaMail.zimbra@redhat.com> <56A233A6.9060804@redhat.com> Message-ID: <444246571.13877430.1453502034897.JavaMail.zimbra@redhat.com> Yes, at least with the way we implement it. When a session is generated it has the node id appended to the end of the session (so the session ID will look something like ASDGAWG242AF.node1 ). Both sessions will end up with the same node ID in this case. We don't maintain an internal map of session ID -> node id, but even if we did it would still work, because that map should be updated when the new cookie is generated. Stuart ----- Original Message ----- > From: "Bill Burke" > To: "Stuart Douglas" > Cc: undertow-dev at lists.jboss.org > Sent: Saturday, 23 January, 2016 12:50:30 AM > Subject: Re: [undertow-dev] sessionId changes between requests? > > Is this safe for load balancers and sticky sessions? > > On 1/22/2016 12:14 AM, Stuart Douglas wrote: > > Something to be aware of is that in Servlet 3.1 users can also trigger this > > change by calling javax.servlet.http.HttpServletRequest.changeSessionId(). > > > > Not sure if that will also cause issues for you or not. > > > > Stuart > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: "Stuart Douglas" > >> Cc: undertow-dev at lists.jboss.org > >> Sent: Friday, 22 January, 2016 3:29:29 PM > >> Subject: Re: [undertow-dev] sessionId changes between requests? > >> > >> Maybe a decoupling of cookie from session ID isn't very feasible...I > >> guess I can just turn off the "changeSessionIdOnLogin" switch and change > >> the ID within the authenticator instead. > >> > >> On 1/21/2016 10:28 PM, Stuart Douglas wrote: > >>> This was done for security reasons (see > >>> https://issues.jboss.org/browse/UNDERTOW-579). > >>> > >>> I don't know how practical it would be to de-couple the cookie value from > >>> the session ID. Could you just use a > >>> javax.servlet.http.HttpSessionIdListener to monitor session ID changes? > >>> > >>> Stuart > >>> > >>> ----- Original Message ----- > >>>> From: "Bill Burke" > >>>> To: undertow-dev at lists.jboss.org > >>>> Sent: Friday, 22 January, 2016 11:44:53 AM > >>>> Subject: Re: [undertow-dev] sessionId changes between requests? > >>>> > >>>> Ok, found it. setChangeSessionIdOnLogin() > >>>> > >>>> Can I ask why this is done? Security reasons? To change the cookie? > >>>> If it is to change the cookie, would be really good in the future to > >>>> decouple the session cookie value from the session id so that plugins, > >>>> like Keycloak, that are remotely managing and monitoring sessions can > >>>> still do so without creating a security hole. > >>>> > >>>> On 1/21/2016 6:10 PM, Bill Burke wrote: > >>>>> 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 > >>>> > >>>> _______________________________________________ > >>>> undertow-dev mailing list > >>>> undertow-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev > >>>> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > From erhard.siegl at gepardec.com Sun Jan 31 16:04:19 2016 From: erhard.siegl at gepardec.com (Erhard Siegl) Date: Sun, 31 Jan 2016 22:04:19 +0100 Subject: [undertow-dev] Compiling Undertow Message-ID: <2C7903DE-1A8C-4AD6-8F10-6F50EC6C1B63@gepardec.com> 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.(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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160131/a1e1dbbe/attachment-0001.html From erhard.siegl at gepardec.com Sun Jan 31 16:04:19 2016 From: erhard.siegl at gepardec.com (Erhard Siegl) Date: Sun, 31 Jan 2016 22:04:19 +0100 Subject: [undertow-dev] Compiling Undertow Message-ID: <5044E2C4-EF8A-4853-AC40-D6909BA8BAE5@gepardec.com> 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.(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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160131/a6d76448/attachment-0001.html From sdouglas at redhat.com Sun Jan 31 18:01:12 2016 From: sdouglas at redhat.com (Stuart Douglas) Date: Sun, 31 Jan 2016 18:01:12 -0500 (EST) Subject: [undertow-dev] Compiling Undertow In-Reply-To: <5044E2C4-EF8A-4853-AC40-D6909BA8BAE5@gepardec.com> References: <5044E2C4-EF8A-4853-AC40-D6909BA8BAE5@gepardec.com> Message-ID: <1306939645.17426633.1454281272530.JavaMail.zimbra@redhat.com> I think the issue has been fixed now. Basically the problem is that JDK8 does not support ALPN natively, so we need to override the boot class path with an ALPN jar. This jar is tied to the JDK version, and the pom had not been updated with the correct ALPN version for that JVM. Stuart ----- Original Message ----- > From: "Erhard Siegl" > To: undertow-dev at lists.jboss.org > Sent: Monday, 1 February, 2016 8:04:19 AM > Subject: [undertow-dev] Compiling Undertow > > 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.(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 > > _______________________________________________ > undertow-dev mailing list > undertow-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev