For a few reasons:
  1. I'd have to insulate the resource handler and directly call it from the authenticated resource (so that someone couldn't call the modified path and get the resource bypassing security). Though that wouldn't be terrible, it adds an additional stage in the process where I'd like to handle everything at once.
  2. In my specific use-case the security validation will be hitting the database so I'd prefer it not occur on the IO thread anyway.
  3. I'm working towards a more simplistic mapping of (path: String) => Option[Resource] to allow some paths to have different handling based on the context or state of the server and add modularity in so much as they don't need to know about each other.
  4. It didn't occur to me until after I had almost finished writing it. :)
It doesn't seem Undertow has a convenient capability to just serve up a File easily.  That would be very useful for explicit files with explicit mappings without requiring a ResourceManager.

On Tue, Aug 30, 2016 at 7:57 PM Stuart Douglas <sdouglas@redhat.com> wrote:
Why can't you just add a handler before the resource handler to modify
the path and verify the user is authenticated?

Stuart

On Wed, Aug 31, 2016 at 10:36 AM, Hicks, Matt <matt@matthicks.com> wrote:
> That's unfortunate, so I completely translated ResourceHandler into Scala to
> be able to add the functionality I need:
>
> https://github.com/outr/hyperscala/blob/master/core/jvm/src/main/scala/org/hyperscala/FunctionalResourceManager.scala#L125
>
> It's not the ideal solution, but it does work.  I still need to do some
> cleanup as well, but a simple mechanism to allow some overrides or some
> separation of this massive block of logic into modular utilities would make
> Undertow far easier to customize.
>
> On Tue, Aug 30, 2016 at 6:03 PM Stuart Douglas <sdouglas@redhat.com> wrote:
>>
>> The ResourceManager interface was not expected to be able to handle
>> that, you should probably do that in a handler before the resource
>> manager is invoked.
>>
>> Stuart
>>
>> On Wed, Aug 31, 2016 at 6:11 AM, Hicks, Matt <matt@matthicks.com> wrote:
>> > Thanks Stuart, that did the trick.
>> >
>> > I'm extending FileResourceManager to convert from the web path to an
>> > internal storage path and also trying to validation against the session
>> > to
>> > verify the logged-in state.  However, I'm running into a roadblock
>> > because
>> > `getResource` doesn't have access to the exchange to be able to get the
>> > cookie value.  I tried using ThreadLocal, but it's dispatched to another
>> > thread so that won't work either.  How am I supposed to access a cookie
>> > or
>> > session from within a ResourceManager.getResource?
>> >
>> > On Mon, Aug 29, 2016 at 8:05 PM Stuart Douglas <sdouglas@redhat.com>
>> > wrote:
>> >>
>> >> For servlet or Undertow native?
>> >>
>> >> For native it is controlled by the
>> >> io.undertow.server.session.SessionCookieConfig implementation that is
>> >> passed to the session manager.
>> >>
>> >> For Servlet the standard way to do it is to use a
>> >> ServletContextListener to modify the domain under
>> >> javax.servlet.ServletContext#getSessionCookieConfig
>> >>
>> >> Stuart
>> >>
>> >> On Fri, Aug 26, 2016 at 11:31 PM, Hicks, Matt <matt@matthicks.com>
>> >> wrote:
>> >> > I can't seem to figure out any way to configure the session manager
>> >> > to
>> >> > define the domain of the cookie.  I want the domain to be
>> >> > *.mydomain.com
>> >> > so
>> >> > the cookie is shared across multiple sub-domains.  Can someone give
>> >> > me
>> >> > an
>> >> > example of how to do this?
>> >> >
>> >> > Thanks
>> >> >
>> >> > _______________________________________________
>> >> > undertow-dev mailing list
>> >> > undertow-dev@lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev