Re: Enterprise deployments: servicing both web requests and non-web RPC calls simultaneously

[Les Hazlewood <lh...@apache.org>]

Keep in mind that the important thing is not an 'either/or' scenario.  Both
web requests and non-web rpc calls should be handled by the same
SecurityManager.  Its my personal opinion that the required check to ensure
valid configuration is mostly unnecessary - you either use the
JSecurityFilter or not.  If you do, you'll have the request/response pair
automatically bound to the thread.

If you can overlook that point, the only thing remaining is test cases -
where you want to guarantee the test writer has bound the pair to the thread
before running the test.  I don't know if that desire trumps a flexible
SecurityManager - I also have to think about it more for a clean way to have
the best of both worlds...

On Wed, Feb 18, 2009 at 4:25 PM, Jeremy Haile <jh...@fastmail.fm> wrote:

> I like keeping the required check - in HTTP web environments, those would
> highlight a misconfiguration problem.  I'm ok renaming WebRememberMeManager
> to HttpRememberMeManager or something if "web" is too broad.  I really think
> RPC scenarios should be need some sort of different ways of accessing
> things.
>
> That being said, I think our model might could be configured better.  For
> example, rather than configuring a WebRememberMeManager, maybe you should
> just configure a DefaultRememberMeManager that can have a set of accessors
> configured - one could be an RmiRememberMeAccessor and another an
> HttpRememberMeAccessor.  Need to think about it more.
>
>
>
>
> On Feb 18, 2009, at 3:38 PM, Les Hazlewood wrote:
>
>  In web-enabled environments that also service RPC calls
>> (RMI/RMI-over-JMS/SOAP/REST/etc), the DefaultWebSecurityManager and some
>> of
>> its default components (WebRememberMeManager, WebSubjectFactory, etc) use
>> the following calls:
>>
>> WebUtils.getRequiredServletRequest()
>> WebUtils.getRequiredServletResponse()
>>
>> The problem here is if an RPC call comes in and the transport layer is
>> _not_
>> HTTP, there will not be any thread-bound servlet request or response.  In
>> these cases, these calls always throw an IllegalStateException.
>>
>> But the scenario is logical in enterprise installations - where the
>> SecurityManager needs to service both web requests and non-web-based RPC
>> calls simultaneously.  We definitely should support this cleanly.
>>
>> Question:  Should we continue to force the 'required' check?  Or is it OK
>> instead to just check to see if the thread-bound objects are null and
>> assume
>> in these cases the call came in on a non-http remoting invocation?
>>
>> I think I prefer not requiring the thread-bound request/response pair and
>> checking for null.  It is certainly the least impact on the code base.
>>  But
>> this opens up the issue that during test cases, the end-user doesn't need
>> to
>> set up request/response mocks.  If they don't set up req/resp mocks, they
>> wouldn't accurately reflect the web-based environment that would exist for
>> them at runtime when using the JSecurityFilter.
>>
>> What do you think?
>>
>
>