Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
thread-topic: [jira] [Created] (SHIRO-287) Enable web-configured
 SecurityManager to be statically accessible for non-request threads
thread-index: AcwAHTGdPVuK/G0xSlKyZ1+rPw0Hmg==
Date: Thu, 21 Apr 2011 07:11:02 -0500
Subject: Re: [jira] [Created] (SHIRO-287) Enable web-configured
 SecurityManager to be statically accessible for non-request threads
Message-ID: <557901cc001d$319d46fc$aa19000a@mse8.exchange.ms>
From: "Jared Bunting" <jared.bunting@digitalreasoning.com>
To: <dev@shiro.apache.org>

Seems to me it should be enabled by default.  Correct me if I'm wrong but
wouldn't this only conflict between webapps if shiro was loaded from a
shared classloader such as can occur with ear deployments (or if shiro is
put in the server classpath)?  And since I see the scenario mentioned
previously as a rare case, this should seldom cause a problem.  Another
option for the multiple webapp case is to store it as an application-level
attribute.

-Jared

Les Hazlewood <lhazlewood@apache.org> wrote:

Hi Jared,

It wil definitely be configurable, but typically because there might
be more than one Shiro-enabled web app in a single JVM (it'd be odd
for a single app to have more than one Shiro SecurityManager).  Right
now in my local dev environment, it is disabled by default.

But what is the 80/20 rule here?  Should it be enabled by default,
with the option to turn it off?  Or keep it disabled by default (as it
is now), and expect people to manually turn it on?

Shiro's general premise is to make things as easy as possible.  Will
more people expect it to 'just work' without having to specify this
extra config option?  Or will more people be running more than one
Shiro-enabled web app in the same JVM?

Thoughts?

HTH,

Les

On Wed, Apr 20, 2011 at 7:24 PM, Jared Bunting
<jared.bunting@digitalreasoning.com> wrote:
> Les,
>
> Will this be disableable via an option on the filter?  I can see where a
> webapp with more than one shiro filter / security manager would cause a
> problem with this.
>
> -Jared
>
> "Les Hazlewood (JIRA)" <jira@apache.org> wrote:
>
> Enable web-configured SecurityManager to be statically accessible for
> non-request threads
> ------------------------------------------------------------------------
--
> ---------------
>
>                 Key: SHIRO-287
>                 URL: https://issues.apache.org/jira/browse/SHIRO-287
>             Project: Shiro
>          Issue Type: New Feature
>            Reporter: Les Hazlewood
>            Assignee: Les Hazlewood
>             Fix For: 1.2.0
>
>
> For any work done on threads that are not triggered by a request thread,
> the SecurityManager should be accessible to these threads so the
> Subject.Builder can be used properly.
>
> This can be accomplished by setting the configured SecurityManager as a
> static member variable in SecurityUtils (via
> SecurityUtils.setSubjectManager).  While static memory is not ideal, it
is
> probably good enough for 90% of web applications, and can be a viable
> solution.
>
> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see:
http://www.atlassian.com/software/jira