While I somewhat agree that an implementation of using an externalized Access Control Model would be better in some respects, I do find that the current implementation is well thought out and quite flexible for Wiki usage.
Any Java Container implementation must simultaneously deal with file permissions, web container permissions, java.policy. WIKI-Groups and Page ACLs were deliberately meant to be managed outside of the web container or java.policy so that users can create discretionary "roles" without getting system admins involved. This is an intentional feature, and a very powerful one which along with Page ACLs reduces the barrier to adoption. We all know the difficulty of getting some administrator in some other area of an organization to grant (or deny) access to a "thing". Note that the hierarchy for Access Control is: (I do not see this documented, it was in a user group a few years back) - "built-in" roles - container-managed roles - WIKI-Groups - WIKI-Profiles AFIK, any "Container" implementation deals with deal with file permissions, "Container" permissions. There are some complexities that may documented but not so well for those not familiar with the concepts. I think this page probably summarise most of the concepts: https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security Questions, Comments and Suggestions for improvements are always welcome. -- -jim Jim Willeke On Tue, Oct 3, 2017 at 10:06 PM, Paul Uszak <paul.us...@gmail.com> wrote: > Well I still have trouble with the permissions /users after a couple of > years. All sorts of weird things happen. > > I've stated previously that I consider the security configuration > extremely complicated, bordering on unusable. You cannot have a credible > product that uses (simultaneously) file permissions, web container > permissions, wiki policies and per page directives. I can't think of > another application that has such complex security across so many levels. > It's madness - do you hear me? Sheer madness :-) > > Seriously, I would suggest a total overhaul to simplify massively. I'd > even consider writing some clearer documentation. It might reduce the > number of set up issues that appear here. Although, with four dimensional > security I suspect I'm not up to it. > > What was the question again..? > > It seems to me that if only the front page is publicly visible, it needn't > be within the wiki's context. Simply have a static front page at one URI, > and have the private wiki at another. It also means you don't have to > explain why you're being unfriendly as the wiki will be invisible > (unlinked). I have something similar myself. Or have I misunderstood? > > On 3 October 2017 at 20:09, Jürgen Weber <juer...@jwi.de> wrote: > > > Hi, > > > > I followed Dave's blog entry at > > > > https://blog.davekoelmeyer.co.nz/2014/07/20/configuring-a- > > public-jspwiki-instance-for-private-use/ > > > > Has someone tried to keep the front page public? (i.e. to give a > > friendly reason for the rest of the pages being private) > > > > I tried to give all front facing pages [{ALLOW view ALL}] > > but still only the login prompt. > > > > Greetings, > > Juergen > > >
