[undertow-dev] Top level access to servlet request

Bernd Eckenfels ecki at zusammenkunft.net
Mon Jul 11 14:06:09 EDT 2016


Hello,

not directly a answer to your question (doing it in handlers will work,
it is just not very porable) but a comment (if I understood your plan
correctly):

Delaying (failed? flooded?) requests might look like a good thing to do
for security but it only allows attackers to overflow your servers more
easily. Quick closing of connections is a better idea - and in case of
password attempts adding the IP dynamically to a (local) blacklist.

Because even when you have a powerful async server like undertow the
resource consumption of an open tcp socket is enormous (compared to an
attacker with a stateless attack tool or ddos pool).

Gruss
Bernd


 Am Mon, 11 Jul 2016 10:50:10 -0400
schrieb Jack Ding <z29ding at uwaterloo.ca>:

> Hi Stuart,
> 
> Thank you for your response. We have a filter class at the top level
> currently which authenticates and tracks requests and may decide to
> delay a request using AsyncContext's timeout. When implemented at the
> top level before being delegated to a servlet, the
> asynccontext.dispatch will cause the request (after the delay) to
> come back through the same filter class. If it is done after being
> delegated, the dispatch will directly access the resource requested.
> The class will mostly work in the same way if added as an outer
> handler to the servlet context, except that dispatch will directly go
> to the  underlying resource.
> 
> Thanks,
> Jack
> 
> On Sun, Jul 10, 2016 at 8:03 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> 
> > No, in Undertow these are not created until the request has actually
> > been delegated to a Servlet context (as it is possible for requests
> > to not be using Servlet at all).
> >
> > What are you trying to do? There is probably a way to do it using
> > native Undertow handlers.
> >
> > Stuart
> >
> > On Sat, Jul 9, 2016 at 1:59 AM, Jack Ding <z29ding at uwaterloo.ca>
> > wrote:
> > > Hi,
> > >
> > > Is there a method or workaround that would allow the the initial
> > > level Handler (e.g., PathHandler) for an undertow server access
> > HttpServletRequest
> > > and HttpServletResponse? I am trying to switch our server from
> > > Embedded Jetty, in which the initial handler does some processing
> > > using the HttpServletRequest and Response before matching and
> > > delegating to the appropriate ServletContextHandler, however in
> > > Undertow it seems these are not created (via
> > > ServletRequestContext) until after the matching.
> > >
> > >
> > > Thank you,
> > >
> > >
> > > Jack
> > >
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 


More information about the undertow-dev mailing list