You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jspwiki.apache.org by Jürgen Weber <ju...@jwi.de> on 2017/10/03 19:09:25 UTC
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
Re: Configuring a public JSPWiki instance for private use
Posted by Col Willis <co...@gmail.com>.
*Using Apache Tomcat, in the users.xml I have the following roles:*
<role rolename="Admin"/>
<role rolename="Authenticated"/>
<role rolename="Trusted"/>
(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 <pe...@jalin.de> 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
Posted by Jürgen Weber <ju...@jwi.de>.
Peter,
that is exactly what I was looking for.
Thanks very much,
Juergen
2017-10-04 9:59 GMT+02:00 Peter Hormanns <pe...@jalin.de>:
>> 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
Posted by Peter Hormanns <pe...@jalin.de>.
> 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
Posted by Peter Hormanns <pe...@jalin.de>.
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
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
>> > > > > > >> > > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Re: Configuring a public JSPWiki instance for private use
Posted by 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
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Configuring a public JSPWiki instance for private use
Posted by Jürgen Weber <ju...@jwi.de>.
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 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 <pa...@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>.
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 <pa...@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 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 <pa...@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 <pa...@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 Paul Uszak <pa...@gmail.com>.
"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 <pa...@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 <pa...@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>.
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 <pa...@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 <pa...@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 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 <pa...@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 <pa...@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 Paul Uszak <pa...@gmail.com>.
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 <pa...@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 Jim Willeke <ji...@willeke.com>.
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 <pa...@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 Paul Uszak <pa...@gmail.com>.
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
>