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 <[email protected]> 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? >> > >
