Re: Can't find jskwiki.properties

[Paul Uszak]

Any reason that this isn't done the traditional way with a -D system
property pointing to an external .properties file? That way you'd only have
one file and be able to see all the configuration parameters should you
wish to change some... Large applications (including Tomcat itself) are
configured this way.

On 30 May 2018 at 21:57, Blake McBride  wrote:

> That did it!  Thanks a lot!
>
> On Wed, May 30, 2018 at 3:32 PM, Harry Metske 
> wrote:
>
> > setting custom properties should be done with the
> jspwiki-custom.properties
> > file.
> > See
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Documentation#section-
> > Documentation-ConfigurationAndAdministration
> >
> > hope that helps
> >
> > regards,
> > Harry
> >
> >
> > Op wo 30 mei 2018 om 22:18 schreef Blake McBride 
> >
> > > Thanks for the help, but I am confused.  Tomcat explodes the war into
> the
> > > app directory.  It doesn't explode any jar files within a war.  What
> good
> > > is it in the jar?  How can I edit it?  Do I extract it, edit it, re-jar
> > > it?  Is jspwiki.war a tomcat redy-to-go web app?
> > >
> > > Thanks!
> > >
> > > Blake
> > >
> > >
> > > On Wed, May 30, 2018 at 3:01 PM, Harry Metske 
> > > wrote:
> > >
> > > > the jspwiki properties file is inside the jspwiki.jar which is in the
> > > > jspwiki.war.
> > > > So you have to recurse one level deeper :-)
> > > >
> > > > cheers,
> > > > Harry
> > > >
> > > >
> > > > Op wo 30 mei 2018 om 21:33 schreef Blake McBride <
> blake1...@gmail.com>
> > > >
> > > > > Hi.
> > > > >
> > > > > The page at
> > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Configuration
> > > > > states:
> > > > >
> > > > > "This is simple dump of the *jspwiki.properties *file contained in
> > > > > JSPWiki.war."
> > > > >
> > > > > I downloaded JSPWiki.war from
> > > > >
> > > > > http://mirror.metrocast.net/apache/jspwiki/2.10.4/
> > > > binaries/webapp/JSPWiki.war
> > > > >
> > > > > I then type:  jar tvf JSPWiki.war |grep properties
> > > > > and it responds:
> > > > >
> > > > >100 Sun May 20 20:20:14 CDT 2018
> > > > > META-INF/maven/org.apache.jspwiki/jspwiki-war/pom.properties
> > > > >
> > > > > So, there is no jspwiki.properties file in JSPWiki.war
> > > > >
> > > > > I also tried running .../Install.jsp
> > > > >
> > > > > Still no jspwiki.properties
> > > > >
> > > > > Am I using the wrong war file?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Blake McBride
> > > > >
> > > >
> > >
> >
>

Re: [RESULT][VOTE] Move to github as the primary repo

[Paul Uszak]

All very good, but this is only for development though isn't it?  I'm
surprised that it's on the user email list anyway rather than the
development list.  I take it that potential users will still be able to
download the stable production .war directly from the main JSPWiki site?

I couldn't vote as I'm only a user and [+1][0][-1] means nothing to me (or
other regular computer users).  Sorry.

On 2 December 2017 at 12:16, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:

> Hi,
>
> closing the vote as more than 72 hours have passed, and there's enough
> number +1s. The result of the vote tally is:
>
> Rick Brockman
> Dirk Frederickx [*]
> Siegfried Goeschl [*]
> Harry Metske [*]
> Juan Pablo Santos [*]
> Jim Willeke
>
> [*] denoting vote from PMC member
>
> will open the required jira issue referencing this mail.
>
> thanks to all who voted!
>
>
> best regards,
> juan pablo
>
>
> On Wed, Nov 29, 2017 at 9:55 AM, Harry Metske 
> wrote:
>
> > +1
> >
> > Op 29 nov. 2017 00:33 schreef "Juan Pablo Santos Rodríguez" <
> > juanpablo.san...@gmail.com>:
> >
> > > Hi all,
> > >
> > > As noted else-thread, we're currently using ASF's git repo as the
> > canonical
> > > repo with a read-only copy at github, but infra offers from a while
> back
> > > now the opposite possibility: work with github repo, which sends the
> > > commits automatically to the ASF's repo, which gets then read-only. It
> > > woukd treat Github as the canonical source (a copy on ASF's repo would
> > > still be made), which allows the PRs and issues to be a bit more
> > convenient
> > > (there are still some things not supported due to the Github's coarse
> > > permission structure). It would be required all committers to use
> > Github's
> > > 2FA [
> > > https://help.github.com/articles/providing-your-2fa-
> authentication-code/
> > ]
> > >
> > > This is the formal VOTE required by infra to set github as the primary
> > repo
> > > for Apache JSPWiki, and as such subject to the usual voting guidelines:
> > it
> > > will be open for at least 72 hours, everybody is encouraged to vote,
> > > although only PMC ones are binding.
> > >
> > > [+1] yes, move to github as the primary repo
> > > [0] don't mind
> > > [-1] we are fine as it is now
> > >
> > >
> > > best regards,
> > > juan pablo
> > >
> >
>

