You are right! What you did is absolutely fine and supported. I forgot you can simply override SecurityManager instance in shiro.ini. Since you did it that way, everything should work correctly in 2.0
The realmAccessor solution should be the only thing you need. When 2.0.1 is released, ShiroFilter.unwrapSecurityManager() should be exposed as public method. > On Apr 19, 2024, at 12:56 PM, Andrew G10i <[email protected]> wrote: > > Hello, > > thank you so much for you reply! > > Let me please give some clarifications: > > 1) the current code works absolutely fine with Shiro 1.13 as of now; > > 2) as per the question "How did you put pkg.local.MySecurityManager into the > system?" - approach was the following: > ================= > i) in shiro.ini I have the following lines: > securityManager = pkg.local.MySecurityManager > securityManager.realms = $realm1, $realm2, $realm3, ... > > ii) MySecurityManager defined as follows: > public final class MySecurityManager extends DefaultWebSecurityManager { > public MultiTenantWebSecurityManager() { > super(); > // I also override SubjectFactory in it by calling the following > method: > setSubjectFactory(new MySubjectFactory()); > } > ... > } > > iii) thus the code below works just fine: > public static MySecurityManager getSecurityManager() { > return (MySecurityManager) > org.apache.shiro.SecurityUtils.getSecurityManager(); > } > ================= > > I believe that approach I found somewhere in this user group few years ago > when it was first implemented it into my project. > And I got impression that it is one of the ideologies of Shiro to be super > extensible & customizable, thus it looked absolutely fine to have such > implementation (to provide my implementation of Security Manager which > extends the default one, which is anyway used in the system by default). 😉 > > Thank you for the proposed solution - I will try to migrate to it. Any other > ideas based on my additional input above are highly appreciated! > > Thank you! > > > From: lenny > Sent: Friday, April 19, 2024 17:40 > Subject: Re: Trying to migrate Shiro 2 in Jakarta EE - getting > ShiroFilter$WrappedSecurityManager instead of own implementation of Security > Manager > > Hi, > > How did you put pkg.local.MySecurityManager into the system? You might have > bigger issues and this is just a symptom. > In order for Jakarta EE module to work correctly, any customizations need to > be done in a supported way, as described in > https://shiro.apache.org/web.html#custom_webenvironment_class > <https://shiro.apache.org/web.html#custom_webenvironment_class> > And your custom environment class needs to inherit from > org.apache.shiro.ee.listeners.IniEnvironment as describer in > https://shiro.apache.org/jakarta-ee.html > <https://shiro.apache.org/jakarta-ee.html> > > The problem is that this custom security manager isn’t really supported well, > and should be avoided. Currently, the Shiro-EE InitEnvironment class isn’t > really set up return custom SecurityManager. > I would avoid that at all costs if you can. > > To access Realms, in particular, or configuration from shiro.ini in general, > I would do the following: > > - Create @ApplicationScoped @Named RealmAccessor bean > - add setRealms(Collection<Realm>) method (and getter for the same) > > In your shiro.ini, use the following syntax: > realmAccessor = realmAccessor > realmAccessor.realms = securityManager.realms > > > This way, your RealmsAccessor bean will have the values you need from your > configuration, so you can iterate it, > or do whatever needs to be done. > > In the mean time, I have an idea how to make IniEnvironment more flexible > > Another way is to use FormResubmitSupport.unwrapSecurityManager() method. > It’s private (for a good reason) and you would need to use reflection to get > to it. > > Hope this helps.
