shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Can anonymous user have permissions?
Date Fri, 13 Feb 2015 05:11:29 GMT
Tamas tossed up this as an example:

That should work, but it seems like a long way to go for something that _should_ just work.
Another idea to consider, is just setting the default principal to 'anonymous' via a SubjectFactory

and then injecting that component:

(i'm not sure how this plays with the rememberMe functionality, but adding just adding this
as a thought)
FTR I had no idea there was a DefaultSubjectFactory.  I think however since that might be
global, that a filter in this case may be better, but have to think about it more now that
I realize there is a feature to set the default subject via factory.

Will this work and property get the anonymous subject managed so that the rest of Shiros systems
behave properly?  Tamas had another example below it that does a login() but I don't think
that is proper, as well as its much more expensive as it dives into shiro frameworks, not
something we want to do on each request w/o authentication.

This branch also has a special realm, but I'm not sure if that is actually needed or something
like "n/a" for realm-name as you have in your example w/o a realm bound to that name is sufficient?

Yeah, the anonymous realm would be a better way to deal with that, that way you could force
this user to the anonymous realm (by making it first in your realm list) which means you would
not need to worry about the odd case of a person trying to login with the 'anonymous' user
and becoming authenticated.
Anonymous realm seems to also provide easy way to shut off anonymous, another requirement/use-case
we have.

And yes, generally we'd like to be able to have a way to grant _guest_ a set of roles/permissions
but presently the shiro frameworks only can do this if a subject has a principal and a _guest_
is a subject w/o a principal.

I'd like to hear other thoughts on this, because I've banged my head on this before.  I feel
you should be able to assign roles/permissions to the _guest_ user, currently the only way
to do this is to force a fake principal into the mix (and then you are no longer really a
Ya, it would be nice if the default delegating impl had some means to say give me the permissions
for _guest_ user.  I think we could build that ourselves, but it seems like something missing
from the core framework.  Would be easier if the delegating took the subject instead of the
the subject.principal, and left that detail up to the securitymanager impl.

It may not matter however for our case, if you remember, we have to be able to allow the _anonymous_
username to be changed for some crazy reason, so we can not really use the _guest_ concept
at all, but have to continue using an _anonymous_ (non-authenticated, non-remembered, non-logged-in)

Yeah, in your case, that dated back to an old odd requirement (the idea was to allow the anonymous
user's info to be pulled from an external source i.e. LDAP)
Yar, we can’t even fully remember the details except for something like “if you use active-directory
the _anonymous_ user is called _guest_.  But I think we are on a path now to make this work
in a simpler fashion, removing the subject.login() should really help.

I think though that shiro could really do with some proper api around is subject.Guest() or
subject.isAnonymous()  (pick one they mean basically the same thing), vs. assuming subject.principal=null
implies this and has no permissions.  Many use-cases I think to want to use the permission
system to allow folks who are anonymous/guest to have access.  Certainly we have these use-cases.
 Needing to force in a fake non-authenticated user complicates things, and voids some of
the use of @RequireGuest apis.

ATM if we progress we can’t use Shiro concept of _guest_ at all.  And would have to re-implement
@RequiresGuest and @RequiresUser to be aware of this special subject.principal=<anonymous>.
  Its do able, and we’ll likely move forward to to this.  But the framework itself IMO
should cope with this edge-case, which isn’t limited to use if you ask google.

 * * *

FTR, shiro is very simple if you use it as explained in the limited examples, but as soon
as you get off the path, its vastly complex and hard to comprehend.

Anyways, we may need more input from you guys and I appreciate the response with details.
 If there is anything we can contribute back, of course, we’ll be more than happy to do
so… but I think this specific issues is a core design limitation to the framework/api that
can as-is only be worked around at present.

View raw message