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