[undertow-dev] Top level access to servlet request

[Stuart Douglas]

While I agree with Bernd that this is not necessarily the best
approach you can also implement this in Undertow quite easily,
something like:

public class DelayHandler implements HttpHandler {

    @Override
    public void handleRequest(HttpServerExchange exchange) throws Exception {
        boolean delay = doStuff();
        if(delay) {
            exchange.getIoThread().executeAfter(new Runnable() {
                @Override
                public void run() {
                    exchange.dispatch(DelayHandler.this);
                }
            }, 30, TimeUnit.SECONDS);
            exchange.dispatch();
            return;
        }
        next.handleRequest();
    }
}

Stuart


On Tue, Jul 12, 2016 at 4:06 AM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
> 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
>> >
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev