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
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, 1 month
Tracing HTTP Response content
by Matt Clarkson
Hi,
I'd like to be able to dump Response content as a string to my logger when
tracing. I'm guessing something related to
HttpServerExchange.getResponseChannel()... but not sure where to go from
there.
thanks!
Matt
10 years, 3 months
Could not handle the same URL to GET and POST with RoutingHandler
by Miere Teixeira
Hi Devs,
I'm facing a new situation with RoutingHandler. I have two HttpHandler's,
one responsible to retrieve all users registered in my database. The second
one is responsible to include an user into my database.
Both handler was registered with RoutingHandler, both registered with
'/users/' URL but the first one registered for GET and the second for POST.
After upgrade to 1.1.0.Beta7 version, this behavior was broken and throws
the exception described bellow.
I've made this simple unit test that simulates the same error when running
in 1.1.0.Beta7, but works perfectly in 1.1.0.Beta6.
https://gist.github.com/miere/3ef15b916cdaaae1896c
Let me know if it is a bug or the wrong way to achieve this goal. Also, let
me know if I could in some way.
Miere
--
java.lang.IllegalStateException: UT000071: Cannot add path template
/sameurl, matcher already contains an equivalent pattern /sameurl
at
io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:112)
at
io.undertow.util.PathTemplateMatcher.add(PathTemplateMatcher.java:148)
at io.undertow.server.RoutingHandler.add(RoutingHandler.java:112)
at io.undertow.server.RoutingHandler.add(RoutingHandler.java:99)
at
kikaha.core.RoutingHandlerTest.ensureItsPossibleToHandlePostAndGetToSameURL(RoutingHandlerTest.java:16)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
10 years, 3 months
How do I handle HTTP Methods in Undertow?
by Luke Ambrogio
So I've decided to start using Undertow, both as an experiment and due to
the great results it achieved in benchmark tests. And while I think it's
fantastic there's a feature which is either missing or I can't find.
I want to develop a RESTful web service so it's important for me to
identify which HTTP method is being called. Now I can get this from
RequestMethod in the HttpServerExchange parameter but if had to that for
every handler that would become tedious.
My solution, which works but feels wrong, is this:
Created an annotation interface called HTTPMethod:
@Retention(RetentionPolicy.RUNTIME)(a)Target(ElementType.METHOD) public
@interface HTTPMethod {
public enum Method {
OTHER, GET, PUT, POST, DELETE}
Method method() default Method.OTHER;
an "abstract" class (which is not abstract):
public abstract class RESTfulHandler implements HttpHandler {
@Overridepublic void handleRequest(HttpServerExchange hse) throws Exception {
for (Method method : this.getClass().getDeclaredMethods()) {
// if method is annotated with @Test
if (method.isAnnotationPresent(HTTPMethod.class)) {
Annotation annotation = method.getAnnotation(HTTPMethod.class);
HTTPMethod test = (HTTPMethod) annotation;
switch (test.method()) {
case PUT:
if (hse.getRequestMethod().toString().equals("PUT")) {
method.invoke(this);
}
break;
case POST:
if (hse.getRequestMethod().toString().equals("POST")) {
method.invoke(this);
}
break;
case GET:
if (hse.getRequestMethod().toString().equals("GET")) {
method.invoke(this);
}
break;
case DELETE:
if (hse.getRequestMethod().toString().equals("DELETE")) {
method.invoke(this);
}
break;
case OTHER:
if (hse.getRequestMethod().toString().equals("OTHER")) {
method.invoke(this);
}
break;
}
if (test.method() == HTTPMethod.Method.PUT) {
method.invoke(this);
}
}
}}
}
and an implementation of both the above:
public class ItemHandler extends RESTfulHandler{
@HTTPMethod(method=GET)public void getAllItems(){
System.out.println("GET");}
@HTTPMethod(method=POST)public void addItem(){
System.out.println("POST"); }
@HTTPMethodpublic void doNothing(){
System.out.println("OTHERS"); }
}
Now as I said, it works, but I'm sure that the abstract class and it's
implementation have something missing so that they glue correctly. So my
question is two fold:
1) Is there a better / proper way to filter HTTP requests in Undertow? 2)
What is the correct way of using annotations correctly correctly in the
above case?
Thanks
10 years, 3 months
Undertow versioning
by Stuart Douglas
Hi all,
Soon I am going to create a 1.1 branch, and move master to 1.2. Wildfly
8.2 is due for release soon and I would like it to use 1.1, however I am
not comfortable having our new and fairly untested mod_cluster load
balancer (i.e. frontend) and HTTP2 code in a final release, as this code
is still very much under development.
These features will be removed from the 1.1 branch, and 1.1 final should
be released soon, while development on these features will continue in
the 1.2 branch.
Stuart
10 years, 3 months
single-sign-on and reauthenticate=false
by Mattias Nilsson Grip
Hi,
I see in a commit message from February "Drop superfluous re-authenticate attribute of <single-sign-on/>."
Looks like re-authenticate=true is still the default behaviour? In previous JBoss versions it was possible to use re-authenticate=false to do single-sign-on for two web applications in different security domains without the need to reauthenticate. What is the proper way to do that now? Should we configure an identity provider?
Regards,
Mattias
10 years, 3 months
undertow http client - howto long polling xhr?
by Brian Clozel
Hi,
I'd like to build an HTTP client that receives chunks of data as part of a
long polling HTTP request, using Undertow's HTTP client. So in a way, I'd
need callback methods like "onHeader" and "onContent".
>From what I read in UndertowClient and HttpClientConnection, it looks like
the http client is parsing the *whole* HTTP response and does not provide
those callbacks.
Is there a way to achieve this?
If not, does this qualify as an interesting feature for undertow's HTTP
client?
Thanks,
--
Brian Clozel
10 years, 3 months
Dispatching to non IO threads
by Bill O'Neil
I have come across a few Handlers that dispatch to a worker thread these
include blocking handler, resource handler and the form parsing handler.
My specific use case was with the form parsing handler. I had a bunch of
handlers chained together basically as follows.
Blocking handler -> ExceptionHandler -> FormParsingHandler ->
MyBlockingHandler
The form parsing handler would cause the handler to be dispatched a second
time to a new executor. This made me lose the stack trace, and the
Exception handler was not catching an exception being thrown inside of
MyBlockingHandler.
I resolved this by basically cloning the form parsing handler and calling
the parseBlocking() instead of the non blocking parse(). This is
acceptable because I already dispatched to a non IO thread.
Should any handler that attempts to dispatch first check if the exchange is
in an IO thread before dispatching or is there a specific use case for some
handlers to always dispatch?
Thanks,
Bill
10 years, 3 months
