July 2014 - undertow-dev - Jboss List Archives

JSESSIONID cookie path empty for root deployments

by arjan tijms

Hi, For a root deployment, Undertow by default writes the JSESSIONID cookie with an empty path. I.e. in the response header the following appears: SET-COOKIE: JSESSIONID=FhgSh... path=; ... An empty path causes browsers to set the cookie on whatever path was used for the request URI. In effect, this causes multiple JSESSIONIDs to be created while browsing through an app deployed to WildFly, and thus multiple JSESSIONIDs being posted back when other paths are accessed (leading to many issues). The cause of this seems to be in io.undertow.servlet.spec.ServletContextImpl#ServletContextImpl and io.undertow.servlet.core.DeploymentManagerImpl#handleDeploymentSessionConfig, where the cookie path is set to deploymentInfo#getContextPath, which in both cases returns the empty string. See: io.undertow.servlet.spec.ServletContextImpl.ServletContextImpl(ServletContainer, Deployment) sessionCookieConfig = new SessionCookieConfigImpl(this); sessionCookieConfig.setPath(deploymentInfo.getContextPath()); and: io.undertow.servlet.core.DeploymentManagerImpl.handleDeploymentSessionConfig(DeploymentInfo, ServletContextImpl) if(sc.getPath() != null) { sessionCookieConfig.setPath(sc.getPath()); } else { sessionCookieConfig.setPath(deploymentInfo.getContextPath()); } I'm not sure if deploymentInfo#getContextPath should indeed return the empty string for a root deployment or not, but I think setting the cookie path to the empty string is not really correct and should be "/" in that case. Kind regards, Arjan Tijms

10 years, 1 month

2
2
0 / 0

CAS / OAuth / OpenID / HTTP / SAML client protocol support?

by Michaël REMOND

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

10 years, 2 months

4
7
0 / 0

Can we please have a notification scheme enabled for Undertow Jira?

by Darran Lofthouse

Can we please have a notification scheme enabling for the Undertow Jira project so that we can receive e-mail notifications. I would suggest just use the same one as is used for Remoting JMX, it should be sufficient to have the notifications go to the general mailing list and interested individuals. Regards, Darran Lofthouse.

10 years, 4 months

3
6
0 / 0

Make Credential on IdentityManager be a generic parameter

by Miere Teixeira

Hi devs, how you doing? I was checking out the security API proposed by Undertow and I've identified that io.undertow.security.idm.IdentityManager receive an empty credential as parameter in two of its methods. After taking a look into the Java Docs and the exemple codes I figure out why. As proposed in the original design, an IdentityManager should know which kind of credential was created by the AuthenticationMechanism, cast it, and then apply the desired identity match. It means that there's an existance relation between both IdentityManager and AuthenticationMechanism. Maybe, making Credential a generic parameter of IdentityManager it will make IdentityManager more plugable. It also forces us the improve SecurityContext with this new design. A little sample copied from BasicAuthenticationMechanism.java[106~110] as an exemple. final IdentityManager<PasswordCredential> idm = > securityContext.getIdentityManagerFor( PasswordCredential.class ); > final PasswordCredential credential = new PasswordCredential(password); > try { > final AuthenticationMechanismOutcome result; > Account account = idm.verify(userName, credential); > Let me know if this makes sense for Undertow needs! Regards

10 years, 5 months

2
2
0 / 0

LoadBalancingProxyClient extensions

by ralf_boogie_blues＠bluewin.ch

Hi Undertow Developers I am playing a little bit with the LoadBalancingProxyClient feature in Undertow. I am looking for a solution that replaces my implementation of a load balancer, which is based on Apache HttpClient. The LoadBalancingProxyClient fulfills almost the functionality I need. Do you have a plan for these two features? To make tho host selection configurable. Currently, it is a static round robin strategy. I think this is a simple task and I was able to change the code so that this host selection is configurable. The second feature is much more difficult for me to solve. I need a failover to the next host also in case the backend server responds with say a status code 503. The backend servers are based on the clustered HA singleton pattern, meaning, there is one backend server which is the master node. The other backend servers are up but shouldn't get http request. If the inactive servers get a call, then they will respond with 503. We use Wildfly for front and backend servers. It would really cool to reuse all the undertow power:-) Let me know what you think. I am certainly offer to help for whatever you need. Testing for example. Regards, Ralf

10 years, 5 months

2
2
0 / 0

NPE in JASPIAuthenticationMechanism when using async requests

by arjan tijms

Hi, When using a basic async servlet, where the request processing is transferred to an @Asynchronous method, there's a NPE at the end of the request: Exception in thread "default task-107" java.lang.NullPointerException at org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.wasAuthExceptionThrown(JASPIAuthenticationMechanism.java:164) at org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism.access$100(JASPIAuthenticationMechanism.java:72) at org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:240) at org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism$1.wrap(JASPIAuthenticationMechanism.java:234) at io.undertow.server.HttpServerExchange$WrapperStreamSinkConduitFactory.create(HttpServerExchange.java:2017) at io.undertow.server.HttpServerExchange.getResponseChannel(HttpServerExchange.java:1167) at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:619) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432) The direct cause is that JASPIAuthenticationMechanism#wasAuthExceptionThrown tries to access the security context as-in the following line: SecurityContextAssociation.getSecurityContext().getData().get(AuthException.class.getName()) != null Only, for an async request processing thread SecurityContextAssociation.getSecurityContext() is always null, causing the NPE. I created a test that functions as a reproducer here: https://github.com/arjantijms/javaee7-samples/tree/master/jaspic/async-au... It also looks like there's something not entirely right with the async time out on Undertow, but I haven't nailed that one down yet. Kind regards, Arjan

10 years, 5 months

2
2
0 / 0

Undertow extensions library?

by Bill O'Neil

Is there any plan to open up an undertow-ext library where the community can make small modules that hook into 3rd party dependencies? For example, an HttpHandler that uses Jackson/Gson to serialize to json and set appropriate headers, or an HTML templating framework for rendering HTML. Would you prefer these to be hosted by 3rd parties instead? Thanks, Bill

10 years, 5 months

3
5
0 / 0

GZIP Compression

by Tom Goldsmith

Hi there, I am wondering what the most idiomatic way to enable GZIP compression is in the current version of immutant. We could add a config to the WAR file we are deploying but I'm curious if there is another way of enabling GZIP either through code or just with the use of a header. Thanks! Tom

10 years, 5 months

2
1
0 / 0

JDK6 Support

by Jakub Bartecek

I am responding to discussion about JDK6 support. I prepared integration of Undertow into Jenkins CI and the community just considering it, but for the community is important compatibility with JDK6. Is it possible to keep Undertow on JDK6? Jakub Bartecek > The recent report from JRebel Labs that surveyed developers said that > majority of the developers are > already on JDK7 with a small footprint for JDK6. > > >> On 06/11/2014 10:24 AM, Stuart Douglas wrote: >>/ Given that no one replied we have now moved to JDK7. />>/ />/> Stuart />>/ />>/> Jason Greene wrote: />>>/ Is there anyone using undertow on JDK6, and cares that we continue to support it? We are considering dropping it. />>>/ />>>/ -- />>>/ Jason T. Greene />>>/ WildFly Lead / JBoss EAP Platform Architect />>>/ JBoss, a division of Red Hat />>>/ />>>

10 years, 6 months

5
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

undertow-dev July 2014