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
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
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.
