You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Juan Pablo Santos Rodríguez <ju...@gmail.com> on 2017/11/09 20:55:11 UTC
Re: Configuring a public JSPWiki instance for private use
Hi again,
couple of things I'd like to point out on this thread (*always* IMHO)
- What is JSPWiki for? Which users should JSPWiki target? should it compete
on the CMS market?
For the latter question, IMO well, no; same as any other wiki out there.
Yes, you can use a wiki to build simple sites (one html layout, something
like, f.ex., jspwiki.apache.org), and (obviously) you can build wiki-based
sites, but that use differs from a CMS. F.ex, CMSs often offer the
capability to track returning users, to offer them personalized content.
Should JSPWiki (or any other wiki) focus on doing that? That shouldn't be a
core functionality for a Wiki, but it's pretty important for a CMS.
As for the initial questions, JSPWiki should be as simple as you want it to
be. You can use it as a personal notepad or you can use it as a corporate
wiki, or something in-between. You may need no customization at all, or you
may need to set up container auth, or any other thing you may need to. This
reflects not only on the installation options -JSPWiki as a
self-executable, as a .war file, as docker container-, but throughout the
code; and also when referred to, on the "Getting Started" page, when it
states "JSPWiki is a simple (well, not any more) WikiWiki clone" (In fact,
I'm thinking on changing that phrase to "JSPWiki is a WikiWiki clone, which
is as simple as you need it to be").
Along the lines of the previous point, the current ACL model starts at no
access control at all and goes up to being as complex (="infinite
combinations" else-thread) as you need it to be. As it allows a lot of
flexibility, is no wonder that
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security is long,
but it is complicated to make it shorter. I see that page more as a
reference guide: I don't remember how to enable all the ACL aspects, so
when I want to see how to set up something I go to the appropiate section
there and read what needs to be done.
Furthermore, when it doesn't meet your needs, then you can code your own
extension and replace the default behaviour pretty easily. Most probably,
the "middle ground product" sense mentioned is because, it allows a lot of
flexibility, but doesn't have many alternatives to the defaults, f.ex., you
can easily switch your page provider, but how many alternatives do we have
for it now? If most of the time the answer to this question is "go ahead
and code it", is easy to think on a middle ground. Sum to that we're all
coding on free time, so features come out slow, so that sense probably
increases.
Given all these, where should JSPWiki head, in a general terms? IMO, two
directions: making it simple to use while keeping its flexibility and
enabling more alternatives to current defaults. As the current pace is
slow, it'll take time to wore off the middle-ground sense, but I hope it to
get smaller with every release..
WDYT?
best regards,
juan pablo
On Fri, Oct 6, 2017 at 1:25 PM, Jürgen Weber <ju...@jwi.de> wrote:
> About setting up Container security for JSPWiki I had a couple years ago
> written about in
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=
> JSPWikiContainerManagedAuthenticationInstallation
>
> And yes, the default policy file should be more restricted.
>
> Juergen
>
> Am 06.10.2017 12:21 schrieb "Paul Uszak" <pa...@gmail.com>:
>
> > Yes a definitive tutorial would be a beginning. But herein lies a
> > problem. Juergen, what are you talking about with your 2nd paragraph?
> Non
> > of this is in the "Quick and simple install" section @
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Getting%20Started. Do you
> > see
> > what I mean? I tried a fresh install yesterday and fell flat on my face
> at
> > step 3. It just doesn't work whereas my SimpleSite experience was
> > wonderful. Grr emoji.
> >
> > With almost infinite undefined security configurations as you've just
> > illustrated, JSPWiki is equally vulnerable. It ships with anonymous
> users.
> > As soon as you turn it on, all the pages and comments get spammed so hard
> > that I get Java out of memory errors. I've also documented an inability
> to
> > log out. We cannot rely on container managed security because it doesn't
> > work easily with the wiki. If it used one or the other we'd be fine, but
> it
> > uses all of them all of the time. Adding more JAAS functionality really
> > isn't the way forward. That's another (enterprise) layer added on top .
> > It's clearly unsustainable and this is borne out by the adoption
> > statistics. I'm thinking of dropping it as well as it takes way too much
> > effort, even to simply reinstall. But as I opportunistically pointed out
> > earlier, there's scant alternative for a simplistic text based site.
> >
> > If I had the requisite skills, my approach would be to fork it, strip it
> > and call it "Kitten". A re architecture to a MVC pattern like Struts2
> > would be ideal as JSP is really a presentation technology isn't it? That
> > would be a clear migration path and a lot of the code could be reused.
> > Pity I'm too thik...
> >
> > On 6 October 2017 at 07:28, Jürgen Weber <ju...@jwi.de> wrote:
> >
> > > Wouldn't a good tutorial be enough?
> > >
> > > Basically you just have to add a user to tomcat-users.xml, enable
> > container
> > > managed security in web.xml and edit the policy (maybe we should
> include
> > > the default policy, that is more restricted and just works).
> > >
> > > Wordpress and friends have zillions of security holes, whereas we can
> > rely
> > > mostly on proven container security.
> > >
> > > Juergen
> > >
> > > Am 06.10.2017 01:35 schrieb "David Vittor" <dv...@gmail.com>:
> > >
> > > > 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 <pa...@gmail.com>
> > > 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 <ju...@jwi.de> 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 <ji...@willeke.com>:
> > > > > > > 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 <
> paul.uszak@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 <ji...@willeke.com>
> > 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.uszak@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 <ju...@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
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Configuring a public JSPWiki instance for private use
Posted by Jürgen Weber <ju...@jwi.de>.
Well, take your mobile phone in portrait mode, head over to
jspwiki.apache.org, try to find the FAQ page, or try to edit a page ..
The world goes mobile, so JSPWiki should be usable for mobile users, too.
cheers,
Jürgen
2017-11-09 21:55 GMT+01:00 Juan Pablo Santos Rodríguez
<ju...@gmail.com>:
> Hi again,
>
> couple of things I'd like to point out on this thread (*always* IMHO)
>
> - What is JSPWiki for? Which users should JSPWiki target? should it compete
> on the CMS market?
> For the latter question, IMO well, no; same as any other wiki out there.
> Yes, you can use a wiki to build simple sites (one html layout, something
> like, f.ex., jspwiki.apache.org), and (obviously) you can build wiki-based
> sites, but that use differs from a CMS. F.ex, CMSs often offer the
> capability to track returning users, to offer them personalized content.
> Should JSPWiki (or any other wiki) focus on doing that? That shouldn't be a
> core functionality for a Wiki, but it's pretty important for a CMS.
>
> As for the initial questions, JSPWiki should be as simple as you want it to
> be. You can use it as a personal notepad or you can use it as a corporate
> wiki, or something in-between. You may need no customization at all, or you
> may need to set up container auth, or any other thing you may need to. This
> reflects not only on the installation options -JSPWiki as a
> self-executable, as a .war file, as docker container-, but throughout the
> code; and also when referred to, on the "Getting Started" page, when it
> states "JSPWiki is a simple (well, not any more) WikiWiki clone" (In fact,
> I'm thinking on changing that phrase to "JSPWiki is a WikiWiki clone, which
> is as simple as you need it to be").
>
> Along the lines of the previous point, the current ACL model starts at no
> access control at all and goes up to being as complex (="infinite
> combinations" else-thread) as you need it to be. As it allows a lot of
> flexibility, is no wonder that
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security is long,
> but it is complicated to make it shorter. I see that page more as a
> reference guide: I don't remember how to enable all the ACL aspects, so
> when I want to see how to set up something I go to the appropiate section
> there and read what needs to be done.
>
> Furthermore, when it doesn't meet your needs, then you can code your own
> extension and replace the default behaviour pretty easily. Most probably,
> the "middle ground product" sense mentioned is because, it allows a lot of
> flexibility, but doesn't have many alternatives to the defaults, f.ex., you
> can easily switch your page provider, but how many alternatives do we have
> for it now? If most of the time the answer to this question is "go ahead
> and code it", is easy to think on a middle ground. Sum to that we're all
> coding on free time, so features come out slow, so that sense probably
> increases.
>
> Given all these, where should JSPWiki head, in a general terms? IMO, two
> directions: making it simple to use while keeping its flexibility and
> enabling more alternatives to current defaults. As the current pace is
> slow, it'll take time to wore off the middle-ground sense, but I hope it to
> get smaller with every release..
>
> WDYT?
>
>
> best regards,
> juan pablo
>
> On Fri, Oct 6, 2017 at 1:25 PM, Jürgen Weber <ju...@jwi.de> wrote:
>
>> About setting up Container security for JSPWiki I had a couple years ago
>> written about in
>>
>> https://jspwiki-wiki.apache.org/Wiki.jsp?page=
>> JSPWikiContainerManagedAuthenticationInstallation
>>
>> And yes, the default policy file should be more restricted.
>>
>> Juergen
>>
>> Am 06.10.2017 12:21 schrieb "Paul Uszak" <pa...@gmail.com>:
>>
>> > Yes a definitive tutorial would be a beginning. But herein lies a
>> > problem. Juergen, what are you talking about with your 2nd paragraph?
>> Non
>> > of this is in the "Quick and simple install" section @
>> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Getting%20Started. Do you
>> > see
>> > what I mean? I tried a fresh install yesterday and fell flat on my face
>> at
>> > step 3. It just doesn't work whereas my SimpleSite experience was
>> > wonderful. Grr emoji.
>> >
>> > With almost infinite undefined security configurations as you've just
>> > illustrated, JSPWiki is equally vulnerable. It ships with anonymous
>> users.
>> > As soon as you turn it on, all the pages and comments get spammed so hard
>> > that I get Java out of memory errors. I've also documented an inability
>> to
>> > log out. We cannot rely on container managed security because it doesn't
>> > work easily with the wiki. If it used one or the other we'd be fine, but
>> it
>> > uses all of them all of the time. Adding more JAAS functionality really
>> > isn't the way forward. That's another (enterprise) layer added on top .
>> > It's clearly unsustainable and this is borne out by the adoption
>> > statistics. I'm thinking of dropping it as well as it takes way too much
>> > effort, even to simply reinstall. But as I opportunistically pointed out
>> > earlier, there's scant alternative for a simplistic text based site.
>> >
>> > If I had the requisite skills, my approach would be to fork it, strip it
>> > and call it "Kitten". A re architecture to a MVC pattern like Struts2
>> > would be ideal as JSP is really a presentation technology isn't it? That
>> > would be a clear migration path and a lot of the code could be reused.
>> > Pity I'm too thik...
>> >
>> > On 6 October 2017 at 07:28, Jürgen Weber <ju...@jwi.de> wrote:
>> >
>> > > Wouldn't a good tutorial be enough?
>> > >
>> > > Basically you just have to add a user to tomcat-users.xml, enable
>> > container
>> > > managed security in web.xml and edit the policy (maybe we should
>> include
>> > > the default policy, that is more restricted and just works).
>> > >
>> > > Wordpress and friends have zillions of security holes, whereas we can
>> > rely
>> > > mostly on proven container security.
>> > >
>> > > Juergen
>> > >
>> > > Am 06.10.2017 01:35 schrieb "David Vittor" <dv...@gmail.com>:
>> > >
>> > > > 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 <pa...@gmail.com>
>> > > 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 <ju...@jwi.de> 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 <ji...@willeke.com>:
>> > > > > > > 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 <
>> paul.uszak@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 <ji...@willeke.com>
>> > 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.uszak@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 <ju...@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
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>