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?
