On 14 March 2014 15:59, Dominic Farr <[email protected]> wrote:
> Not sure I fully understand your "component-based configuration system", so
> can you include your configuration at least?
The INI configuration is uninteresting - a [urls] section setting up
permissions mapped to urls.
The component-based config is complex to explain, but could be reduced
to the following actual java class (using psuedo code rather than real
code):
public void initSystem() {
// bits I am happy with
MyUserDAO dao = ...
MyUserRealm realm = new MyUserRealm(dao);
SecurityManager sm = new DefaultWebSecurityManager(realm);
SecurityUtils.setSecurityManager(sm);
// bit that goes wrong
Jetty jetty = new EmbeddedJetty();
}
It goes wrong because embedded jetty reads web.xml and web.xml
includes EnvironmentLoaderListener, and that starts its own
SecurityManager. I want it to re-use the static one from
SecurityUtils.
> On PasswordMatcher question, I'm assuming you mean
> https://shiro.apache.org/static/1.2.2/apidocs/org/apache/shiro/authc/credential/PasswordMatcher.html
> Shiro uses setter inject over constructor. I think because that is how ini
> works. On this class there are get/set PasswordService.
Yes I mean that PasswordMatcher. Not everyone uses the INI format for
everything. I'm creating an instanceof PasswordMatcher
programmatically, and it is a (minor) pain because it needs three
lines instead of one (in order to call the setter). I would consider
it good practice for Shiro to provide for setting common elements via
the constructor as well as via setters, particularly when the
PasswordService is the only setter and it is mandatory!
Stephen
> On 14 March 2014 15:45, Stephen Colebourne <[email protected]> wrote:
>>
>> Hi Shiro team,
>> I am currently integrating Shiro into our application.
>>
>> We have our own component-based configuration system which needs to
>> operate as follows:
>> - start user database component
>> - start Shiro PasswordService component
>> - start Shiro SeurityManager component
>> - start embedded Jetty web server
>>
>> I can quite happily perform the first three steps, but when I start
>> the web server it currently reads a Shiro INI file in
>> IniWebEnvironment and sets up a second SecurityManager. Instead, I
>> want the existing static SecurityManager to be used. (I want to
>> continue using the INI file to setup the filters from the [main] and
>> [urls] section).
>>
>> Have I missed something, or do I just have to hack around with the
>> WebEnvironment to write a subclass that re-uses the static
>> SecurityManager?
>>
>> In the embedded Jetty scenario, I think most users would want to
>> re-use a static SecurityManager that has been separately created.
>>
>> Also, as a detail, PasswordMatcher could really do with an additional
>> constructor that takes the PasswordService.
>>
>> thanks
>> Stephen
>
>