Re: Data Migration

[Paul Uszak]

To be clear, you still want to stick with JSPWiki for the front end though?

On 28 November 2017 at 13:16, Col Willis  wrote:

> Hi all,
>
> I have a personal JSPWiki for a few years with File-based storage
> (jspwiki-files)
>
> I want to migrate this to AWS Cloud, but setup a Database back-end...
>
> What is the best way to Migrate data from jspwiki-files into Database?
>
>
> Thanks,
>
> Colin
>

Re: Tomcat Manager installation

[Paul Uszak]

Thanks, I've read the bug report now.  Exactly my problem.

However, this speaks to a larger issue.  How could something like this
possibly happen? It's like pressing RUN on the IDE, getting five screens of
stack trace errors and deciding that it's ready to ship never even having
seen the welcome screen.  A significant percentage of (techie) users are on
*nix.  If a cross platform product wants to be taken seriously, we can't
ignore 67% of the user base by only testing that it installs on Windows!
VMware and VirtualBox are your friends.  Argh.

Anyway, thanks again for your help.

Ref. https://w3techs.com/technologies/overview/operating_system/all







On 19 November 2017 at 21:53, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:

> Hi Paul,
>
> that's a fair point, indeed you're probably referring to
> https://issues.apache.org/jira/browse/JSPWIKI-1051 which was fixed in
> 2.10.3-git-33, so anyone downloading 2.10.2 will probably step into the
> same problem. I'll try to reword the getting started guide his week to make
> clearer the following points:
>
> - instead of telling to copy the war, talk about deploying the war, like f.
> ex., copying the file or using the gui. Point out that there are other ways
> of using JSPWiki, like the self-executable or the Docker image
> - signaling clearly which files / folders should be accesible by default
> (pages, attachments, logs and ehcache files, IIRC)
> - production-wise installations will probably need some degree of
> customization
> - as an additional tip, point out that you could also download and compile
> from master, which usually contains more fixes/features and also works
>
> sounds reasonable? would that help out, or at least clarify things? Note
> that all these points are noted on the "customizing your installation"
> section which follows the "quick and simple install" section; although I
> realise it's easy to not read the former when you've stumbled into an error
> on the latter..
>
>
> thanks,
> juan pablo
>
>
> On Mon, Nov 13, 2017 at 2:39 PM, Rick Brockman <r...@richardbrockman.info>
> wrote:
>
> > Not too late as far as I'm concerned and I concur totally with Paul
> > Uszak...thanks to all !
> >
> > On 2017-11-13 06:09, Paul Uszak wrote:
> >
> > > Well it's not too late to have the conversation :-) or is it :-(
> > >
> > >> The pre-Install.jsp step shouldn't be more difficult than performing a
> > >> normal deploy of a war file, through usual means.
> > >
> > > That's the problem.  Non of this is defined.  MY usual means is to  use
> > the
> > > manager application and deploy via the Tomcat GUI.  So you navigate to
> > > JSPWiki.war and it's uploaded, deployed and started.  There is no
> concept
> > > of "having access".  The access control thing is enabling you to use
> the
> > > manager in the first place.  Tomcat then deploys it with
> tomcatX:tomcatX
> > > permissions.  And tomcatX isn't even a proper user (can't log in).
> > >
> > > I think that the problem is with the default location of the wiki log
> > > files.  Tomcat doesn't allow them to be created within it's context
> > > directory without changing it's permissions, or (prior to starting the
> > > context) changing the location of the wiki's log files.  And what else?
> > > How is the automatic search index stored and where? So all this is
> beyond
> > > the normal deployment method. You have to realise that a web
> /application
> > > server looks differently to a developer than it does when it's in
> > > production mode.  It's fine to run a local off grid web server as
> > root:root
> > > with 777 permissions everywhere when you're cutting code.  It's harder
> in
> > > production. And an application server is always going to be more
> > > complicated than a pure web server.
> > >
> > > This all makes the deployment not "simple". As soon as you have to
> invoke
> > > chown and vim it gets "hard", especially for non developers /non
> > > administrators.
> > >
> > > On 9 November 2017 at 20:48, Juan Pablo Santos Rodríguez <
> > > juanpablo.san...@gmail.com> wrote:
> > >
> > > Hi Paul,
> > >
> > > as I've been mostly missing last month, I'm checking all related
> JSPWiki
> > > mail, and I was wondering what kind of problems did you had performing
> a
> > > clean deploy of JSPWiki. It's probably too late to help, but at least
> we
> > > could document clearlier how to proceed in case of problems 

