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(a)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(a)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(a)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(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/undertow-dev
>