Hi Thibault,
You can get access to the Shiro WebEnvironment (and everything that it
contains, like the SecurityManager, FilterChainManager and any other
configured objects) by doing the following:
ServletContext servletContext = //get your webapp's ServletContext
WebEnvironment webEnvironment =
WebUtils.getRequiredWebEnvironment(servletContext);
WebSecurityManager webSecurityManager = webEnvironment.getWebSecurityManager();
If you want to get objects that were configured in the [main] section,
you can check:
if (webEnvironment instanceof NamedObjectEnvironment) {
NamedObjectEnvironment env = (NamedObjectEnvironment)webEnvironment;
MyBean bean = env.getObject("mainSectionBeanName", MyBean.class);
}
Note that this API is only available in Shiro 1.2 (in the current
trunk snapshots)
Cheers,
--
Les Hazlewood
CTO, Katasoft | http://www.katasoft.com | 888.391.5282
twitter: @lhazlewood | http://twitter.com/lhazlewood
katasoft blog: http://www.katasoft.com/blogs/lhazlewood
personal blog: http://leshazlewood.com
On Wed, Jan 4, 2012 at 12:28 AM, Thibault TIGEON
<[email protected]> wrote:
> Hi HTM,
>
> Thanks for your answer.
> You said that SM is avalable in the memory heap, but how web framework can
> access to this SM and why it is never call for the memory heap by framework
> web?
> For instance if I want to reproduce this behavior in a CDI environment how
> can i do?
>
> Regards,
>
> Thibault
>
>
> 2012/1/3 Les Hazlewood <[email protected]>
>>
>> Hi Thibault,
>>
>> This method is always available. It would be a new feature request to
>> prevent this from being available (please create a new Jira issue if
>> you think this should be a feature).
>>
>> That being said, it should be noted that Shiro's primary purpose is to
>> 1) be easy to use and understand and to 2) protect the application
>> from the end-user and/or attack vectors. Shiro does not often make
>> attempts to protect the application code from the developer (since
>> they can just ignore Shiro's APIs entirely if they wanted, thereby
>> subverting any security at all).
>>
>> Also note that SecurityUtils.setSecurityManager should only ever be
>> called if an application's default configuration mechanism does not
>> provide a better alternative. For example, Tapestry, Spring, Guice
>> and Shiro web environments all never need to call
>> SecurityUtils.getSecurityManager() because the SM instance is always
>> easily accessible from heap memory via other method calls. Avoid
>> static memory if you can and use SecurityUtils.setSecurityManager only
>> when you can't avoid it.
>>
>> But again, if you feel this should be a feature, please file a Jira
>> issue and we can discuss.
>>
>> HTH,
>>
>> --
>> Les Hazlewood
>> CTO, Katasoft | http://www.katasoft.com | 888.391.5282
>> twitter: @lhazlewood | http://twitter.com/lhazlewood
>> katasoft blog: http://www.katasoft.com/blogs/lhazlewood
>> personal blog: http://leshazlewood.com
>>
>> On Tue, Jan 3, 2012 at 4:07 AM, Thibault TIGEON
>> <[email protected]> wrote:
>> > Hi,
>> >
>> > how to prevent the application to override the securitymanager at
>> > runtime?
>> >
>> > It seems SecurityUtils.setSecurityManager is always available.
>> >
>> > Is there any way to do a kind of "only startup configuration"?
>> >
>> > Regards,
>> >
>> > Thibault
