Tamas tossed up this as an example: https://github.com/sonatype/nexus-oss/commit/ad1d703125ec1be1d0eae00492939d60de38a701#diff-c82a898a4ce4094080b2cb98d3567affR38
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 https://github.com/bdemers/shiro/compare/bdemers:anonymous-user-roles...anon-take-2#diff-c592bbcd955d97db3e51216509533851R10 and then injecting that component: https://github.com/bdemers/shiro/compare/bdemers:anonymous-user-roles...anon-take-2#diff-0d740ecf6abf4b36742a10db24b7b8c7R28 (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 _guest_) 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) user. 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. —jason
