Re: Configuring a public JSPWiki instance for private use

[David Vittor]

I kind of feel both sides of the argument are right here. Even though
JSPWiki has a pretty great authentication system, the problem is it's not
very user friendly.

The solution I think is to build some sort of an "admin" UI into JSP wiki
which lets users configure group/user permissions, and then saves these
into the back end jspwiki.policy file.

I think that is one thing that Confluence did really well, even though the
backend is complex the front end is easy to manage. I think JSPWiki needs
to the same. There is actually in the code a "hidden" admin page, but it's
very buggy, and not sure how much additional work is needed to make this
public.

The other solution might be to use the tomcat group/user configurations
with JAAS, but this probably needs better documentation, that is easy to
follow.

Every person/organisation has different requirements for how they want
security to work. But that should not stop us making every effort to make
it more user friendly.

Anyway they are my thoughts.

Cheers,
David V




On Fri, Oct 6, 2017 at 10:01 AM, Paul Uszak  wrote:

> "What is JSPWiki for?" This then is the question.  If we kneel before our
> god(s), hands on heart, lovingly think of our grandmothers and ask
> ourselves “Can JSPWiki effectively compete in the content management
> market” , what's the honest answer?  I think deep down in our souls it's an
> emphatic “no”.
>
> I created a test Wordpress account last night in under five minutes. It
> looks great and you get free hosting.  Wix offers even more fantastical
> creativity when you enrol.  And xml editing wasn't needed.  Foswiki is more
> powerful and polished, and used extensively.  Pretty tough competition.
>
> But the market isn’t crowded at the bottom.  It’s empty.  This isn’t a daft
> strategy.  It’s the quintessential definition of strategic marketing.  An
> analogous example is the tool Vi.  Vi is still cherished and extensively
> used, even today configuring state of the art IaaS deployments. Simple can
> be successful.  I can see a need (which is where I came on board) for a
> plain and simple Wiki.  I use mine as a single user web site where it acts
> as a content management system.
>
> Low system requirements, low bandwidth and most importantly, low
> configuration.  Zero configuration to start.  The details can be thrashed
> out later, but JSPWiki’s offering and place in the market must be resolved
> for success.  I’ve posed this question before, but I’m not sure that
> there’s sufficient appetite for answering it sincerely.  C'est la vie.
>
>
> On 5 October 2017 at 21:49, Jürgen Weber  wrote:
>
> > Jim,
> >
> > I also think the JSPWiki Authorization system is very good. The
> > container looks after authentication, and the policies decide what the
> > Container authenticated user is allowed too.
> >
> > Kudos to Andrew Jaquith (https://www.ecyrd.com/
> JSPWiki/wiki/AndrewJaquith)
> >
> > Juergen
> >
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=
> > JSPWikiContainerManagedAuthenticationInstallation
> >
> > 2017-10-05 10:39 GMT+02:00 Jim Willeke :
> > > Try not to think of it as infinite complexities but rather infinite
> > > Combinations. ;)
> > >
> > > And if you have a suggestion or a request for an improvement, I am sure
> > > folks would listen.
> > >
> > > I do agree many of the JSPWiki pages could use some refactoring.
> > > As with MOST open source projects the docs and code they are out of the
> > > beyond the realm of understanding for "common folk".
> > >
> > > Oh, and on "And how can you even dream of having anonymous users on an
> > > internet facing
> > > wiki?"
> > > Many are, even Wikipedia.
> > >
> > > And as far as "What is JSPWiki for?", I agree it is somewhat of a
> > > middle-road undefined product.
> > >
> > >- Not for the Enterprise as there is AFIK, no method to keep the
> sales
> > >dept separate from the engineering dept. (Well no reasonable tools
> to
> > make
> > >it happen)
> > >- Not for the Casual user as there is too much Flexibility. (or
> maybe
> > >too much Complexity). Perhaps most Casual users would be better off
> > with
> > >a "hosted" solution. (https://www.blogger.com/ or something)
> > >- Is not designed (or packaged) to be "dropped in" a SaaS like
> Google
> > >App Engine (or whatever AWS and Microsoft Hosting has to offer in
> that
> > >line.)
> > >- Perhaps it is best as a toolkit to be embedded within another
> > product
> > >offering?
> > >
> > > So I agree it is somewhat a "For anyone" which is NEVER the right
> answer
> > > for todays crowded market if you want to Succeed.
> > >
> > > If you would like some help, please provide some details on your
> > > configuration.
> > > Are you on Tomcat?
> > > Do you have Container Authentication turned on?
> > >
> > > Have you altered the WEB-INF/jspwiki.policy file?
> > >
> > > Any other details you think might be helpful.
> > >
> > >
> > > --

Re: Configuring a public JSPWiki instance for private use

[Paul Uszak]

"What is JSPWiki for?" This then is the question.  If we kneel before our
god(s), hands on heart, lovingly think of our grandmothers and ask
ourselves “Can JSPWiki effectively compete in the content management
market” , what's the honest answer?  I think deep down in our souls it's an
emphatic “no”.

I created a test Wordpress account last night in under five minutes. It
looks great and you get free hosting.  Wix offers even more fantastical
creativity when you enrol.  And xml editing wasn't needed.  Foswiki is more
powerful and polished, and used extensively.  Pretty tough competition.

But the market isn’t crowded at the bottom.  It’s empty.  This isn’t a daft
strategy.  It’s the quintessential definition of strategic marketing.  An
analogous example is the tool Vi.  Vi is still cherished and extensively
used, even today configuring state of the art IaaS deployments. Simple can
be successful.  I can see a need (which is where I came on board) for a
plain and simple Wiki.  I use mine as a single user web site where it acts
as a content management system.

Low system requirements, low bandwidth and most importantly, low
configuration.  Zero configuration to start.  The details can be thrashed
out later, but JSPWiki’s offering and place in the market must be resolved
for success.  I’ve posed this question before, but I’m not sure that
there’s sufficient appetite for answering it sincerely.  C'est la vie.


On 5 October 2017 at 21:49, Jürgen Weber  wrote:

> Jim,
>
> I also think the JSPWiki Authorization system is very good. The
> container looks after authentication, and the policies decide what the
> Container authenticated user is allowed too.
>
> Kudos to Andrew Jaquith (https://www.ecyrd.com/JSPWiki/wiki/AndrewJaquith)
>
> Juergen
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=
> JSPWikiContainerManagedAuthenticationInstallation
>
> 2017-10-05 10:39 GMT+02:00 Jim Willeke :
> > Try not to think of it as infinite complexities but rather infinite
> > Combinations. ;)
> >
> > And if you have a suggestion or a request for an improvement, I am sure
> > folks would listen.
> >
> > I do agree many of the JSPWiki pages could use some refactoring.
> > As with MOST open source projects the docs and code they are out of the
> > beyond the realm of understanding for "common folk".
> >
> > Oh, and on "And how can you even dream of having anonymous users on an
> > internet facing
> > wiki?"
> > Many are, even Wikipedia.
> >
> > And as far as "What is JSPWiki for?", I agree it is somewhat of a
> > middle-road undefined product.
> >
> >- Not for the Enterprise as there is AFIK, no method to keep the sales
> >dept separate from the engineering dept. (Well no reasonable tools to
> make
> >it happen)
> >- Not for the Casual user as there is too much Flexibility. (or maybe
> >too much Complexity). Perhaps most Casual users would be better off
> with
> >a "hosted" solution. (https://www.blogger.com/ or something)
> >- Is not designed (or packaged) to be "dropped in" a SaaS like Google
> >App Engine (or whatever AWS and Microsoft Hosting has to offer in that
> >line.)
> >- Perhaps it is best as a toolkit to be embedded within another
> product
> >offering?
> >
> > So I agree it is somewhat a "For anyone" which is NEVER the right answer
> > for todays crowded market if you want to Succeed.
> >
> > If you would like some help, please provide some details on your
> > configuration.
> > Are you on Tomcat?
> > Do you have Container Authentication turned on?
> >
> > Have you altered the WEB-INF/jspwiki.policy file?
> >
> > Any other details you think might be helpful.
> >
> >
> > --
> > -jim
> > Jim Willeke
> >
> > On Wed, Oct 4, 2017 at 6:45 PM, Paul Uszak  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
> >> 

Re: Configuring a public JSPWiki instance for private use

[Jürgen Weber]

Jim,

I also think the JSPWiki Authorization system is very good. The
container looks after authentication, and the policies decide what the
Container authenticated user is allowed too.

Kudos to Andrew Jaquith (https://www.ecyrd.com/JSPWiki/wiki/AndrewJaquith)

Juergen

https://jspwiki-wiki.apache.org/Wiki.jsp?page=JSPWikiContainerManagedAuthenticationInstallation

2017-10-05 10:39 GMT+02:00 Jim Willeke :
> Try not to think of it as infinite complexities but rather infinite
> Combinations. ;)
>
> And if you have a suggestion or a request for an improvement, I am sure
> folks would listen.
>
> I do agree many of the JSPWiki pages could use some refactoring.
> As with MOST open source projects the docs and code they are out of the
> beyond the realm of understanding for "common folk".
>
> Oh, and on "And how can you even dream of having anonymous users on an
> internet facing
> wiki?"
> Many are, even Wikipedia.
>
> And as far as "What is JSPWiki for?", I agree it is somewhat of a
> middle-road undefined product.
>
>- Not for the Enterprise as there is AFIK, no method to keep the sales
>dept separate from the engineering dept. (Well no reasonable tools to make
>it happen)
>- Not for the Casual user as there is too much Flexibility. (or maybe
>too much Complexity). Perhaps most Casual users would be better off with
>a "hosted" solution. (https://www.blogger.com/ or something)
>- Is not designed (or packaged) to be "dropped in" a SaaS like Google
>App Engine (or whatever AWS and Microsoft Hosting has to offer in that
>line.)
>- Perhaps it is best as a toolkit to be embedded within another product
>offering?
>
> So I agree it is somewhat a "For anyone" which is NEVER the right answer
> for todays crowded market if you want to Succeed.
>
> If you would like some help, please provide some details on your
> configuration.
> Are you on Tomcat?
> Do you have Container Authentication turned on?
>
> Have you altered the WEB-INF/jspwiki.policy file?
>
> Any other details you think might be helpful.
>
>
> --
> -jim
> Jim Willeke
>
> On Wed, Oct 4, 2017 at 6:45 PM, Paul Uszak  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 

Re: Configuring a public JSPWiki instance for private use

[Jürgen Weber]

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

[Jim Willeke]

Try not to think of it as infinite complexities but rather infinite
Combinations. ;)

And if you have a suggestion or a request for an improvement, I am sure
folks would listen.

I do agree many of the JSPWiki pages could use some refactoring.
As with MOST open source projects the docs and code they are out of the
beyond the realm of understanding for "common folk".

Oh, and on "And how can you even dream of having anonymous users on an
internet facing
wiki?"
Many are, even Wikipedia.

And as far as "What is JSPWiki for?", I agree it is somewhat of a
middle-road undefined product.

   - Not for the Enterprise as there is AFIK, no method to keep the sales
   dept separate from the engineering dept. (Well no reasonable tools to make
   it happen)
   - Not for the Casual user as there is too much Flexibility. (or maybe
   too much Complexity). Perhaps most Casual users would be better off with
   a "hosted" solution. (https://www.blogger.com/ or something)
   - Is not designed (or packaged) to be "dropped in" a SaaS like Google
   App Engine (or whatever AWS and Microsoft Hosting has to offer in that
   line.)
   - Perhaps it is best as a toolkit to be embedded within another product
   offering?

So I agree it is somewhat a "For anyone" which is NEVER the right answer
for todays crowded market if you want to Succeed.

If you would like some help, please provide some details on your
configuration.
Are you on Tomcat?
Do you have Container Authentication turned on?

Have you altered the WEB-INF/jspwiki.policy file?

Any other details you think might be helpful.


--
-jim
Jim Willeke

On Wed, Oct 4, 2017 at 6:45 PM, Paul Uszak  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:
> >