Re: Tomcat Manager installation

[Paul Uszak]

Well it's not too late to have the conversation :-) or is it :-(

> The pre-Install.jsp step shouldn't be more difficult than performing a
> normal deploy of a war file, through usual means.

That's the problem.  Non of this is defined.  MY usual means is to  use the
manager application and deploy via the Tomcat GUI.  So you navigate to
JSPWiki.war and it's uploaded, deployed and started.  There is no concept
of "having access".  The access control thing is enabling you to use the
manager in the first place.  Tomcat then deploys it with tomcatX:tomcatX
permissions.  And tomcatX isn't even a proper user (can't log in).

I think that the problem is with the default location of the wiki log
files.  Tomcat doesn't allow them to be created within it's context
directory without changing it's permissions, or (prior to starting the
context) changing the location of the wiki's log files.  And what else?
How is the automatic search index stored and where? So all this is beyond
the normal deployment method. You have to realise that a web /application
server looks differently to a developer than it does when it's in
production mode.  It's fine to run a local off grid web server as root:root
with 777 permissions everywhere when you're cutting code.  It's harder in
production. And an application server is always going to be more
complicated than a pure web server.

This all makes the deployment not "simple". As soon as you have to invoke
chown and vim it gets "hard", especially for non developers /non
administrators.

On 9 November 2017 at 20:48, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:

