Hi, Alex, I have been using Shiro for about 6 years, so let me give you some perspective from “user’s” side. Shiro’s APIs are indeed “older” style, but they are perfectly fine and work perfectly well in today’s modern code. There is no need to “redesign” APIs as you are trying to do. I believe that as you use Shiro more, you will understand more concepts and your desire to redesign Shiro will deminish.
From what I can see, you “original” problem is to invalidate sessions when something change in a database. This is wrong, unnecessary, and impossible in Shiro. However, there is a perfectly good method to do this, and it works well in my application. All you need to do is to clear the cache of the invalidated user, and that user no longer will have any role or permission. In my application, what happens if the user is “deleted” is that every page access will result in “permission denied” page, so, even though the user still has a web session, their permissions are all removed and they will no longer ave any access, which will accomplish what I believe is to be your task. > On Nov 7, 2020, at 12:50 AM, Alex Orlov <[email protected]> wrote: > > Hi all, > > Trying to I get the list of all logged in subjects I found this method : > SessionDAO#Collection<Session> getActiveSessions() > and want to use it. > > And I have two questions: > > 1) Why does API hide top level objects for which we have interfaces? > For example, using SecurityUtils we can get SecurityManager, however, > SecurityManager doesn’t let get SessionManager, SessionDAO etc. > So, we can’t do > SecurityUtils.getSecurityManager().getSessionManager().getSessionDAO()? > It seems to be unusual for me. Besides it is possible to set them via ini: > > sessionManager = com.foo.my.SessionManagerImplementation > securityManager.sessionManager = $sessionManage > > sessionManager = org.apache.shiro.web.session.mgt.DefaultWebSessionManager > securityManager.sessionManager = $sessionManager > # Configure a SessionDAO and then set it: > securityManager.sessionManager.sessionDAO = $sessionDAO > > So, we can configure them statically, but not dynamically. At least, we must > be able to get them > at runtime. Maybe it is necessary to change API to make it more flexible? > > 2) Why does SecurityManager extend SessionManager? > As I understand SecurityManager has a SessionManager, but not is a > SessionManager: > > public interface SecurityManager extends Authenticator, Authorizer, > SessionManager > > Could anyone explain? > > > -- > Best regards, Alex Orlov
