You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Alex Orlov <oo...@mail.ru> on 2020/11/07 06:50:39 UTC
Some questions about Shiro API
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
Re: Some questions about Shiro API
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
You got me,
I understand nothing.
You are right, I am wrong,
> On Nov 9, 2020, at 1:40 AM, Alex Orlov <oo...@mail.ru> wrote:
>
> Hi Lenny,
>
> It seems, that you simply don’t understand many things:
>
> 1) You don’t understand what is API and why API is used instead of implementation by library users.
> 2) You don’t understand, when some user suggests improvements, not only he, but all users will
> take advantages of them.
> 3) You don’t understand, that bad API is not only one user’s problem, but all users. For example,
> consider this https://stackoverflow.com/questions/22826922/how-to-close-shiro-session <https://stackoverflow.com/questions/22826922/how-to-close-shiro-session> QA that
> was viewed 7k times.
>
> I am writing all these just to show, that you are wrong, but not to explain you what is black and what is white.
> It is up to you. That’s why this is my last message to you.
>
> Best regards, Alex
Re[5]: Some questions about Shiro API
Posted by Alex Orlov <oo...@mail.ru>.
Hi Lenny,
It seems, that you simply don’t understand many things:
1) You don’t understand what is API and why API is used instead of implementation by library users.
2) You don’t understand, when some user suggests improvements, not only he, but all users will
take advantages of them.
3) You don’t understand, that bad API is not only one user’s problem, but all users. For example,
consider this https://stackoverflow.com/questions/22826922/how-to-close-shiro-session QA that
was viewed 7k times.
I am writing all these just to show, that you are wrong, but not to explain you what is black and what is white.
It is up to you. That’s why this is my last message to you.
Best regards, Alex
Re: Some questions about Shiro API
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Again, it’s not as black and white as you think.
Not everything is perfect, nothing is, and nothing ever will be.
Yes, Shiro APIs are a bit old-fashioned, but they work perfectly, understandable
and productive.
Trust me, as you rework your problems “in terms of Shiro design” your desire for casts will largely disappear.
I believe you are trying to use objects in your code that you are mostly do not need to.
> On Nov 8, 2020, at 4:24 AM, Alex Orlov <oo...@mail.ru> wrote:
>
> Hi Andreas,
>
> I am just a Shiro user and this is Shiro user mailing list. I fulfilled my duties — opened an issue and gave explanations.
> I develop my projects, Shiro developers develop Shiro. I just can’t develop any library I use in my projects ( > 30) — because
> to do it I must give up my projects.
>
> The idea of my message wasn’t "Change the API because anyway you have nothing to do". The idea of my message
> was — "Don’t call a wrong thing a right thing".
>
>
> --
> Best regards, Alex Orlov
>
>
> Воскресенье, 8 ноября 2020, 12:54 +03:00 от Andreas Reichel <an...@manticore-projects.com>:
>
> Dear Alex.
>
>
> On Sun, 2020-11-08 at 12:47 +0300, Alex Orlov wrote:
>> So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
>> or API is not flexible enough.
>
>
> Sometimes it may mean: it works perfectly fine as it is and the people have more relevant stuff to do.
> Look at Hurd: perfect in theory, unusable in practise. Look at the Linux kernel. Far away from being perfect or clean, but runs impressively well and reliable.
>
> That said: your best argument might be a pull request, which demonstrates the improvement you have in mind. I am sure, the Shiro developpers would merge it when the advantage of the refactoring is obvious.
>
> Best regards
> Andreas
>
Re[4]: Some questions about Shiro API
Posted by Alex Orlov <oo...@mail.ru>.
Hi Andreas,
I am just a Shiro user and this is Shiro user mailing list. I fulfilled my duties — opened an issue and gave explanations.
I develop my projects, Shiro developers develop Shiro. I just can’t develop any library I use in my projects ( > 30) — because
to do it I must give up my projects.
The idea of my message wasn’t "Change the API because anyway you have nothing to do". The idea of my message
was — "Don’t call a wrong thing a right thing".
--
Best regards, Alex Orlov
>Воскресенье, 8 ноября 2020, 12:54 +03:00 от Andreas Reichel <an...@manticore-projects.com>:
>
>Dear Alex.
>
>
>On Sun, 2020-11-08 at 12:47 +0300, Alex Orlov wrote:
>>So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
>>or API is not flexible enough.
>
>Sometimes it may mean: it works perfectly fine as it is and the people have more relevant stuff to do.
>Look at Hurd: perfect in theory, unusable in practise. Look at the Linux kernel. Far away from being perfect or clean, but runs impressively well and reliable.
>
>That said: your best argument might be a pull request, which demonstrates the improvement you have in mind. I am sure, the Shiro developpers would merge it when the advantage of the refactoring is obvious.
>
>Best regards
>Andreas
Re: Re[2]: Some questions about Shiro API
Posted by Andreas Reichel <an...@manticore-projects.com>.
Dear Alex.
On Sun, 2020-11-08 at 12:47 +0300, Alex Orlov wrote:
> So, when you do FooImpl impl = (FooImpl) foo; it means that either
> you are doing something wrong,
> or API is not flexible enough.
Sometimes it may mean: it works perfectly fine as it is and the people
have more relevant stuff to do.
Look at Hurd: perfect in theory, unusable in practise. Look at the
Linux kernel. Far away from being perfect or clean, but runs
impressively well and reliable.
That said: your best argument might be a pull request, which
demonstrates the improvement you have in mind. I am sure, the Shiro
developpers would merge it when the advantage of the refactoring is
obvious.
Best regards
Andreas
Re: Some questions about Shiro API
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
“simply unacceptable” is so black&white :)
The reality is that people used Shiro for decades, and it was acceptable for all of those people and all this time.
Simple fact is that no one is going to redesign Shiro APIs for you.
Either you need to do a PR, and convince the maintainers it’s useful, or,
use Shiro, or, or don’t use it.
That is a fact.
> On Nov 8, 2020, at 3:47 AM, Alex Orlov <oo...@mail.ru> wrote:
>
> Hi Lenny,
>
> I have casts, you have casts, Bob and Mike also have casts. It doesn’t matter how many casts
> you have, you mustn’t have any.
>
> In modern SO development approach we use only API and shouldn’t know anything about implementations
> classes. I’m sure that you know about OSGI, JPMS etc. The main idea of such systems is to completely hide
> implementation classes. You event don’t see those implementation classes, so, you just CAN’T use them!
>
> So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
> or API is not flexible enough.
>
> So, I can’t accept your advice because it is simply unacceptable.
>
>
> --
> Best regards, Alex Orlov
>
>
> Суббота, 7 ноября 2020, 23:37 +03:00 от Lenny Primak <lp...@hope.nyc.ny.us>:
>
> Oh and I have very few “casts” that are necessary to accomplish any of this
>
> > On Nov 7, 2020, at 12:50 AM, Alex Orlov <ooo_saturn7@mail.ru <x-...@mail.ru>> 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
>
Re[2]: Some questions about Shiro API
Posted by Alex Orlov <oo...@mail.ru>.
Hi Lenny,
I have casts, you have casts, Bob and Mike also have casts. It doesn’t matter how many casts
you have, you mustn’t have any.
In modern SO development approach we use only API and shouldn’t know anything about implementations
classes. I’m sure that you know about OSGI, JPMS etc. The main idea of such systems is to completely hide
implementation classes. You event don’t see those implementation classes, so, you just CAN’T use them!
So, when you do FooImpl impl = (FooImpl) foo; it means that either you are doing something wrong,
or API is not flexible enough.
So, I can’t accept your advice because it is simply unacceptable.
--
Best regards, Alex Orlov
>Суббота, 7 ноября 2020, 23:37 +03:00 от Lenny Primak <lp...@hope.nyc.ny.us>:
>
>Oh and I have very few “casts” that are necessary to accomplish any of this
>
>> On Nov 7, 2020, at 12:50 AM, Alex Orlov < ooo_saturn7@mail.ru > 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
Re: Some questions about Shiro API
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
Oh and I have very few “casts” that are necessary to accomplish any of this
> On Nov 7, 2020, at 12:50 AM, Alex Orlov <oo...@mail.ru> 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
Re: Some questions about Shiro API
Posted by Lenny Primak <lp...@hope.nyc.ny.us>.
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 <oo...@mail.ru> 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