> Hi Paul,
>
> as I've been mostly missing last month, I'm checking all related JSPWiki
> mail, and I was wondering what kind of problems did you had performing a
> clean deploy of JSPWiki. It's probably too late to help, but at least we
> could document clearlier how to proceed in case of problems for upcoming
> users.
>
> The pre-Install.jsp step shouldn't be more difficult than performing a
> normal deploy of a war file, through usual means. As long as you have
> enough permissions on your server/machine to do that, everything should go
> fine. And if it doesn't, tomcat's logs (or whatever server you're using)
> should point out what is going wrong. There no need for anything else. This
> obviously changes as soon as you have limited access to your
> server/machine, but also in that case JSPWiki logs should point to whatever
> is happening..
>
>
> best regards,
> juan pablo
>
> On Fri, Oct 6, 2017 at 4:56 AM, Paul Uszak <paul.us...@gmail.com> wrote:
>
> > Further to recent "complexity" discussions, what is the protocol for
> > installing JSPWiki via the Tomcat manager gui please?
> >
> > I followed the simple installation guide but it fails at step 3.  I
> > deployed the jar file with the gui and that was successful.  A JSPWiki (I
> > left the default name) directory appeared with all of the relevant files.
> > Going to Install.jsp returns a 404 error unfortunately, but the context
> is
> > up and running.All of the files are owned by tomcat7 /tomcat7., and
> > it's running on a high port.  So I've fallen down at the first hurdle :-(
> > I vaguely remember that all of the permissions have to be customised (or
> > something).
> >
> > It's been a couple of years since I installed it last time, but I
> remember
> > that it took a while.  The instructions don't seem to mention anything
> > about users /groups.  All they say is that "I" need access to the tomcat
> > area.  But I don't as that's what deployment does.  What are the other
> > steps prior to navigating to "Install.jsp"?
> >
> > Thanks all.
> >
>

Re: Configuring a public JSPWiki instance for private use

[Paul Uszak]

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 <juer...@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" <dvit...@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 <paul.us...@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 us

Re: Configuring a public JSPWiki instance for private use

[Paul Uszak]

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

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

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

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


On 5 October 2017 at 21:49, Jürgen Weber <juer...@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 <j...@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.us...@gmail.com> wrote:
> >
> >> I'm sorry Jim, I can't even remotely begin to agree with you.
> >>
> >> There are not *some* complexities.  There are almost  infinite
> >> complexities. Some of this might be clear to a professional IT guru like
> >> yourself, but (I will wager) that most cannot scratch even the surface.
> >> The document you link to is 7000 words long, and includes enterprise
> JAAS
> >> configuration that is on (it states) by default.  What?  And implied
> >> permissions? It reads like a matrix of potential security combinations.
> >>
> >> We don't even know what the relationship is between container users and
> >> wiki users. Are they the

Re: Configuring a public JSPWiki instance for private use

[Paul Uszak]

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 <j...@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.us...@gmail.com> wrote:
>
> > Well I still have trouble with the permissions /users after a  couple of
> > years. All sorts of weird things happen.
> >
> > I've  stated previously that I consider the security configuration
> > extremely complicated, bordering on unusable.  You cannot have a credible
> > product that uses (simultaneously) file permissions, web container
> > permissions, wiki policies and per page directives.  I can't think of
> > another application that has such complex security across so many levels.
> > It's madness - do you hear me?  Sheer madness :-)
> >
> > Seriously, I would suggest a  total overhaul to simplify massively. I'd
> > even consider writing some clearer documentation.   It might reduce the
> > number of set up issues that appear here. Although, with four dimensional
> > security I suspect I'm not up to it.
> >
> > What was the question again..?
> >
> > It seems to me that if only the front page is publicly visible, it
> needn't
> > be within the wiki's context.  Simply have a static front page at one
> URI,
> > and have the private wiki at another.  It also means you don't have to
> > explain why you're being unfriendly as the wiki will be invisible
> > (unlinked).  I have something similar myself.  Or have I misunderstood?
> >
> > On 3 October 201

Re: Configuring a public JSPWiki instance for private use

[Paul Uszak]

Well I still have trouble with the permissions /users after a  couple of
years. All sorts of weird things happen.

I've  stated previously that I consider the security configuration
extremely complicated, bordering on unusable.  You cannot have a credible
product that uses (simultaneously) file permissions, web container
permissions, wiki policies and per page directives.  I can't think of
another application that has such complex security across so many levels.
It's madness - do you hear me?  Sheer madness :-)

Seriously, I would suggest a  total overhaul to simplify massively. I'd
even consider writing some clearer documentation.   It might reduce the
number of set up issues that appear here. Although, with four dimensional
security I suspect I'm not up to it.

What was the question again..?

It seems to me that if only the front page is publicly visible, it needn't
be within the wiki's context.  Simply have a static front page at one URI,
and have the private wiki at another.  It also means you don't have to
explain why you're being unfriendly as the wiki will be invisible
(unlinked).  I have something similar myself.  Or have I misunderstood?

On 3 October 2017 at 20:09, Jürgen Weber  wrote:

> Hi,
>
> I followed Dave's blog entry at
>
> https://blog.davekoelmeyer.co.nz/2014/07/20/configuring-a-
> public-jspwiki-instance-for-private-use/
>
> Has someone tried to keep the front page public? (i.e. to give a
> friendly reason for the rest of the pages being private)
>
> I tried to give all front facing pages [{ALLOW view ALL}]
> but still only the login prompt.
>
> Greetings,
> Juergen
>

Re: OT (sort of): Nuxeo migrates off Confluence

[Paul Uszak]

You're kidding, right?

I've asked this previously but for the newest members, I'll ask again.
What is JSPWiki for?  I know that this appears to be banging a drum, but it
is unrealistic to expect large scale uptake of JSPWiki if you can’t decide
what or who it’s for.  Picking out and replicating minor features of
successful products seems to be without direction and ultimately
fruitless.  Could we be honest with ourselves here?  Why are we looking at
features from solutions used by the US Navy, Boeing and Orange?  Is it to
compete with them, or to continue a hobby?

There is a huuuge market opportunity for a simple very low bandwidth wiki
/website solution (I see the two as synonymous).  The market space is
virtually uncontested in this area.  There are numerous strengths that
JSPWiki has that could be leveraged to dominate in this role.  Market
segmentation is key here.  Try to provide a solution to a very specific
problem, and do it well.  There are thousands of nerds (I use the term
playfully) who'd like a turnkey solution to hosting their own website from
that old box under the table.  They struggle with low bandwidth.  There are
organisations across the whole of the developing world wanting their own
websites with minimal bandwidth requirements to pass over the mobile
network. There is now probably more mobile (low bandwidth) coverage in
Africa than hard wired.  Pick a  market segment and make it your own.
That's the route to success.  “Whatever you are, be a good one”

On the specifics of Metalsmith and as a user of JSPWiki, I vote no.  Why
rip out the heart of what already kinda works, to replace it with a static
meta data driven tool?  Don’t forget that static web sites are just a fad
like the old thick /thin client-server debate.  It’ll pass so just stick
with what you know.  The technology is not the issue here.  That’s just
simple code.  The vision is the issue.
JSPWiki doesn’t have to copy.  JSPWiki could lead.

On 21 November 2016 at 19:43, Dave Koelmeyer <
dave.koelme...@davekoelmeyer.co.nz> wrote:

> Nuxeo is a major open source enterprise documentation management system
> product. Their developer team recently migrated all documentation from
> Confluence to a static site generator. While not related directly to
> JSPWiki, the reasons why they switched are interesting, and it's not
> every day one hears about a switch from the Microsoft Office of wikis:
>
> https://www.nuxeo.com/blog/from-confluence-to-metalsmith-
> a-migration-story-of-nuxeo-docs/
>
> This could provide some insight into potential features for JSPWiki down
> the line.
>
> Cheers,
> Dave
>
> --
> Dave Koelmeyer
> http://blog.davekoelmeyer.co.nz
> GPG Key ID: 0x238BFF87
>
>

Re: Container-managed auth security issue?

[Paul Uszak]

I get similarly weird behaviour but not exactly identical.  My strangest
effects are that I can't log out. If I log out, then just browse back I'm
logged back in. I also can't log in cleanly as I always get the "you can't
do that" page, but then I'm logged in. I can't get to the JSPWiki log in
page at all, just the realm basic dialogue.  If I ever try to cancel a
login dialogue I just get a Server 500 error that never goes away until I
close the browser.

I think that Access Control List x JSPWiki security x Container security x
individual JSP page granularity is just too complicated, both to manage or
debug.  There probably aren't enough deployments to identify /document
/debug all possible use cases. I'm not sure what the answer might be other
than an authorisation mechanism rethink.  I suspect that the ratio of
installations to security complexity is such that most people have some
sort of problem.

Prayer: Please God, don't add MySql support as that will just make it a
total nightmare with it's dumb ass port /socket & location based
authorisation model on top of the wiki's.


On Saturday, 20 February 2016, Dave Koelmeyer <
dave.koelme...@davekoelmeyer.co.nz> wrote:

> Hi All,
>
> I've stumbled across some rather interesting behaviour which I'd like to
> know if someone else can replicate, and, if this is expected with my setup.
>
> I'm running JSPWiki v2.10.2-svn-38 with container-managed
> authentication, with user accounts provisioned using a file-based
> security realm in Payara Server 4.1. My JSPWiki policy file has been
> deliberately locked down such that only authenticated users can view
> content.
>
> The userdatabase.xml file contains the following only, as one would expect:
>
> 
> 
>  wikiName="Administrator" fullName="Administrator" email=""
> password="{SSHA}somepassword" created="2016.02.20 at 23:11:59:610 NZDT"
> lastModified="2016.02.20 at 23:11:59:610 NZDT" lockExpiry="" >
> 
> 
>
> To test the installation is secure a user performs the following:
>
>  1. Navigate to the JSPWiki login screen
>  2. Click on ["Don't have account?"] "Join JSPWiki now!
>  3. On the "Register a new user!" page, enter a random Name and email
> address, and click "Create a new user profile". The account cannot
> be created.
>
>
> Now, leaving this browser tab as-is, open a second browser tab.
> Authenticate to JSPWiki as an authorised user. Next, switch back to the
> original tab. Repeat step 3 above. The session logs you in. Under "User
> Preferences -> Profile" for the logged-in user, the "Name" and "Email
> address" values have changed to what was set in step 3 above. The "Login
> name" however is still the account derived from the Payara security realm.
>
> Now, if one inspects the userdatabase.xml file, a new entry *has* been
> created. In the following example "derekz" is set in the file-based
> security realm, whereas "Alex" is the name set when registering the new
> user account directly:
>
>   fullName="Alex" email="a...@example.com " password=""
> created="2016.02.2
> 0 at 23:28:59:268 NZDT" lastModified="2016.02.20 at 23:28:59:268 NZDT"
> lockExpiry="" >
> 
> 
>
> So what gives? Something tells me this perhaps shouldn't be working
> quite like this, even with the unlikely scenario of attempting to
> register a new user when the same authorised user is already authenticated.
>
> Cheers,
> Dave
>
> --
> Dave Koelmeyer
> http://blog.davekoelmeyer.co.nz
> GPG Key ID: 0x238BFF87
>
>

Re: JSPWiki on Facebook

[Paul Uszak]

Sorry Dave, but is there a faux pas?  WordPress?  Best not to advertise a
more successful competing product on your own site...

On Friday, 26 February 2016, Siegfried Goeschl <
siegfried.goes...@it20one.com> wrote:

> Hi Dave,
>
> it looks nice :-)
>
> Thanks for your effort
>
> Siegfried Goeschl (not a Facebook user)
>
> > On 24 Feb 2016, at 02:40, Dave Koelmeyer <
> dave.koelme...@davekoelmeyer.co.nz > wrote:
> >
> > Hi All,
> >
> > I've now made a Page on Facebook:
> >
> > https://www.facebook.com/ApacheJSPWiki/
> >
> >
> > I've added Janne as a co-admin, and to safeguard against not having
> > access to the account down the line if any of the core devs would also
> > like to be added as page admins please drop me a line.
> >
> > Cheers,
> > Dave
> >
> > --
> > Dave Koelmeyer
> > http://blog.davekoelmeyer.co.nz
> > GPG Key ID: 0x238BFF87
> >
>
>

Re: A way to find dead links for external pages

[Paul Uszak]

What security issues does this present?

Remember, the link targets have been selected by the wiki authors so they
are desirable links rather than spam.  I can't quite see a threat model if
all you're doing is reporting a HTTP status code.  Isn't this what search
engines do by default?

On 4 January 2016 at 06:27, Derek Hohls  wrote:

> There seem to be any number of tools out there... have you seen:
> https://wummel.github.io/linkchecker/
> (showing my bias towards Python)
>
> >>> Foster Schucker  12/28/15 8:39 PM >>>
> Thanks. I didn't think there was a way in JSPWiki to do that. I was on
> the look for a tool that was smart enough to do the walk and only report
> back on external sites/links. I figured with the number of people on
> this list that do that I could get a quick recommendation of a tool that
> someone liked.
>
> Thanks!
>
> Foster
> On Mon, 28 Dec 2015 19:09:43 +0100, Harry Metske
>  wrote:
>
> There has been a discussion about this before:
> https://issues.apache.org/jira/browse/JSPWIKI-330
>
> We considered it a security risk and did not implement it.
>
> kind regards,
> Harry
>
>
> On 28 December 2015 at 16:14, Foster Schucker 
> wrote:
>
> > I have a wiki that ties into external sites. As these places
> switch to
> > new platforms the old links die. (Or they die due to refactoring).
> >
> > Anyway I'm looking for a way to walk the wiki pages and see if
> there is a
> > 200 response back from the other side. I'm guessing one of you
> have had to
> > do this before, no sense in reinventing the wheel.
> >
> > In a perfect world it would spit out [PageName] URL ResponseCode
> for each
> > URL (that would let me catch other errors like forbidden, etc.
> but I'd be
> > happy to get the ones that don't produce a 200.
> >
> > Thanks!
> > Foster
> >
> >
>
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
> This message has been scanned for viruses and dangerous content by
> MailScanner,
> and is believed to be clean.
>
> Please consider the environment before printing this email.
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
>
> This message has been scanned for viruses and dangerous content by
> *MailScanner* ,
> and is believed to be clean.
>
>
> Please consider the environment before printing this email.
>
>

Can't log out properly

[Paul Uszak]

Hi.

Getting to grips with the wiki, and have set up container based
security in Tomcat. I'n using version 2.10.1 with Tomcat 7.

I have a problem in that I can't log out properly when I finish.  I
log in with full admin rights.  I can click log out, and it looks as
if I've logged out.  BUT, if I then click something like 'edit', I
automatically get logged back in .  I get a warning -

Forbidden

Sorry, but you are not allowed to do that.


when I log in the first time.  Should I get this warning?

It seems as if the password security stuff isn't quite gelling
together.  All the security is via a security realm in web.xml.  Do I
have to set security up elsewhere please?  I'm worried as I want to
use the wiki in an internet facing situation.  Thanks.