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
9 years, 12 months
Changing headers on proxy response
by Jeff Williams
Hi,
I am currently using a customer handler wrapping the proxy handler. I want
to set some response headers from my handler, but if they exist in the
response from the proxy's backend, they are overridden. Example code:
Undertow.builder()
.addHttpListener(8080, "localhost")
.setHandler(new MyHandler(new ProxyHandler(proxy, 30000,
ResponseCodeHandler.HANDLE_404))).build();
class MyHandler extends HttpHandler {
private static final HttpString ACCESS_CONTROL_EXPOSE_HEADERS = new
HttpString("Access-Control-Expose-Headers");
private HTTPHandler next;
public MyHandler(HttpHandler next) {
this.next = next;
}
public void handleRequest(HttpServerExchange exchange) throws Exception {
exchange.getResponseHeaders().put(ACCESS_CONTROL_EXPOSE_HEADERS, "new
ACEH");
}
}
The problem here is that the backend server responds with an
Access-Control-Expose-Headers header and that replaces the one I set in
MyHandler.
Is there any way I can change headers after proxy has received the response
from backend and before it starts sending the response to the client?
Regards,
Jeff
10 years
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
Undertow with Docker Port issue
by Chris Christo
Hi,
Has anyone managed to get undertow working with docker (on CoreOS)?
I have a very basic jar that starts up an undertow server on (localhost at port 80) and has a single HttpHandler at the endpoint ‘/hello’. I’ve tested the jar locally and the endpoint works fine.
I have a docker file along the lines of:
---------------
FROM dockerfile/java:oracle-java8
## wget the app from a server
CMD java -jar my-app.jar
EXPOSE 80
---------------
I then run the container (after building it from the above docker file) as follows:
docker run -d -p 80:80 my-app
(Yes I made sure the server did start and is running before the following:)
I see that the iptables are as follows (which is identical to what dockerfiles/nginx produces):
---------------
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere 172.17.0.65 tcp dpt:http
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
---------------
Finally I try to curl at the ‘/hello’ endpoint but I just get a connection refused. I try the curl request to localhost from within the same server and it doesn’t work. I also try from a different computer using the public IP of the machine and it does’t work.
The dockerfile/nginx works perfect when I curl at it at port 80.
I’m stumped for ideas, please help!
Thanks,
Chris
10 years
Handling termination of WebSocket connection
by Vladimir Tsukur
Let's imagine user closed browser tab and thus terminated WebSocket
connection. Is there any way to run a callback method on the server-side to
handle this case?
The requirement is to perform necessary cleanup actions when connection is
closed, regardless of the type of disconnect (normal, forced termination,
etc.).
(Ideally using lower level API, and not JSR 356)
--
Vladimir Tsukur
Software Architect, Design Engineer
10 years, 1 month
How to do custom authentication?
by Marc Boorshtein
Undertow team,
I'm trying to integrate our integration with JBoss into Wildfy 8.x. Its a
reverse proxy that generates a token in a header that is then decoded and
the context is set. It works in JBoss 7.x using a combination of a Valve
and a JAAS LoginModule but am struggling to figure out what the replacement
of the Valve would be.
Doing some googling I found
http://undertow.io/documentation/core/security.html but it doesn't point
out how to configure this without writing custom code to add mechanism to
the chain. I found a stacktrace article about setting up a servlet
extension that creates the mechanism, but I don't feel like thats the
*best* solution. When I did the JBoss 7 integration I used PicketLink's
SAML integration as an example but it looks like it isn't yet working for
Wildfly 8.x and won't work until 9?
I know this isn't a JBoss list but my post on the JBoss forums isn't going
anywhere so I thought I'd ask here. If someone could point me to an
example (I usually start with an example of authenticating based on a
username in a header) I'd really appreciate it.
Thanks
Marc Boorshtein
CTO Tremolo Security
marc.boorshtein(a)tremolosecurity.com
<marc.boorshtein(a)tremolosecurity.com>
10 years, 1 month
Response Wrappers
by Jeff Williams
Hi,
I am testing an undertow server for doing on-the-fly encryption (AES CTR)
of responses from a reverse proxy. I have currently implemented this by
implementing a StreamSinkConduit and adding this as a wrapper using
exchange.addResponseWrapper.
I have a few questions:
1) The StreamSinkConduit interface is pretty big and I'm not sure I've
implemented all of it correctly. Is there an easier way? At the end of the
day, I'm really only doing anything interesting in the write method. I've
been looking at the DeflatingStreamSinkConduit, but that is a fair bit more
complex than I need. Is there any documentation about when the different
methods are called?
2) To initialise the cipher, I need some information about the response,
i.e. the offset from the start for Range requests. Currently I intialise
the cipher the first time it is requested (in write) using the response
code and response headers. Is this a reasonable approach?
3) Can you point me towards some information on logging configuration?
Thanks!
Jeff
10 years, 1 month
Undertow forwards too early when handling error page, causing many issues
by arjan tijms
Hi,
Contrary to other servers (Tomcat, JBoss AS 7/EAP 6, GlassFish and
probably all others), Undertow immediately performs a forward when
HttpServletResponse#sendError() is invoked instead of waiting until
all servlets and filters of the application are finished.
In case the error page happens to be a Facelets page, this forward
causes the FacesServlet to be invoked once again, basically creating
another FacesContext inside the same thread. This overrides the
previous FacesContext. After that is released, the "original"
FacesContext is never put back.
In OmniFaces we created a workaround for this, see
https://github.com/omnifaces/omnifaces/commit/b9badb86cb2112fd87485e060db...
Unfortunately, this OmniFaces workaround isn't bulletproof. In case of
an HTTP 400, PrimeFaces loses its RequestContext as well and OmniFaces
can't help setting it back.
This results in exceptions like the following:
java.lang.NullPointerException
at org.primefaces.context.PrimeFacesContext.release(PrimeFacesContext.java:26)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665)
Although not confirmed, this behaviour from Undertow is the likely
cause of a large number of other exceptions as well.
Kind regards,
Arjan Tijms
10 years, 1 month