Re: Configuring a public JSPWiki instance for private use
> > > > > >> reasons run deep and I've written on them previously, but I >> > guess >> > > > that >> > > > > > >> nothing is likely to improve. *What is JSPWiki for?* I'd >> > dearly >> > > > love >> > > > > > >> JSPWiki to succeed, but honestly I cannot see a way forward >> even >> > > > > though >> > > > > > I >> > > > > > >> keep desperately searching. Naff powers of persuasion I >> guess. >> > > > > > >> >> > > > > > >> Unfortunately at this moment I'm repurposing my wiki so >> there's >> > a >> > > > > fierce >> > > > > > >> debate between heart and mind as to whether I should seek >> > greener >> > > > > grass. >> > > > > > >> Is this too -ve? >> > > > > > >> >> > > > > > >> On 4 October 2017 at 14:01, Jim Willeke >> > wrote: >> > > > > > >> >> > > > > > >> > 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 >> > > > 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 >> > > > > > >> > > > >> > > > > > >> > > >> > > > > > >> > >> > > > > > >> >> > > > > > >> > > > > >> > > > >> > > >> > >>
Re: Configuring a public JSPWiki instance for private use
t; > > > > > > > > > > > > > > -- > > > > > > > -jim > > > > > > > Jim Willeke > > > > > > > > > > > > > > On Wed, Oct 4, 2017 at 6:45 PM, Paul Uszak < > paul.us...@gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > >> I'm sorry Jim, I can't even remotely begin to agree with you. > > > > > > >> > > > > > > >> There are not *some* complexities. There are almost infinite > > > > > > >> complexities. Some of this might be clear to a professional IT > > > guru > > > > > like > > > > > > >> yourself, but (I will wager) that most cannot scratch even the > > > > > surface. > > > > > > >> The document you link to is 7000 words long, and includes > > > enterprise > > > > > > JAAS > > > > > > >> configuration that is on (it states) by default. What? And > > > implied > > > > > > >> permissions? It reads like a matrix of potential security > > > > > combinations. > > > > > > >> > > > > > > >> We don't even know what the relationship is between container > > > users > > > > > and > > > > > > >> wiki users. Are they the same? And what then about the wiki > > > groups & > > > > > > >> container roles? Are they the same? I'm in the odd state of > > not > > > > > being > > > > > > >> able to log out of the wiki. If I log out and the page says > > > logged > > > > > out > > > > > > >> G’day (what is that, Klingon?) I just hit back on the browser > > and > > > > I'm > > > > > > back > > > > > > >> in and able to edit! That's a trivial example, but > illustrates > > > the > > > > > > point > > > > > > >> well. > > > > > > >> > > > > > > >> And how can you even dream of having anonymous users on an > > > internet > > > > > > facing > > > > > > >> wiki? As soon as you try to implement some form of primitive > > > > security > > > > > > >> against the evil hordes out there, you run afoul of the > > > > *flexibility*. > > > > > > I > > > > > > >> think that you have to conclude that the whole security > thing's > > a > > > > > mess. > > > > > > >> You might want to review the holistic scope of barriers to > > > adoption. > > > > > > The > > > > > > >> reasons run deep and I've written on them previously, but I > > guess > > > > that > > > > > > >> nothing is likely to improve. *What is JSPWiki for?* I'd > > dearly > > > > love > > > > > > >> JSPWiki to succeed, but honestly I cannot see a way forward > even > > > > > though > > > > > > I > > > > > > >> keep desperately searching. Naff powers of persuasion I > guess. > > > > > > >> > > > > > > >> Unfortunately at this moment I'm repurposing my wiki so > there's > > a > > > > > fierce > > > > > > >> debate between heart and mind as to whether I should seek > > greener > > > > > grass. > > > > > > >> Is this too -ve? > > > > > > >> > > > > > > >> On 4 October 2017 at 14:01, Jim Willeke > > wrote: > > > > > > >> > > > > > > >> > 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 > > > > 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 > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
Re: Configuring a public JSPWiki instance for private use
> > > >> > > > > > > >> > 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 > > > 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 > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > >
Re: Configuring a public JSPWiki instance for private use
ce. > > > > >> The document you link to is 7000 words long, and includes > enterprise > > > > JAAS > > > > >> configuration that is on (it states) by default. What? And > implied > > > > >> permissions? It reads like a matrix of potential security > > > combinations. > > > > >> > > > > >> We don't even know what the relationship is between container > users > > > and > > > > >> wiki users. Are they the same? And what then about the wiki > groups & > > > > >> container roles? Are they the same? I'm in the odd state of not > > > being > > > > >> able to log out of the wiki. If I log out and the page says > logged > > > out > > > > >> G’day (what is that, Klingon?) I just hit back on the browser and > > I'm > > > > back > > > > >> in and able to edit! That's a trivial example, but illustrates > the > > > > point > > > > >> well. > > > > >> > > > > >> And how can you even dream of having anonymous users on an > internet > > > > facing > > > > >> wiki? As soon as you try to implement some form of primitive > > security > > > > >> against the evil hordes out there, you run afoul of the > > *flexibility*. > > > > I > > > > >> think that you have to conclude that the whole security thing's a > > > mess. > > > > >> You might want to review the holistic scope of barriers to > adoption. > > > > The > > > > >> reasons run deep and I've written on them previously, but I guess > > that > > > > >> nothing is likely to improve. *What is JSPWiki for?* I'd dearly > > love > > > > >> JSPWiki to succeed, but honestly I cannot see a way forward even > > > though > > > > I > > > > >> keep desperately searching. Naff powers of persuasion I guess. > > > > >> > > > > >> Unfortunately at this moment I'm repurposing my wiki so there's a > > > fierce > > > > >> debate between heart and mind as to whether I should seek greener > > > grass. > > > > >> Is this too -ve? > > > > >> > > > > >> On 4 October 2017 at 14:01, Jim Willeke wrote: > > > > >> > > > > >> > 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 > > 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 > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > >
Re: Configuring a public JSPWiki instance for private use
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 > > > > >> 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 > 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 > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > >
Re: Configuring a public JSPWiki instance for private use
s > > >> >- 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 > > >> 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 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 > > >> > > > > > >> > > > > >> > > > >> > > >
Re: Configuring a public JSPWiki instance for private use
amp; > >> container roles? Are they the same? I'm in the odd state of not being > >> able to log out of the wiki. If I log out and the page says logged out > >> G’day (what is that, Klingon?) I just hit back on the browser and I'm > back > >> in and able to edit! That's a trivial example, but illustrates the > point > >> well. > >> > >> And how can you even dream of having anonymous users on an internet > facing > >> wiki? As soon as you try to implement some form of primitive security > >> against the evil hordes out there, you run afoul of the *flexibility*. > I > >> think that you have to conclude that the whole security thing's a mess. > >> You might want to review the holistic scope of barriers to adoption. > The > >> reasons run deep and I've written on them previously, but I guess that > >> nothing is likely to improve. *What is JSPWiki for?* I'd dearly love > >> JSPWiki to succeed, but honestly I cannot see a way forward even though > I > >> keep desperately searching. Naff powers of persuasion I guess. > >> > >> Unfortunately at this moment I'm repurposing my wiki so there's a fierce > >> debate between heart and mind as to whether I should seek greener grass. > >> Is this too -ve? > >> > >> On 4 October 2017 at 14:01, Jim Willeke wrote: > >> > >> > 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 > >> 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 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 > >> > > > > >> > > > >> > > >> >
Re: Configuring a public JSPWiki instance for private use
re 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 >> 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 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 >> > > > >> > > >> > >>
Re: Configuring a public JSPWiki instance for private use
Peter, that is exactly what I was looking for. Thanks very much, Juergen 2017-10-04 9:59 GMT+02:00 Peter Hormanns : >> put the ACLs into jspwiki.policy : >> >> Something like >> >> grant principal com.ecyrd.jspwiki.auth.authorize.Role "All" { >> permission com.ecyrd.jspwiki.auth.permissions.PagePermission >> "*:LeftMenu", "view"; >> permission com.ecyrd.jspwiki.auth.permissions.PagePermission >> "*:LeftMenuFooter", "view"; >> permission com.ecyrd.jspwiki.auth.permissions.PagePermission >> "*:Main", "view"; >> permission com.ecyrd.jspwiki.auth.permissions.PagePermission >> "*:Impress", "view"; >> permission com.ecyrd.jspwiki.auth.permissions.PagePermission >> "*:Forbidden", "view"; >> permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", >> "login"; >> }; >> > > replace "com.ecyrd.jspwiki.auth" by "org.apache.wiki.auth". > I copied from an old configuration file. > > > Peter > > -- > Peter Hormanns - Informatikbüro Hormanns & Wenz > http://www.hormanns-wenz.de - Tel 02151 3274911 > Peter Hormanns - Hafenstraße 17 - 47809 Krefeld
Re: Configuring a public JSPWiki instance for private use
> > > 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 > 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 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 > > > > > > > > > >
Re: Configuring a public JSPWiki instance for private use
I'm sorry Jim, I can't even remotely begin to agree with you. There are not *some* complexities. There are almost infinite complexities. Some of this might be clear to a professional IT guru like yourself, but (I will wager) that most cannot scratch even the surface. The document you link to is 7000 words long, and includes enterprise JAAS configuration that is on (it states) by default. What? And implied permissions? It reads like a matrix of potential security combinations. We don't even know what the relationship is between container users and wiki users. Are they the same? And what then about the wiki groups & container roles? Are they the same? I'm in the odd state of not being able to log out of the wiki. If I log out and the page says logged out G’day (what is that, Klingon?) I just hit back on the browser and I'm back in and able to edit! That's a trivial example, but illustrates the point well. And how can you even dream of having anonymous users on an internet facing wiki? As soon as you try to implement some form of primitive security against the evil hordes out there, you run afoul of the *flexibility*. I think that you have to conclude that the whole security thing's a mess. You might want to review the holistic scope of barriers to adoption. The reasons run deep and I've written on them previously, but I guess that nothing is likely to improve. *What is JSPWiki for?* I'd dearly love JSPWiki to succeed, but honestly I cannot see a way forward even though I keep desperately searching. Naff powers of persuasion I guess. Unfortunately at this moment I'm repurposing my wiki so there's a fierce debate between heart and mind as to whether I should seek greener grass. Is this too -ve? On 4 October 2017 at 14:01, Jim Willeke wrote: > 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 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 mis
Re: Configuring a public JSPWiki instance for private use
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 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 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 > > >
Re: Configuring a public JSPWiki instance for private use
put the ACLs into jspwiki.policy : Something like grant principal com.ecyrd.jspwiki.auth.authorize.Role "All" { permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:LeftMenu", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:LeftMenuFooter", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Main", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Impress", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Forbidden", "view"; permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "login"; }; replace "com.ecyrd.jspwiki.auth" by "org.apache.wiki.auth". I copied from an old configuration file. Peter -- Peter Hormanns - Informatikbüro Hormanns & Wenz http://www.hormanns-wenz.de - Tel 02151 3274911 Peter Hormanns - Hafenstraße 17 - 47809 Krefeld
Re: Configuring a public JSPWiki instance for private use
*Using Apache Tomcat, in the users.xml I have the following roles:* (No need to set a rolename for Anonymous or All) *In the jspwiki.policy set the role-permissions:* grant principal org.apache.wiki.auth.authorize.Role "All" { permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view"; permission org.apache.wiki.auth.permissions.WikiPermission "*", "login"; }; grant principal org.apache.wiki.auth.authorize.Role "Anonymous" { permission org.apache.wiki.auth.permissions.WikiPermission "*", "login"; }; grant principal org.apache.wiki.auth.authorize.Role "Authenticated" { permission org.apache.wiki.auth.permissions.PagePermission "*:*", "view,comment"; }; grant principal org.apache.wiki.auth.authorize.Role "Trusted" { permission org.apache.wiki.auth.permissions.PagePermission "*:*", "modify,delete"; permission org.apache.wiki.auth.permissions.WikiPermission "*", "editProfile,createPages,login"; }; grant principal org.apache.wiki.auth.GroupPrincipal "Admin" { permission org.apache.wiki.auth.permissions.AllPermission "*"; }; grant principal org.apache.wiki.auth.authorize.Role "Admin" { permission org.apache.wiki.auth.permissions.AllPermission "*"; }; *On any Wiki Page you can now have something like:* [{ALLOW comment Authenticated}] [{ALLOW modify Trusted}] *Or* [{ALLOW view Admin}] *etc* On 4 October 2017 at 08:23, Peter Hormanns wrote: > Am 03.10.2017 21:09, schrieb Jürgen Weber: > >> I followed Dave's blog entry at >> >> https://blog.davekoelmeyer.co.nz/2014/07/20/configuring-a-pu >> blic-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. >> > > Hi Juergen, > > put the ACLs into jspwiki.policy : > > Something like > > grant principal com.ecyrd.jspwiki.auth.authorize.Role "All" { > permission com.ecyrd.jspwiki.auth.permissions.PagePermission > "*:LeftMenu", "view"; > permission com.ecyrd.jspwiki.auth.permissions.PagePermission > "*:LeftMenuFooter", "view"; > permission com.ecyrd.jspwiki.auth.permissions.PagePermission > "*:Main", "view"; > permission com.ecyrd.jspwiki.auth.permissions.PagePermission > "*:Impress", "view"; > permission com.ecyrd.jspwiki.auth.permissions.PagePermission > "*:Forbidden", "view"; > permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", > "login"; > }; > > "Main" ist my front page. > > Best regards, > Peter > > > -- > Peter Hormanns - Informatikbüro Hormanns & Wenz > http://www.hormanns-wenz.de - Tel 02151 3274911 > Peter Hormanns - Hafenstraße 17 - 47809 Krefeld > -- Col
Re: Configuring a public JSPWiki instance for private use
Am 03.10.2017 21:09, schrieb Jürgen Weber: 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. Hi Juergen, put the ACLs into jspwiki.policy : Something like grant principal com.ecyrd.jspwiki.auth.authorize.Role "All" { permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:LeftMenu", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:LeftMenuFooter", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Main", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Impress", "view"; permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:Forbidden", "view"; permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*", "login"; }; "Main" ist my front page. Best regards, Peter -- Peter Hormanns - Informatikbüro Hormanns & Wenz http://www.hormanns-wenz.de - Tel 02151 3274911 Peter Hormanns - Hafenstraße 17 - 47809 Krefeld
Re: Configuring a public JSPWiki instance for private use
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 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 >
Re: Configuring a public JSPWiki instance for private use
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