Re: Plugins in a mardown flowered wiki

[Juan Pablo Santos Rodríguez]

Hi Peter,

as per [#1], it should work, and if it doesn't, then it's a bug, there
are tests checking one line plugin invocations, but not for plugins
with body. Does the log yield something regarding the plugin
invocation?

The other only thing that comes to mind is that the plugin must be a
markdown link, so perhaps the markdown is missing a () at the end?


best regards,
juan pablo

[#1]: 
https://github.com/apache/jspwiki/blob/master/jspwiki-markdown/src/main/java/org/apache/wiki/markdown/extensions/jspwikilinks/postprocessor/PluginLinkNodePostProcessorState.java#L74-L76

On Fri, Jul 19, 2024 at 7:31 PM Peter Hormanns
 wrote:
>
> Dear JSPWiki-Community,
>
> I have a question about plugins, in a JSPWiki that uses Markdown as
> markup language.
>
> I could use plugins that use simple parameters as key-value pairs. But I
> could not use plugins where the call line or the plugin body is
> evaluated. Is there a chance?
>
> In WikiMarkup I would use:
>
> [{WikiTags HashTagOne HashTagTwo OtherHasTag}]
>
> or
>
> [{WikiCSS
>
> html {
>  font-family: Lato,sans-serif;
>  font-size: 16px;
>  color: #666;
>   }
> }]
>
> Is it posible to use plugins like that in markdown?
>
> 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: SampleAjaxPlugin problem

[Juan Pablo Santos Rodríguez]

Hi Ulf,

That's a bug :-/ Plugin has been unchanged mostly since developed, and the
js should be available right away. Would you mind raising a jira for that?
Or even better, a PR? O:-)

Best regards,
juan pablo

El mar, 9 jul 2024, 9:43, Ulf Dittmer 
escribió:

> I just stumbled upon
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=SampleAjaxPlugin, which
> looks
> interesting. It's broken, though, as it needs jspwiki-common.js
> (specifically the ajaxHtmlCall method), which isn't included in that page.
>
> How do I force jspwiki-common.js to be included in a page? Or are
> mooTools-based solutions generally not the right approach these days, given
> its apparent obsolescence?
>
> Thanks
> Ulf
>

Re: wysiwyg editor replacement

[Juan Pablo Santos Rodríguez]

Hi,

yup, I've just seen it has been discontinued on 2017 :-/ IIRC, it was
chosen b/c it was written with mootools which is(was?) heavily used by
JSPWiki then, but surely Dirk knows far better. As js is not my strong
suit, I don't have any experience with any of the editors listed on
the link you've provided, but if you have had eany experience with any
of them I'd be happy to hear


best regards,
juan pablo

On Fri, Jul 5, 2024 at 1:15 PM Alex O'Ree  wrote:
>
> any thoughts on potentially replacing the wysiwyg editor? seems like it's
> using a library that hasn't been touched in almost ten years. it definitely
> has some issues and perhaps an alternate solution might improve the user
> experience.
> I found a bunch of potentials here:
> https://github.com/JefMari/awesome-wysiwyg-editors/blob/master/readme.md

Re: WikiFormsPlugin with file input?

[Juan Pablo Santos Rodríguez]

Hi!

first message did get sent, in my case wasn't unable to answer back until now.

CsrfProtectionFilter[#1] is a filter that is put in place to avoid
CSRF attacks. It basically expects to find a hidden input field
carrying the user's session id, so all of our forms carry a custom
tag[#2] (eg. [#3]) that does precisely that. AttachmentTab[#4]
contains a multipart form, contains the tag and works. If you got that
message, it means that either the WikiSession doesn't the csrf token
or it isn't present on the request. As the first  is generated on
WikiSession creation, what parameters come with the request? perhaps
the requestContainsValidCsrfToken method on CsrfProtectionFilter needs
further refinement for this kind of cases?

HTH,
juan pablo


[#1]: 
https://github.com/apache/jspwiki/blob/master/jspwiki-http/src/main/java/org/apache/wiki/http/filter/CsrfProtectionFilter.java
[#2]: 
https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/main/java/org/apache/wiki/tags/CsrfProtectionTag.java
[#3]: 
https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/webapp/templates/default/InfoContent.jsp#L123
[#4]: 
https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/webapp/templates/default/AttachmentTab.jsp#L47

On Fri, Jul 5, 2024 at 12:40 PM Ulf Dittmer
 wrote:
>
> Hi-
>
> I haven't actually seen this message go out to the mailing list, but I've
> come a bit further in implementing this - which, naturally, throws up
> different problems :-)
>
> So far I have 1) extended FormUtil to handle file uploads (using Apache
> Commons FileUpload), and 2) extended FormOpen to take an "enctype"
> parameter (because forms containing file uploads need multipart/form-data).
>
> At this point, the form submit causes an "o.a.w.h.f.CsrfProtectionFilter -
> Incorrect X-XSRF-TOKEN param with value 'null' received for null" error,
> even though the CSRF token is present and submitted. My guess is that the
> form handling by the FileUpload library somehow interferes with CSRF token
> handling, although I can't imagine how.
>
> Can anyone provide some idea of what might be (or might not be) going on?
>
> Thanks
> Ulf
>
> -- Forwarded message -
> From: Ulf Dittmer 
> Date: Wed, Jul 3, 2024 at 9:58 AM
> Subject: WikiFormsPlugin with file input?
> To: 
>
>
> I want to implement a simple file upload solution for users of a JSPWiki
> site, and was wondering what the easiest way to go about this might be. The
> FormInput plugin can create file input elements, but obviously that won't
> work as the parameters are passed in a Map.
>
> Has anyone implemented something like this, or is aware of
> a WikiFormsPlugin extension that can do this?
>
> The end result would be a simple way for users to upload files along with
> keywords for a simple file storage and retrieval solution. The files would
> not be associated to particular pages, so using attachments would not
> really work.
>
> Thanks
> Ulf

Re: problematic CalendarTag <-> WeblogPlugin interaction

[Juan Pablo Santos Rodríguez]

and merged just now for 2.12.3-git-01 :-)

thanks!

On Mon, Jun 24, 2024 at 10:27 AM Ulf Dittmer
 wrote:
>
> Rull request created: https://github.com/apache/jspwiki/pull/350
>
> On Sun, Jun 23, 2024 at 12:43 PM Ulf Dittmer 
> wrote:
>
> > Thanks Dirk, I wasn't aware of the findFreeEntry method. It basically
> > confirms that there is no built-in method to search for pages by pattern,
> > and that a linear search must be employed. Practically, I think checking
> > the first 10 or so would be sufficient, as it would be highly unusual to
> > write more than 10 blog entries on any given day, and then to delete most
> > of them.
> >
> > I'll see what I can come up with.
> >
> > Ulf
> >
> > On Sat, Jun 22, 2024 at 10:35 PM Dirk Frederickx <
> > dirk.frederi...@gmail.com> wrote:
> >
> >> Ulf,
> >>
> >> The problem seems to be in o.a.w.tags/CalenderTag.java  in getDayLink().
> >>
> >> It only checks for the page with the pattern
> >> ${param.page}_blogentry_'ddMMyy'_1
> >> ;  which has the suffix "_1".
> >>
> >> I guess it should actually also check for the existence of pages with a
> >> higher _nn.
> >> It should stop at MAX_BLOG_ENTRIES (now set tot 10_000), but that would be
> >> performance wise not realistic.
> >> Better would be to check for the existence of pages starting with the
> >> pattern ${param.page}_blogentry_'ddMMyy'_ followed by a /\d+/.
> >> Possibly you can find inspiration in  o.a.w.plugin/WeblogEntryPlugin in
> >> findFreeEntry()   which is used to create new entries.
> >>
> >>
> >> Grtz
> >>   dirk
> >>
> >> On Fri, Jun 21, 2024 at 10:15 AM Ulf Dittmer
> >>  wrote:
> >>
> >> > The CalendarTag, when deciding whether to link a particular day, assumes
> >> > that the presence or absence of a page "..._blogentry_'ddMMyy'_1'
> >> indicates
> >> > whether there are weblog entries for a given day (this is in
> >> Sidebar.jsp).
> >> >
> >> > The problem is, if the first entry on that day (the one with ..._1) is
> >> > deleted, others on that day (..._2 etc.) are not checked, and so that
> >> day
> >> > is not linked.
> >> >
> >> > You can see this on
> >> >
> >> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Haddock%20Weblog%20Example
> >> > I created two blog entries, and then deleted the first one. Today's date
> >> > (June 21) should still be highlighted and linked because of the second
> >> > entry, but it isn't.
> >> >
> >> > I'm not asking for this to be fixed, I'm just looking for advice on what
> >> > the best approach would be. If there's a reasonable solution, I'd be
> >> happy
> >> > to work on that and contribute it.
> >> >
> >> > Ulf
> >> >
> >>
> >

Re: Bad signature for jspwiki-wikipages-de-2.12.2.zip

[Juan Pablo Santos Rodríguez]

Hi Florian,

seems that the old files weren't deleted, the re-uploaded artifact
with the corrected signature would be
https://archive.apache.org/dist/jspwiki/2.12.2/wikipages/jspwiki-wikipages-de-2.12.2-jspwiki.zip
with
https://archive.apache.org/dist/jspwiki/2.12.2/wikipages/jspwiki-wikipages-de-2.12.2-jspwiki.zip.asc
(notice the jspwiki suffix which isn't present on the previous link)

it's probably matter of deleting the files with the changed name /
invalid signatures from the release area


cheers,
juan pablo

On Fri, Jun 28, 2024 at 7:27 PM Arturo Bernal  wrote:
>
> Cheking
>
> Arturo
>
>
> On Fri, Jun 28, 2024 at 6:47 PM Florian Preinstorfer <
> lists-jspw...@nblock.org> wrote:
>
> > Hi,
> > Am 2024-06-26 19:09, schrieb Arturo Bernal:
> > >I apologize for the confusion and any inconvenience caused by the
> > >invalid signatures. If you encounter any further issues or have any
> > concerns,
> > >please do not hesitate to reach out.
> >
> > I just tried to verify
> >
> > https://archive.apache.org/dist/jspwiki/2.12.2/wikipages/jspwiki-wikipages-de-2.12.2.zip
> > with
> >
> > https://archive.apache.org/dist/jspwiki/2.12.2/wikipages/jspwiki-wikipages-de-2.12.2.zip.asc
> > and get
> >
> >gpg: BAD signature from "Arturo Bernal " [unknown]
> >
> > The timestamps show on the index page seem to be unchanged (at least for
> > jspwiki-wikipages-de-2.12.2.zip and jspwiki-wikipages-de-2.12.2.zip.asc
> >
> > Best,
> > Florian
> >

Re: Bad signature for jspwiki-wikipages-de-2.12.2.zip

[Juan Pablo Santos Rodríguez]

Thanks! :-)

El mié, 26 jun 2024, 19:09, Arturo Bernal  escribió:

> Hi Florian, Juan Pablo, and all,
>
> I wanted to inform you that I have updated the documentation and replaced
> the files with signature issues. The problematic GPG signatures have been
> corrected, and the affected files have been re-uploaded.
>
> Here is a summary of the actions taken:
>
>1. Verified and corrected the signatures for the problematic artifacts.
>2. Re-uploaded the corrected artifacts and their signatures to SVN.
>
> I apologize for the confusion and any inconvenience caused by the invalid
> signatures. If you encounter any further issues or have any concerns,
> please do not hesitate to reach out.
>
> Best regards,
> Arturo
>
>
> On Tue, Jun 25, 2024 at 11:38 AM Arturo Bernal  wrote:
>
> > Hi All,
> >
> > I'm okay with not doing a new release and instead replacing the files
> that
> > have signature issues.
> >
> >
> > Arturo
> >
> >
> > On Mon, Jun 24, 2024 at 9:57 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> >> Hi!
> >>
> >> my bad: gpg --keyserver hkps://pgp.mit.edu/ --recv-keys 2D51AAC6 did
> >> not return the key, but gpg --keyserver hkps://keyserver.ubuntu.com
> >> --recv-keys 2D51AAC6 did.
> >>
> >> Done that, I've checked the sigs and basically the ones on the
> >> wikipages folder are the ones giving trouble. In this release, the
> >> name from the wikipages artifacts changed from
> >> jspwiki-wikipages-$LANG-2.12.2.zip to
> >> jspwiki-wikipages-$LANG-2.12.2-jspwiki.zip, so perhaps the name change
> >> has to do with this error? Also the markdown zip don't contain the asc
> >> files. I think they were added on a second pass during the release
> >> vote, so maybe that's why there aren't the asc fils (if they aren't
> >> b/c those zips get autogenerated we can fix that on the next release).
> >> Also I copied a bunch of convenience jars on binaries/webapp that were
> >> lacking their signatures. Also my bad for copying them without
> >> checking first.
> >>
> >> As for a new release, given that
> >> ./source/jspwiki-builder-2.12.2-source-release.zip contains a valid
> >> signature I wouldn't go for a new release. This is *the* release file,
> >> the important one, whereas the rest are just convenience binaries, so
> >> I think is ok if we fix the sigs directly at svn. For the wikipages it
> >> should be as easy as
> >>
> >> git checkout 2.12.2
> >> cd jspwiki-wikipages
> >> mvn clean install gpg:sign
> >>
> >> and then just copy the files and sigs. Same could be done for the
> >> other convenience jars too
> >>
> >> makes sense? Does anyone thinks that this should warrant a 2.12.3
> >> release, just in any case? If anybody is uncomfortable with proceeding
> >> like above we can always go with 2.12.3 and fix it there.
> >>
> >>
> >> cheers,
> >> juan pablo
> >>
> >> On Mon, Jun 24, 2024 at 7:56 PM Arturo Bernal 
> wrote:
> >> >
> >> >   Hi,
> >> >
> >> > The key is available (gpg --list-keys --fingerprint 2D51AAC6), but I
> >> don't
> >> > think that will solve the issue. It seems that I might have generated
> >> the
> >> > signature incorrectly.
> >> >
> >> > I checked and, yes, there are binaries that were signed correctly.
> >> > Verification worked for jspwiki-portable-2.12.2-woas.zip with
> >> > jspwiki-portable-2.12.2-woas.zip.asc.
> >> >
> >> >
> >> >
> >> > Best regards,
> >>
> >
>

Re: Bad signature for jspwiki-wikipages-de-2.12.2.zip

[Juan Pablo Santos Rodríguez]

Hi!

my bad: gpg --keyserver hkps://pgp.mit.edu/ --recv-keys 2D51AAC6 did
not return the key, but gpg --keyserver hkps://keyserver.ubuntu.com
--recv-keys 2D51AAC6 did.

Done that, I've checked the sigs and basically the ones on the
wikipages folder are the ones giving trouble. In this release, the
name from the wikipages artifacts changed from
jspwiki-wikipages-$LANG-2.12.2.zip to
jspwiki-wikipages-$LANG-2.12.2-jspwiki.zip, so perhaps the name change
has to do with this error? Also the markdown zip don't contain the asc
files. I think they were added on a second pass during the release
vote, so maybe that's why there aren't the asc fils (if they aren't
b/c those zips get autogenerated we can fix that on the next release).
Also I copied a bunch of convenience jars on binaries/webapp that were
lacking their signatures. Also my bad for copying them without
checking first.

As for a new release, given that
./source/jspwiki-builder-2.12.2-source-release.zip contains a valid
signature I wouldn't go for a new release. This is *the* release file,
the important one, whereas the rest are just convenience binaries, so
I think is ok if we fix the sigs directly at svn. For the wikipages it
should be as easy as

git checkout 2.12.2
cd jspwiki-wikipages
mvn clean install gpg:sign

and then just copy the files and sigs. Same could be done for the
other convenience jars too

makes sense? Does anyone thinks that this should warrant a 2.12.3
release, just in any case? If anybody is uncomfortable with proceeding
like above we can always go with 2.12.3 and fix it there.


cheers,
juan pablo

On Mon, Jun 24, 2024 at 7:56 PM Arturo Bernal  wrote:
>
>   Hi,
>
> The key is available (gpg --list-keys --fingerprint 2D51AAC6), but I don't
> think that will solve the issue. It seems that I might have generated the
> signature incorrectly.
>
> I checked and, yes, there are binaries that were signed correctly.
> Verification worked for jspwiki-portable-2.12.2-woas.zip with
> jspwiki-portable-2.12.2-woas.zip.asc.
>
>
>
> Best regards,

Re: Bad signature for jspwiki-wikipages-de-2.12.2.zip

[Juan Pablo Santos Rodríguez]

Hi,

I did try yesterday and got "Can't check signature: public key not found"
(the artifacts are signed with RSA ID 2D51AAC6). Did you send your GPG key
to the default gpg server? Perhaps doing

gpg --send-key 2D51AAC6

is enough to solve the issue? Same thing happens when checking 2.12.1
artifacts, so not sure that a new release will be enough to fix this
problem :-?

HTH,
juan pablo

El lun, 24 jun 2024, 11:30, Arturo Bernal  escribió:

> Hi all,
>
> I've reviewed the .war and source files, and they appear to be in order.
> However, I'm unsure what might have caused the GPG signature to be invalid.
>
> To resolve this issue comprehensively, I propose generating a new version
> from scratch. I will prepare a version 2.12.3 that addresses all potential
> issues.
>
> what do you think?
>
> Best regards,
>
> Arturo
>
>
> On Sat, Jun 22, 2024 at 6:05 PM Arturo Bernal  wrote:
>
> > Hi,
> >
> > Let me check.
> >
> > Cheers
> >
> >
> > Arturo
> >
> >
> > On Sat, Jun 22, 2024 at 6:03 PM Florian Preinstorfer <
> > lists-jspw...@nblock.org> wrote:
> >
> >> Hi,
> >> it seems the GPG signature for jspwiki-wikipages-de-2.12.2.zip is
> >> invalid:
> >>
> >>wget -q
> >>
> https://archive.apache.org/dist/jspwiki/2.12.2/wikipages/jspwiki-wikipages-de-2.12.2.zip
> >>wget -q
> >>
> https://archive.apache.org/dist/jspwiki/2.12.2/wikipages/jspwiki-wikipages-de-2.12.2.zip.asc
> >>
> >>gpg --verify jspwiki-wikipages-de-2.12.2.zip.asc
> >>gpg: assuming signed data in 'jspwiki-wikipages-de-2.12.2.zip'
> >>gpg: Signature made Wed Jun 12 21:52:44 2024 CEST
> >>gpg:using RSA key
> >> C650FF7A0C0817441BAC320743B5E9442D51AAC6
> >>gpg: BAD signature from "Arturo Bernal "
> [unknown]
> >>
> >> Best,
> >> Florian
> >>
> >
>

CVE-2024-27136: Apache JSPWiki: Cross-site scripting vulnerability on upload page

[Juan Pablo Santos Rodríguez]

Severity: moderate

Affected versions:

- Apache JSPWiki through 2.12.1

Description:

XSS in Upload page in Apache JSPWiki 2.12.1 and priors allows the
attacker to execute javascript in the victim's browser and get some
sensitive information about the victim.  Apache JSPWiki users should
upgrade to 2.12.2 or later.

Credit:

This issue was discovered by sonnh from Vietnam National Cyber
security technology corporation (finder)

References:

https://jspwiki.apache.org/
https://www.cve.org/CVERecord?id=CVE-2024-27136
https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2024-27136

Re: Time To Move To Jakarta EE

[Juan Pablo Santos Rodríguez]

Hi!

IIRC, there's one default method on the public API (Engine?) that
relies on javax.servlet. Not that it would break any existing plugin
or filter, but it's part of the public API anyway. And maybe from the
Session you could grab the http session as well, I'd have to look to
be sure. Regarding the migration, it shouldn't be much more than
changing imports, but we'll see when we are there

In any case, going to JDK-17 and requiring a new major version of
Tomcat, or whichever, would be a stronger reason to name it 3.0. I
remember the attempt at 3.0, but given the amount of time that has
passed I think it would be ok to stick with it. At least, I'd find
weird the change from 2.12 to 4.0 out of the blue.


cheers,
juan pablo

On Thu, May 30, 2024 at 6:27 PM Foster Schucker  wrote:
>
> I've been a JSP Wiki user since the early days.  I'd also suggest going
> to 3.0 or 4.0 for a change like this.
>
> /Tomcat, Openliberty and JBoss EAP 8 are fine with 17, I hope all
> applications do, too.///
> My office has a sign "Hope is not an engineering strategy"  :-)
>
> Thanks!
> Foster
>
>
>

Re: Time To Move To Jakarta EE

[Juan Pablo Santos Rodríguez]

Hi Jürgen!

I wholeheartedly agree :-) As this would be a major release (JSPWiki
3.0.0), perhaps we should follow the path of other oss projects and
lift the JDK requirement to 17 as well?


best regards,
juan pablo

On Mon, May 27, 2024 at 10:00 AM Jürgen Weber  wrote:
>
> Hi jspwiki users,
>
> time is up for javax.
>
> The last javax Tomcat 9 is 89 minor versions old.
>
> Wildfly 26 was the last to support javax. Current is 32.
>
> JSPWiki should move on to Jakarta EE.
>
> Let's sed javax to jakarta and release.
>
> Support of Jakarta EE 9
> https://issues.apache.org/jira/browse/JSPWIKI-1170
>
> Cheers,
> Juergen

User account creation temporarily locked at jspwiki-wiki.a.o due to recent spamming

[Juan Pablo Santos Rodríguez]

Hi,

as can be seen by the recent changes page, this eastern we've had some
heavy, most probably automated spam at jspwiki-wiki.a.o. Basically all
of the dirt consisted on automated ways of seeking vulnerabilities
(xss, database tampering, session hijacking, etc.). Luckily all of
these vectors of attacks were previously reported and fixed, so
nothing serious ended up happening.

However, there was a LOT of dirt that have to be manually removed. To
avoid further situations like this, user account creation has been
temporarily locked (userdatabase.xml has been made read only), and
offending users removed, with the idea being to moderate user account
creation, via workflow approval, and putting a policy to forbid page
edition for anonymous users as well. Most defaced pages now have an
ACL in place to allow edition only to users on Gardener or Admin
groups, which will be applied as time permits to the documentation
pages.

Anyone wishing to improve the documentation is more than welcome, just
please state on this list that you wish to be added to the Gardener
group, or that you do want to improve our documentation and we'll
gladly add you to this group.

We'll note all of this on jspwiki-wiki.a.o and also here as soon as
we're able to put in place the long-run solution. Of course, any other
idea on how to proceed with this situation, and on how to balance it
with regular users wishing to improve the wiki is more than welcome,
please do answer back on list


best regards,
juan pablo

Re: is there administrative features?

[Juan Pablo Santos Rodríguez]

Hi Alex,

IIRC, there isn't support for that, would you mind opening jira ticket with
this, so it can be tackled later on?

As an alternative, you can provide the properties as environment variables,
where you can compose them based on other env. variables.


HTH,
juan pablo

El jue, 28 mar 2024, 18:15, Alex O'Ree  escribió:

> For the jsp wiki properties file, is there a syntax for referencing a
> system property?
> for example, i want to store wiki content in ${catalina.base}/wiki would
> should resolve to something like c:\tomcat\wiki as a sibling directory to
> conf, webapps, bin, etc
>
> I don't particularly want to put a full path in the config file
>
> On Wed, Mar 20, 2024 at 7:33 PM Alex O'Ree  wrote:
>
> > Thanks for the info
> >
> > On Wed, Mar 20, 2024, 6:49 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> >> Hi!
> >>
> >> regarding tomcat/lib, it's just a place on classpath outside the
> >> jspwiki war. that way you can upgrade your JSPWiki version without
> >> needing any war surgery. But really, any place on classpath is fine to
> >> get your jspwiki-custom.properties file read,
> >>
> >> As for themes, JSPWiki has the notion of "templates", a group of JSP
> >> files that render JSPWiki appereance. There is a default template, and
> >> there are some JSP files to be expected on your template; if they
> >> aren't found, they're read from the default template. Tipically you
> >> provide some styles on customheader.jsp (or something like that, don't
> >> recall the exact name now and don't have the code at hand), and
> >> usually that's enough to customize the overall appeareance, although
> >> you can completely modify the UI.
> >>
> >> As for the default template, it supports changing appearance
> >> (light/dark), but also "themes", f.ex., Dark [#1] or clean blue [#2]
> >> themes. They're another way to change (overall) styling, but they
> >> don't require a property on your jspwiki-custom file. Search for theme
> >> at jspwiki-wiki.a.o and you'll get some more info and additional
> >> themes there.
> >>
> >>
> >> HTH,
> >> juan pablo
> >>
> >> [#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Dark%20Theme
> >> [#2] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Clean%20Blue%20Theme
> >>
> >> On Mon, Mar 18, 2024 at 1:43 AM Alex O'Ree  wrote:
> >> >
> >> > great info, thanks
> >> >
> >> > is there a reason for using the tomcat/lib folder for storing config
> >> file?
> >> > I feel like it should be in the war/WEB-INF/classes location instead.
> >> >
> >> > i see that there's different themes available, but it's not clear to
> use
> >> > them within the webapp beside light/dark mode. The docs for changing
> >> themes
> >> > doesn't seem to correlate with the latest version. Ref
> >> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=CustomUserPreferences
> >> >
> >> > On Sun, Mar 17, 2024 at 7:06 PM Juan Pablo Santos Rodríguez <
> >> > juanpablo.san...@gmail.com> wrote:
> >> >
> >> > > Hi!
> >> > >
> >> > > Regarding using the database, yup, It doesn't matter, your instances
> >> should
> >> > > share db, wiki working dir and cache. The important bit is the
> >> working dir,
> >> > > there's were the index files are.
> >> > >
> >> > > Regarding the cache, latest master brings support for custom events
> >> > > listeners [#1], which should be the entry point you're looking for.
> >> Bear on
> >> > > mind that you'll have to code it. And it'll be GA on upcoming
> 2.12.2.
> >> > >
> >> > > Also, Ehcache can be configured to have a shared cache, using a
> >> multicast
> >> > > address, so perhaps that's easier to set upthan going through the
> >> messaging
> >> > > route?
> >> > >
> >> > >
> >> > > Best regards,
> >> > > juan pablo
> >> > >
> >> > >
> >> > >
> >> > > [#1]
> >> > >
> >> > >
> >>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToWriteACustomWikiEventListener
> >> > >
> >> > > El dom, 17 mar 2024, 23:31, Alex O'Ree 
> >> escribió:
> >> > >
> >>

Re: is there administrative features?

[Juan Pablo Santos Rodríguez]

Hi!

regarding tomcat/lib, it's just a place on classpath outside the
jspwiki war. that way you can upgrade your JSPWiki version without
needing any war surgery. But really, any place on classpath is fine to
get your jspwiki-custom.properties file read,

As for themes, JSPWiki has the notion of "templates", a group of JSP
files that render JSPWiki appereance. There is a default template, and
there are some JSP files to be expected on your template; if they
aren't found, they're read from the default template. Tipically you
provide some styles on customheader.jsp (or something like that, don't
recall the exact name now and don't have the code at hand), and
usually that's enough to customize the overall appeareance, although
you can completely modify the UI.

As for the default template, it supports changing appearance
(light/dark), but also "themes", f.ex., Dark [#1] or clean blue [#2]
themes. They're another way to change (overall) styling, but they
don't require a property on your jspwiki-custom file. Search for theme
at jspwiki-wiki.a.o and you'll get some more info and additional
themes there.


HTH,
juan pablo

[#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Dark%20Theme
[#2] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Clean%20Blue%20Theme

On Mon, Mar 18, 2024 at 1:43 AM Alex O'Ree  wrote:
>
> great info, thanks
>
> is there a reason for using the tomcat/lib folder for storing config file?
> I feel like it should be in the war/WEB-INF/classes location instead.
>
> i see that there's different themes available, but it's not clear to use
> them within the webapp beside light/dark mode. The docs for changing themes
> doesn't seem to correlate with the latest version. Ref
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=CustomUserPreferences
>
> On Sun, Mar 17, 2024 at 7:06 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi!
> >
> > Regarding using the database, yup, It doesn't matter, your instances should
> > share db, wiki working dir and cache. The important bit is the working dir,
> > there's were the index files are.
> >
> > Regarding the cache, latest master brings support for custom events
> > listeners [#1], which should be the entry point you're looking for. Bear on
> > mind that you'll have to code it. And it'll be GA on upcoming 2.12.2.
> >
> > Also, Ehcache can be configured to have a shared cache, using a multicast
> > address, so perhaps that's easier to set upthan going through the messaging
> > route?
> >
> >
> > Best regards,
> > juan pablo
> >
> >
> >
> > [#1]
> >
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToWriteACustomWikiEventListener
> >
> > El dom, 17 mar 2024, 23:31, Alex O'Ree  escribió:
> >
> > > > they should be possible as long as you shared your "wiki work dir"
> > >
> > > Is this true, even when a database storage solution?
> > >
> > > > Also, by default  there's a caching layer in front of the file system
> > > access to pages
> > > and attachments, ehcache based.
> > >
> > > Is there perhaps a server side API that i can use to detect a change?
> > > And to trigger the cache invalidation?
> > > I have a kafka setup in the environment and...in theory...if i can detect
> > > the change, i can send a kafka topic message trigger the invalidation for
> > > all of the instances
> > >
> > >
> > > On Sun, Mar 17, 2024 at 5:43 PM Juan Pablo Santos Rodríguez <
> > > juanpablo.san...@gmail.com> wrote:
> > >
> > > > Hi Alex!
> > > >
> > > > regarding rolling upgrades / load balancing, they should be possible
> > > > as long as you shared your "wiki work dir" (containing f.ex., lucene
> > > > indexes) and your wiki pages/attachment filesystem. Also, by default
> > > > there's a caching layer in front of the file system access to pages
> > > > and attachments, ehcache based. That should be tuned too in order to
> > > > share the cache among your wiki instances.
> > > >
> > > > As for the wiki installation, the wiki page dir you note on the
> > > > installation is the path were the wiki pages should be extracted. I
> > > > don't have the installation page on my head now, so perhaps the
> > > > behaviour is different.. Also, I noticed you opened a ticket a few
> > > > days ago regarding installation, so there's also that (I'll try to
> > > > look at it thie week btw).
> > > >
> > > > Last, regarding container based authentication, it'

Re: is there administrative features?

[Juan Pablo Santos Rodríguez]

Hi!

Regarding using the database, yup, It doesn't matter, your instances should
share db, wiki working dir and cache. The important bit is the working dir,
there's were the index files are.

Regarding the cache, latest master brings support for custom events
listeners [#1], which should be the entry point you're looking for. Bear on
mind that you'll have to code it. And it'll be GA on upcoming 2.12.2.

Also, Ehcache can be configured to have a shared cache, using a multicast
address, so perhaps that's easier to set upthan going through the messaging
route?


Best regards,
juan pablo



[#1]
https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToWriteACustomWikiEventListener

El dom, 17 mar 2024, 23:31, Alex O'Ree  escribió:

> > they should be possible as long as you shared your "wiki work dir"
>
> Is this true, even when a database storage solution?
>
> > Also, by default  there's a caching layer in front of the file system
> access to pages
> and attachments, ehcache based.
>
> Is there perhaps a server side API that i can use to detect a change?
> And to trigger the cache invalidation?
> I have a kafka setup in the environment and...in theory...if i can detect
> the change, i can send a kafka topic message trigger the invalidation for
> all of the instances
>
>
> On Sun, Mar 17, 2024 at 5:43 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi Alex!
> >
> > regarding rolling upgrades / load balancing, they should be possible
> > as long as you shared your "wiki work dir" (containing f.ex., lucene
> > indexes) and your wiki pages/attachment filesystem. Also, by default
> > there's a caching layer in front of the file system access to pages
> > and attachments, ehcache based. That should be tuned too in order to
> > share the cache among your wiki instances.
> >
> > As for the wiki installation, the wiki page dir you note on the
> > installation is the path were the wiki pages should be extracted. I
> > don't have the installation page on my head now, so perhaps the
> > behaviour is different.. Also, I noticed you opened a ticket a few
> > days ago regarding installation, so there's also that (I'll try to
> > look at it thie week btw).
> >
> > Last, regarding container based authentication, it's definitely
> > possible. We have some integration tests [#2] that run through several
> > JSPWiki instances. The "-cma-" ones are those configured to use
> > container managed authentication.
> >
> >
> > HTH,
> > juan pablo
> >
> > [#2] https://github.com/apache/jspwiki/tree/master/jspwiki-it-tests
> >
> > On Sun, Mar 17, 2024 at 9:35 PM Alex O'Ree  wrote:
> > >
> > > I think that my issue was during installation, the default pages did
> not
> > > install, so i left with a blank wiki. I checked out the sources and
> > copied
> > > the default wiki page set and now things are a bit more put together
> and
> > > featureful.
> > >
> > > is there a way to use servlet container based authentication or just
> use
> > > the container provided servlet request user principle?
> > >
> > >
> > > On Sun, Mar 17, 2024 at 10:46 AM Alex O'Ree 
> wrote:
> > >
> > > > thanks for the info. looks like plugin installation is more developer
> > > > oriented, not really an easy administrative task. i was hoping for
> > > > something like a jenkins plugin setup where it's a one click install
> > type
> > > > of thing. not really a problem.
> > > >
> > > > using file system based storage (or database), and there's more than
> > one
> > > > instance of jsp wiki, say for rolling upgrades or load balancing, is
> > there
> > > > a way to notify other instances of changed content and/or index needs
> > to be
> > > > updated?
> > > >
> > > > On Tue, Mar 12, 2024 at 3:38 PM Juan Pablo Santos Rodríguez <
> > > > juanpablo.san...@gmail.com> wrote:
> > > >
> > > >> Hi Alex!
> > > >>
> > > >> thanks for your interest in JSPWiki! :-) As for your questions:
> > > >>
> > > >> Are there any administrative capabilities? like pages to see how
> much
> > > >> stuff exists in the wiki?
> > > >> for the latter, that can be accomplished via plugin [#1]. IIRC, The
> > > >> default set of wiki pages contains pages for page index, recent and
> > > >> changes / full history and a system info page with a some more wiki
&

Re: is there administrative features?

[Juan Pablo Santos Rodríguez]

Hi Alex!

regarding rolling upgrades / load balancing, they should be possible
as long as you shared your "wiki work dir" (containing f.ex., lucene
indexes) and your wiki pages/attachment filesystem. Also, by default
there's a caching layer in front of the file system access to pages
and attachments, ehcache based. That should be tuned too in order to
share the cache among your wiki instances.

As for the wiki installation, the wiki page dir you note on the
installation is the path were the wiki pages should be extracted. I
don't have the installation page on my head now, so perhaps the
behaviour is different.. Also, I noticed you opened a ticket a few
days ago regarding installation, so there's also that (I'll try to
look at it thie week btw).

Last, regarding container based authentication, it's definitely
possible. We have some integration tests [#2] that run through several
JSPWiki instances. The "-cma-" ones are those configured to use
container managed authentication.


HTH,
juan pablo

[#2] https://github.com/apache/jspwiki/tree/master/jspwiki-it-tests

On Sun, Mar 17, 2024 at 9:35 PM Alex O'Ree  wrote:
>
> I think that my issue was during installation, the default pages did not
> install, so i left with a blank wiki. I checked out the sources and copied
> the default wiki page set and now things are a bit more put together and
> featureful.
>
> is there a way to use servlet container based authentication or just use
> the container provided servlet request user principle?
>
>
> On Sun, Mar 17, 2024 at 10:46 AM Alex O'Ree  wrote:
>
> > thanks for the info. looks like plugin installation is more developer
> > oriented, not really an easy administrative task. i was hoping for
> > something like a jenkins plugin setup where it's a one click install type
> > of thing. not really a problem.
> >
> > using file system based storage (or database), and there's more than one
> > instance of jsp wiki, say for rolling upgrades or load balancing, is there
> > a way to notify other instances of changed content and/or index needs to be
> > updated?
> >
> > On Tue, Mar 12, 2024 at 3:38 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> >> Hi Alex!
> >>
> >> thanks for your interest in JSPWiki! :-) As for your questions:
> >>
> >> Are there any administrative capabilities? like pages to see how much
> >> stuff exists in the wiki?
> >> for the latter, that can be accomplished via plugin [#1]. IIRC, The
> >> default set of wiki pages contains pages for page index, recent and
> >> changes / full history and a system info page with a some more wiki
> >> information. You can see all of them at jspwiki-wiki.apache.org, on
> >> the left menu, inside the special pages box. Don't know if you're
> >> looking for something else though
> >>
> >> Ability to preload content? backup/restore?
> >> Pages/Attachment by default are stored on files inside a directory.
> >> The initial page load consists on unzipping a file inside a folder, so
> >> nothing stops you from putting there more pages. For new pages to be
> >> picked up you should restart your jspwiki instance, so they get picked
> >> up by the indexer. There aren't any in-built capabilities to
> >> import/export pages or backup/restore, you have to take care of that
> >> outside JSPWiki. Also, I've said pages are stored on disk (the page
> >> and attachment providers), but you can provide your own
> >> page/attachment provider implementation
> >>
> >> User management and permissions setup?
> >> Please see [#2] all related to Identity management, groups, ACLs
> >> (application-wide or per page), authentication, etc.
> >>
> >> I'd also add the things that I like most from JSPWiki:
> >> * very, very easy to use and setup
> >> * almost every moving part of JSPWiki is customisable and can be
> >> replaced with another implementation, 3rd party or not (2 page
> >> providers, 3 search indexers, two wiki syntaxis, plugins, filters)
> >> * deployment options (war, portable binaries, docker images)
> >> * comprehensive security options
> >>
> >>
> >> HTH,
> >> juan pablo
> >>
> >>
> >> [#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Category.Plugins
> >> [#2 <https://jspwiki-wiki.apache.org/Wiki.jsp?page=Category.Plugins[#2>]
> >> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security
> >>
> >> On Tue, Mar 12, 2024 at 12:14 AM Alex O'Ree  wrote:
> >> >
> >> > I'm shopping around for a java based wiki solution. I've found xwiki and
> >> > seems pretty capable, but i've always been a fan of asf projects so i'm
> >> > digging deep into jspwiki.
> >> >
> >> > Are there any administrative capabilities? like pages to see how much
> >> stuff
> >> > exists in the wiki?
> >> > Ability to preload content? backup/restore?
> >> > User management and permissions setup?
> >>
> >

Re: is there administrative features?

[Juan Pablo Santos Rodríguez]

Hi Alex!

thanks for your interest in JSPWiki! :-) As for your questions:

Are there any administrative capabilities? like pages to see how much
stuff exists in the wiki?
for the latter, that can be accomplished via plugin [#1]. IIRC, The
default set of wiki pages contains pages for page index, recent and
changes / full history and a system info page with a some more wiki
information. You can see all of them at jspwiki-wiki.apache.org, on
the left menu, inside the special pages box. Don't know if you're
looking for something else though

Ability to preload content? backup/restore?
Pages/Attachment by default are stored on files inside a directory.
The initial page load consists on unzipping a file inside a folder, so
nothing stops you from putting there more pages. For new pages to be
picked up you should restart your jspwiki instance, so they get picked
up by the indexer. There aren't any in-built capabilities to
import/export pages or backup/restore, you have to take care of that
outside JSPWiki. Also, I've said pages are stored on disk (the page
and attachment providers), but you can provide your own
page/attachment provider implementation

User management and permissions setup?
Please see [#2] all related to Identity management, groups, ACLs
(application-wide or per page), authentication, etc.

I'd also add the things that I like most from JSPWiki:
* very, very easy to use and setup
* almost every moving part of JSPWiki is customisable and can be
replaced with another implementation, 3rd party or not (2 page
providers, 3 search indexers, two wiki syntaxis, plugins, filters)
* deployment options (war, portable binaries, docker images)
* comprehensive security options


HTH,
juan pablo


[#1] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Category.Plugins
[#2] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security

On Tue, Mar 12, 2024 at 12:14 AM Alex O'Ree  wrote:
>
> I'm shopping around for a java based wiki solution. I've found xwiki and
> seems pretty capable, but i've always been a fan of asf projects so i'm
> digging deep into jspwiki.
>
> Are there any administrative capabilities? like pages to see how much stuff
> exists in the wiki?
> Ability to preload content? backup/restore?
> User management and permissions setup?

Re: Strange problem with Apache in front of JSPWiki on Tomcat

[Juan Pablo Santos Rodríguez]

Hi Ulf,

Would you mind sharing how your Apache instance is set up? Does it show to
which URL is trying to access the second time?


Thx in advance,
juan pablo

El sáb, 24 feb 2024, 18:23, Ulf Dittmer 
escribió:

> Hi all-
>
> I'm experiencing a strange problem, and was hoping someone might have run
> into this before.
>
> I'm running a JSPWiki site on Tomcat with an Apache in front of it. The
> Apache refuses an edit of a very simple page with a "Forbidden - You don't
> have permission to access this resource.", namely for a page with just
> these two lines:
>
> [{Image src='
>
> https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png
> '
> }]
>
> [{Image src='
>
> https://www.google.com/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png
> '
> }]
>
> (This is a minimized proof of concept of the behavior).
>
> With just one Image invocation, there's no problem. Running on a local
> machine without an Apache in front of it, there's no problem with as many
> Image elements as I want. The issue also happens if the Image references an
> attachment on that page.
>
> Has anyone seen anything like this? Or know why Apache might find this
> offensive?
>
> Thanks for any clues.
>
> Ulf
>

Re: Registering a WikiEventListener

[Juan Pablo Santos Rodríguez]

Hi Ulf,

this thread got me thinking, it shouldn't be that hard to register a
custom wiki event listener.. Starting with 2.12.2-git-10, the
CustomWikiEventListener interface has been pushed to the public API,
in order to make really easy to use custom event listeners. The
related doc is at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToWriteACustomWikiEventListener

Anyone interested, please give it a try and share your impressions! O:-)


cheers,
juan pablo

On Sat, Nov 25, 2023 at 3:33 PM Juan Pablo Santos Rodríguez
 wrote:
>
> Hi Ulf,
>
> I've just merged the PR, a snapshot with the change should be
> available in a few minutes.
>
> thanks for following this through! :-)
>
>
> best regards,
> juan pablo
>
> On Fri, Nov 24, 2023 at 4:34 PM Ulf Dittmer
>  wrote:
> >
> > Hi Juan-
> >
> > Done: https://github.com/apache/jspwiki/pull/322
> >
> > It's strange that the URL decoding is commented out, because that is
> > actually needed.
> >
> > Ulf
> >
> > On Fri, Nov 24, 2023 at 2:49 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> > > Hi Ulf!
> > >
> > > Hmmm seems to me that URLConstructor.parsePageFromUrl was thought with the
> > > short URL constructors in mind. I'd rather change it so it looks like:
> > >
> > > static String parsePageFromURL( final HttpServletRequest request, 
> > > final
> > > Charset encoding ) {
> > > final String name = request.getPathInfo();
> > > if( name == null || name.length() <= 1 ) {
> > > return request.getParameter("page"); /// change here,
> > > might still return null for front page, so perhaps it should return
> > > engine.getFrontPage in that case?
> > > } else if( name.charAt(0) == '/' ) {
> > > return name.substring(1);
> > > }
> > >
> > > // This is required, because by default all URLs are handled as
> > > Latin1, even if they are really UTF-8.
> > > // name = TextUtil.urlDecode( name, encoding );
> > >
> > > return name;
> > > }
> > >
> > > }
> > >
> > > fixing/adding appropriate unit tests. Would you mind trying that & sending
> > > a PR if it fixes the issue? If not able, I think I can commit/push the 
> > > code
> > > myself this weekend.
> > >
> > > The issue with the parsePage method is that it needs the current wiki
> > > context (attach, view, edit, etc.), which isn't there in a straightforward
> > > way.
> > >
> > >
> > > Best regards,
> > > juan pablo
> > >
> > > El jue, 23 nov 2023, 11:43, Ulf Dittmer  > > .invalid>
> > > escribió:
> > >
> > > > I'm confused: URLConstructor.parsePageFromURL -which is used to extract
> > > the
> > > > page name from the HttpServletRequest when firing the PAGE_REQUESTED and
> > > > PAGE_DELIVERED events- looks at the path info rather than the query
> > > string
> > > > (which contains the page name). How is that supposed to work? Should it
> > > be
> > > > using URLConstructor.parsePage instead?
> > > >
> > > > Something like this seems to do the trick:
> > > >
> > > > String name = request.getParameter("page");
> > > > if (StringUtils.isBlank(name)) {
> > > > // TODO: get reference to Engine
> > > > // name = engine.getFrontPage();
> > > > } else {
> > > > // This is required, because by default all URLs are handled as
> > > Latin1,
> > > > even if they are really UTF-8.
> > > > name = URLDecoder.decode(name, encoding);
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Nov 22, 2023 at 7:02 PM Ulf Dittmer 
> > > > wrote:
> > > >
> > > > > Now we're getting somewhere :-)
> > > > >
> > > > > In WikIEventManager, I can see my listener being added
> > > > > in WikiEventDelegate.addWikiEventListener, but the reference is null
> > > when
> > > > > the event reaches WikiEventDelegate.fireEvent. Probably courtesy of 
> > > > > the
> > > > > WeakReference.
> > > > >
> > > > > Ok, making the event listener a static class, and keeping a reference
> > > to
> > > 

Re: Registering a WikiEventListener

[Juan Pablo Santos Rodríguez]

Hi Ulf,

I've just merged the PR, a snapshot with the change should be
available in a few minutes.

thanks for following this through! :-)


best regards,
juan pablo

On Fri, Nov 24, 2023 at 4:34 PM Ulf Dittmer
 wrote:
>
> Hi Juan-
>
> Done: https://github.com/apache/jspwiki/pull/322
>
> It's strange that the URL decoding is commented out, because that is
> actually needed.
>
> Ulf
>
> On Fri, Nov 24, 2023 at 2:49 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi Ulf!
> >
> > Hmmm seems to me that URLConstructor.parsePageFromUrl was thought with the
> > short URL constructors in mind. I'd rather change it so it looks like:
> >
> > static String parsePageFromURL( final HttpServletRequest request, final
> > Charset encoding ) {
> > final String name = request.getPathInfo();
> > if( name == null || name.length() <= 1 ) {
> > return request.getParameter("page"); /// change here,
> > might still return null for front page, so perhaps it should return
> > engine.getFrontPage in that case?
> > } else if( name.charAt(0) == '/' ) {
> > return name.substring(1);
> > }
> >
> > // This is required, because by default all URLs are handled as
> > Latin1, even if they are really UTF-8.
> > // name = TextUtil.urlDecode( name, encoding );
> >
> > return name;
> > }
> >
> > }
> >
> > fixing/adding appropriate unit tests. Would you mind trying that & sending
> > a PR if it fixes the issue? If not able, I think I can commit/push the code
> > myself this weekend.
> >
> > The issue with the parsePage method is that it needs the current wiki
> > context (attach, view, edit, etc.), which isn't there in a straightforward
> > way.
> >
> >
> > Best regards,
> > juan pablo
> >
> > El jue, 23 nov 2023, 11:43, Ulf Dittmer  > .invalid>
> > escribió:
> >
> > > I'm confused: URLConstructor.parsePageFromURL -which is used to extract
> > the
> > > page name from the HttpServletRequest when firing the PAGE_REQUESTED and
> > > PAGE_DELIVERED events- looks at the path info rather than the query
> > string
> > > (which contains the page name). How is that supposed to work? Should it
> > be
> > > using URLConstructor.parsePage instead?
> > >
> > > Something like this seems to do the trick:
> > >
> > > String name = request.getParameter("page");
> > > if (StringUtils.isBlank(name)) {
> > > // TODO: get reference to Engine
> > > // name = engine.getFrontPage();
> > > } else {
> > > // This is required, because by default all URLs are handled as
> > Latin1,
> > > even if they are really UTF-8.
> > > name = URLDecoder.decode(name, encoding);
> > > }
> > >
> > >
> > >
> > >
> > > On Wed, Nov 22, 2023 at 7:02 PM Ulf Dittmer 
> > > wrote:
> > >
> > > > Now we're getting somewhere :-)
> > > >
> > > > In WikIEventManager, I can see my listener being added
> > > > in WikiEventDelegate.addWikiEventListener, but the reference is null
> > when
> > > > the event reaches WikiEventDelegate.fireEvent. Probably courtesy of the
> > > > WeakReference.
> > > >
> > > > Ok, making the event listener a static class, and keeping a reference
> > to
> > > > it in CoreBean, causes the listener to not be null, and to receive
> > > > PAGE_DELIVERED events.
> > > > engine.addWikiEventListener(myListener) now works fine.
> > > >
> > > > BUT: for both PAGE_REQUESTED and PAGE_DELIVERED, the event's
> > > getPageName()
> > > > method returns null
> > > > The javadocs state "Returns the Wiki page name associated with this
> > > > event. This may be null if unavailable." but why would it be
> > unavailable?
> > > >
> > > > Thanks,
> > > > Ulf
> > > >
> > > > On Wed, Nov 22, 2023 at 6:01 PM Juan Pablo Santos Rodríguez <
> > > > juanpablo.san...@gmail.com> wrote:
> > > >
> > > >> Hi!,
> > > >>
> > > >> The lifecycle extension was just an easy entry point to register the
> > > >> listener, if you're doing it elsewhere it should be fine, you should
> > be
> > > >> receiving the events as soon as you'

Re: Registering a WikiEventListener

[Juan Pablo Santos Rodríguez]

Hi Ulf!

Hmmm seems to me that URLConstructor.parsePageFromUrl was thought with the
short URL constructors in mind. I'd rather change it so it looks like:

static String parsePageFromURL( final HttpServletRequest request, final
Charset encoding ) {
final String name = request.getPathInfo();
if( name == null || name.length() <= 1 ) {
return request.getParameter("page"); /// change here,
might still return null for front page, so perhaps it should return
engine.getFrontPage in that case?
} else if( name.charAt(0) == '/' ) {
return name.substring(1);
}

// This is required, because by default all URLs are handled as
Latin1, even if they are really UTF-8.
// name = TextUtil.urlDecode( name, encoding );

return name;
}

}

fixing/adding appropriate unit tests. Would you mind trying that & sending
a PR if it fixes the issue? If not able, I think I can commit/push the code
myself this weekend.

The issue with the parsePage method is that it needs the current wiki
context (attach, view, edit, etc.), which isn't there in a straightforward
way.


Best regards,
juan pablo

El jue, 23 nov 2023, 11:43, Ulf Dittmer 
escribió:

> I'm confused: URLConstructor.parsePageFromURL -which is used to extract the
> page name from the HttpServletRequest when firing the PAGE_REQUESTED and
> PAGE_DELIVERED events- looks at the path info rather than the query string
> (which contains the page name). How is that supposed to work? Should it be
> using URLConstructor.parsePage instead?
>
> Something like this seems to do the trick:
>
> String name = request.getParameter("page");
> if (StringUtils.isBlank(name)) {
> // TODO: get reference to Engine
> // name = engine.getFrontPage();
> } else {
> // This is required, because by default all URLs are handled as Latin1,
> even if they are really UTF-8.
> name = URLDecoder.decode(name, encoding);
> }
>
>
>
>
> On Wed, Nov 22, 2023 at 7:02 PM Ulf Dittmer 
> wrote:
>
> > Now we're getting somewhere :-)
> >
> > In WikIEventManager, I can see my listener being added
> > in WikiEventDelegate.addWikiEventListener, but the reference is null when
> > the event reaches WikiEventDelegate.fireEvent. Probably courtesy of the
> > WeakReference.
> >
> > Ok, making the event listener a static class, and keeping a reference to
> > it in CoreBean, causes the listener to not be null, and to receive
> > PAGE_DELIVERED events.
> > engine.addWikiEventListener(myListener) now works fine.
> >
> > BUT: for both PAGE_REQUESTED and PAGE_DELIVERED, the event's
> getPageName()
> > method returns null
> > The javadocs state "Returns the Wiki page name associated with this
> > event. This may be null if unavailable." but why would it be unavailable?
> >
> > Thanks,
> > Ulf
> >
> > On Wed, Nov 22, 2023 at 6:01 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> >> Hi!,
> >>
> >> The lifecycle extension was just an easy entry point to register the
> >> listener, if you're doing it elsewhere it should be fine, you should be
> >> receiving the events as soon as you've registered it.
> >>
> >> Regarding the registration,
> >>
> >> WikiEventManager.addWikiEventListener(org.apache.wiki.WikiEngine.class,
> >> new
> >> WikiEventListener() {
> >>
> >> Having skimmed the code this morning, I think it should use the engine
> >> instance, something like
> >>
> >> WikiEventManager.addWikiEventListener(m_engine, new
> >> WikiEventListener() {
> >>
> >> As this is where WikiJSPFilter send the events. Would you mind trying to
> >> debug inside WikiEventManager.fireEvent to see where the events are
> being
> >> dispatched? I'll try to look into this throughout the week, but can't
> >> promise anything.
> >>
> >>
> >> Best regards,
> >> juan pablo
> >>
> >> El mié, 22 nov 2023, 16:52, Ulf Dittmer  >> .invalid>
> >> escribió:
> >>
> >> > Hm, creating an extension seems like a lot of effort for something
> that
> >> > should -from my reading of the javadocs- be relatively simple to do.
> >> >
> >> > I'm beefing up the CoreBean with page view statistics. So the code I
> >> posted
> >> > before would be run as part of the CoreBean constructor, which should
> >> > ensure that it is run during startup time.
> >> >
> >> > Based on what you said I just tried
> >&g

Re: Registering a WikiEventListener

[Juan Pablo Santos Rodríguez]

Hi Ulf,

I haven't had time to look into this in detail, but I'd try to register the
listener through an Engine lifecycle extension (#1), from there you should
be able to register your listener as soon as the Engine is instantiated.

WikiJSPFilter fires some Page events, but fires them to the running
WikiEngine, so it's there where you should listen to.

WikiEventUtils disappeared long ago, IIRC due to a refactor so that the
jspwiki-event could be extracted to it's own module. Don't remember very
well, but its methods ended up mostly in WiliEventManager


HTH,
juan pablo

#1:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToWriteAnEngineLifecycleExtension


El mié, 22 nov 2023, 10:49, Ulf Dittmer 
escribió:

> I also tried
>
>
> WikiEventManager.addWikiEventListener(org.apache.wiki.ui.WikiServletFilter.class,
> new WikiEventListener() {
> ...
>
> but that doesn't get called, either. Does anyone know how that is supposed
> to work?
>
> If I understand https://jspwiki-wiki.apache.org/Wiki.jsp?page=WikiEvent
> correctly, that might need to be done BEFORE WikiServletFilter in
> instantiated, but I don't see how that is possible. But then, I'm not sure
> how accurate that page is - some of the other pages describing event
> handling some out of date.
>
> Thanks,
> Ulf
>
> On Tue, Nov 21, 2023 at 11:10 AM Ulf Dittmer 
> wrote:
>
> > Hi-
> >
> > I'm trying to get notified whenever a page is delivered by listening to
> > WikiPageEvent.PAGE_DELIVERED events. To that end I implemented a
> > WikiEventListener like this
> >
> > engine.addWikiEventListener(new WikiEventListener() {
> > @Override
> > public void actionPerformed (WikiEvent event) {
> > log.info(event.toString());
> > if (event instanceof WikiPageEvent) {
> > ...
> > }
> > }
> > });
> > }
> >
> > But the listener is never called with WikiPageEvents. According to
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=WikiEventUtils (a class
> > which apparently no longer exists) I may have to register the listener
> with
> > WikiServletFilter rather than WikiEngine. How would I go about that?
> >
> > Thanks,
> > Ulf
> >
>

Re: Changing the colors of a site

[Juan Pablo Santos Rodríguez]

Hi,

if you don't feel comfortable mangling with the less files, as another
approach, you can define a template (a folder inside
./jspwiki-war/src/main/webapp/templates) with only a localheader.jsp
(see [#1]) file and set there your CSS. If a file is missing from a
template, JSPWiki will read if from the default template, so this is a
nice way to add wiki-wide customizations.

You could also play with the Add CSS style directive, and get custom
css styles, globally (by placing it on the LeftMenu page), for a given
user, etc. [#2] woud be a good starting place for looking into this
approach.


HTH,
juan pablo


[#1] 
https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/webapp/templates/default/localheader.jsp#L31-L34
[#2] https://jspwiki-wiki.apache.org/Wiki.jsp?page=Add%20CSS%20Style

On Sat, Sep 30, 2023 at 9:08 PM Arturo Bernal  wrote:
>
> Hi Ulf,
>
> Thank you for reaching out. The elegant way to change the colors of the
> header and footer in JSPWiki is to modify the variables.less file and then
> recompile the LESS into CSS. This ensures that your changes are integrated
> into the base template and are consistent across the site.
>
> However, if you're not familiar with LESS or if you're looking for a
> quicker workaround, you can directly override the CSS styles. Here's an
> example to change the header background to a pinkish-red color:
>
> css
>
> .header {
>   background: hsla(333, 76%, 46%, 0.9) !important;
> }
>
> The !important flag ensures that this rule will take precedence over any
> existing styles.
>
> Please note that using !important is generally considered a workaround and
> it's best to use it sparingly. For a long-term solution, I would recommend
> getting comfortable with LESS and modifying the variables.less file.
>
> Hope this helps!
>
>
> Arturo
>
>
> On Fri, Sep 29, 2023 at 3:38 PM Ulf Dittmer
>  wrote:
>
> > Hi-
> >
> > For a site I'm implementing with JSPWiki I need to change the two blue
> > tones of the header and footer to other colors. How would I go about that?
> > I've gone through various CSS-related pages of the documentation, but they
> > all seem to deal with changing styles within a page, not in the base
> > template. I suspect the answer has something to do with the color
> > definitions in the variables.less file, but although I'm somewhat
> > proficient with CSS, LESS is a mystery to me.
> >
> > Can someone point me in the right direction?
> >
> > Thanks, Ulf
> >

Re: Preventing seeing the page source

[Juan Pablo Santos Rodríguez]

Hi Ulf,

I don't have a PC in front of me right now, so don't know if it's feasible,
but perhaps you could play with  [#1] inside the Nav.jsp
page?


HTH,
juan pablo


[#1]:
https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/main/java/org/apache/wiki/tags/UserCheckTag.java

El lun, 21 ago 2023, 15:35, Ulf Dittmer 
escribió:

> Hi-
>
> I’m setting up a public instance where I don't want anyone who is not
> Authenticated to be able to view the page source. Looking at Nav.jsp, I
> can’t make out how to set that up.
>
> I don't really want to remove the “raw” skin, as that might be useful for
> Authenticated users.
>
> Is there a way to make the use of the raw skin contingent upon people being
> Authenticated?
>
> Thanks,
> Ulf
>

Re: Section Editing broken

[Juan Pablo Santos Rodríguez]

Hi Jim,

Would you mind trying accessing directly to your tomcat's instance and see
if everything works as expected?

It seems to me that the problem is probably sitting at the Apache
configuration (the cookie handling); digging through the MLs' archives I
found [#1], which depicts a similar situation maybe that's useful in your
case?


HTH,
juan pablo

[#1] https://lists.apache.org/thread/tsdsjo10s94tdbnsqksmz0fym9f8god7

El jue, 17 ago 2023, 20:13, Jim Wise  escribió:

> Hi!
>
> To add to this, I see no errors in the javascript console throughout, with
> one exception, which is odd, but I believe not relevant:
>
> Parsing application manifest
> https://wiki.draga.com/wiki/favicons/site.webmanifest: The manifest is
> not valid JSON data.
>
> Looking at that loaded resource, it is indeed not JSON — it’s a JSPWiki
> “this page does not exist” page — but this should not affect the page
> itself, and no other errors show in the console.
>
> Thanks,
> --
> Jim Wise (he/him)
> jw...@draga.com
>
>
>
>
>
> > On Aug 17, 2023, at 12:40, Jim Wise  wrote:
> >
> > Interestingly, the edit page itself also obeys user preferences.  It is
> only Wiki content that is not getting it.
> >
> > --
> >   Jim Wise (he/him)
> >   jw...@draga.com
> >
> >
> >
> >
> >
> >> On Aug 17, 2023, at 12:37, Jim Wise  wrote:
> >>
> >> For completeness, I have also tried with ProxyPass/ProxyPassReverse
> using HTTP instead of AJP, with no change.
> >>
> >> --
> >>  Jim Wise (he/him)
> >>  jw...@draga.com
> >>
> >>
> >>
> >>
> >>
> >>> On Aug 17, 2023, at 11:55, Jim Wise  wrote:
> >>>
> >>> Thank you — there is an apache reverse proxy in front of tomcat,
> communicating with tomcat via AJP.
> >>>
> >>> I have ProxyPass and ProxyPassReverse set, but do not have
> ProxyPassReverseCookiePath set, as the path is the same in front of and
> behind the proxy (I’m mapping / on the apache virtual host to / on the
> tomcat instance).
> >>>
> >>> With section editing enabled (and dark mode turned back off), I see
> two JSPWikiUserPrefs cookies, both with the correct domain, one with path
> “/“ and one with path “/wiki”.
> >>>
> >>> The one pathed to “/“ contains:
> >>>
> >>> {
> >>> "Version": "haddock04",
> >>> "PrevQuery": "",
> >>> "editor": "plain",
> >>> "SectionEditing": true,
> >>> "Appearance": false,
> >>> "Language": "en",
> >>> "Layout": "fluid",
> >>> "Orientation": "fav-left",
> >>> "DateFormat": "dd-MMM- HH:mm",
> >>> "TimeZone": "US/Eastern",
> >>> "autosuggest": true,
> >>> "tabcompletion": true,
> >>> "smartpairs": false,
> >>> "livepreview": true,
> >>> "previewcolumn": false
> >>> }
> >>>
> >>> The one pathed to “/wiki” contains:
> >>>
> >>> {
> >>> "version": "haddock04",
> >>> "PrevQuery": ""
> >>> }
> >>>
> >>> To eliminate another variable between the working jspwiki-wiki and
> this wiki, I’ve upgraded openjdk to 17, with no change in behavior.
> >>>
> >>> --
> >>> Jim Wise (he/him)
> >>> jw...@draga.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> On Aug 17, 2023, at 06:06, Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
> >>>>
> >>>> Hi Jim,
> >>>>
> >>>> Do you have something in front of your tomcat instance (an Apache web
> >>>> server or something like that)? In that case, f.ex., for Apache you
> have to
> >>>> set some directives: proxypass, proxypassreverse and
> >>>> proxypassreversecookiepath, IIRC.
> >>>>
> >>>> Another thing to check would be your JSPWiki user prefs cookie, to
> which
> >>>> domain/path is mapped? Does it get stored 

Re: Section Editing broken

[Juan Pablo Santos Rodríguez]

Hi Jim,

Do you have something in front of your tomcat instance (an Apache web
server or something like that)? In that case, f.ex., for Apache you have to
set some directives: proxypass, proxypassreverse and
proxypassreversecookiepath, IIRC.

Another thing to check would be your JSPWiki user prefs cookie, to which
domain/path is mapped? Does it get stored when you save the user
preferences, or the log shows something unusual about that?


Regards,
juan pablo

El jue, 17 ago 2023, 7:54, Arturo Bernal  escribió:

> Hi Jim,
>
> I have tested this on the official JSPWiki page and can confirm that
> everything works as expected. After switching to dark mode and saving the
> preferences, I was redirected to the main page with the dark theme applied.
> The same goes for the Section editing; it works as intended. Have you tried
> refreshing the browser's cache to see if that resolves the issue?
>
> As far as I recall, we are using Java 17 and JSPWiki v2.12.1.
>
> Best regards,
>
> Arturo
>
>
> On Thu, Aug 17, 2023 at 4:45 AM Jim Wise  wrote:
>
> > As an update, some playing with this seems to show that this is an issue
> > with user preferences in the wiki here, not just with section editing.
> >
> > As a concrete example, if I turn on dark mode in the preferences, this
> > changes the appearance of the preferences screen, and of the login
> screen,
> > but displayed wiki pages are unchanged, and still appear in light mode.
> >
> > I’ll dig further, but any pointers are appreciated!
> > --
> > Jim Wise (he/him)
> > jw...@draga.com
> >
> >
> >
> >
> >
> > > On Aug 15, 2023, at 18:21, Jim Wise  wrote:
> > >
> > > Hi!
> > >
> > > Editing itself works great.  Section editing links no longer appear
> next
> > to each section heading, however, so I can only edit the whole page.
> > >
> > > I’ve just logged out, cleared all data (Cookies, Cache, and Local Data)
> > from our wiki, then logged in and turned section editing back on in my
> user
> > preferences, and I still see no section editing links.
> > >
> > > I’ve verified the same behavior in Safari 16.5.2 and FireFox 116.0.2.
> > >
> > > What JVM and App Server are jspwiki-wiki running?  Wondering if this is
> > the difference.
> > >
> > > Happy to share any more info here that helps debug as well!
> > >
> > > --
> > >   Jim Wise (he/him)
> > >   jw...@draga.com
> > >
> > >
> > >
> > >
> > >
> > >> On Aug 15, 2023, at 16:14, Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> > >>
> > >> Hi Jim,
> > >>
> > >> I've just tried section editing at jspwiki-wiki.a.o (currently running
> > >> 2.12.1) and it seem to work well :-?
> > >>
> > >> Would you mind trying to refresh the browser's cache and see if that
> > does
> > >> the trick?
> > >>
> > >> I don't recall any change for section editing (or js changes,
> generally
> > >> speaking) between 2.11.0 and 2.12.1, but I may be mistaken.
> > >>
> > >> Exactly, what behaviour are you getting? You don't arrive at the edit
> > page,
> > >> it doesn't have anything, it overwrites the page,..?
> > >>
> > >>
> > >> Best regards,
> > >> juan pablo
> > >>
> > >> El mar, 15 ago 2023, 20:39, Jim Wise  escribió:
> > >>
> > >>> Hi!
> > >>>
> > >>> Before I dig deeper, is section editing working for anyone under
> > 2.12.x?
> > >>>
> > >>> Just got a report that it had been broken “for quite a while”, and
> > turning
> > >>> it on verifies that its is indeed not working under 2.12.1 on OpenJDK
> > >>> 11.0.20 and Tomcat 9.0.79.
> > >>>
> > >>> I’m sorry not to have further clarity on “for a while” — happy to
> play
> > >>> with this and try to bisect, just want to make sure that it actually
> is
> > >>> broken for other folks, rather than being a misconfiguration on my
> > part.
> > >>>
> > >>> Changes we’ve made in the last “for a while” (read:  since this
> > definitely
> > >>> worked, but probably too far back) include:
> > >>>
> > >>> - Update of JSPWiki from 2.11.0 through 2.12.1
> > >>> - Two versions of OpenJDK (8.x and 11.x)
> > >>> - Steady rolling upgrades of Tomcat from 9.0.46 through 9.0.79
> > >>>
> > >>> I recognize this is a largish revision space to bisect, but post it
> for
> > >>> comparison in case section editing is currently working for anyone,
> so
> > we
> > >>> can see what differs.
> > >>>
> > >>> Thanks all,
> > >>> --
> > >>>   Jim Wise (he/him)
> > >>>   jw...@draga.com
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> >
> >
>

Re: Section Editing broken

[Juan Pablo Santos Rodríguez]

Hi Jim,

I've just tried section editing at jspwiki-wiki.a.o (currently running
2.12.1) and it seem to work well :-?

Would you mind trying to refresh the browser's cache and see if that does
the trick?

I don't recall any change for section editing (or js changes, generally
speaking) between 2.11.0 and 2.12.1, but I may be mistaken.

Exactly, what behaviour are you getting? You don't arrive at the edit page,
it doesn't have anything, it overwrites the page,..?


Best regards,
juan pablo

El mar, 15 ago 2023, 20:39, Jim Wise  escribió:

> Hi!
>
> Before I dig deeper, is section editing working for anyone under 2.12.x?
>
> Just got a report that it had been broken “for quite a while”, and turning
> it on verifies that its is indeed not working under 2.12.1 on OpenJDK
> 11.0.20 and Tomcat 9.0.79.
>
> I’m sorry not to have further clarity on “for a while” — happy to play
> with this and try to bisect, just want to make sure that it actually is
> broken for other folks, rather than being a misconfiguration on my part.
>
> Changes we’ve made in the last “for a while” (read:  since this definitely
> worked, but probably too far back) include:
>
> - Update of JSPWiki from 2.11.0 through 2.12.1
> - Two versions of OpenJDK (8.x and 11.x)
> - Steady rolling upgrades of Tomcat from 9.0.46 through 9.0.79
>
> I recognize this is a largish revision space to bisect, but post it for
> comparison in case section editing is currently working for anyone, so we
> can see what differs.
>
> Thanks all,
> --
> Jim Wise (he/him)
> jw...@draga.com
>
>
>
>
>
>

[ANNOUNCE] Arturo Bernal as new JSPWiki PMC and committer!

[Juan Pablo Santos Rodríguez]

Hi all,

We're glad to announce that the JSPWiki PMC has a new member and
committer, Arturo Bernal.


Welcome!

juan pablo,
on behalf of the JSPWiki PMC

Re: Re: Re: "Workflow-Problems"

[Juan Pablo Santos Rodríguez]

Absolutely! Do let me know if there's anything I can do to help with that


Best regards,
juan pablo

p.s.: I'm re-adding user@j.a.o to cc:, please keep it there so other
people with the same issue can be kept updated about its state, or the
other way round, maybe other people can chime in with new ideas on how
to fix it - thanks!

On Fri, Jun 16, 2023 at 11:29 AM  wrote:
>
> Hei juan pablo,
>
> today i do't have the time to test. but Martina perhaps can test, if sie has 
> time today.
> otherwise martina or i will test on monday.
>
> we hope that's ok?
>
> greetings
> frank
>
>
> -"Juan Pablo Santos Rodríguez"  schrieb: -
> An: frank.fau...@stuttgarter.de
> Von: "Juan Pablo Santos Rodríguez" 
> Datum: 16.06.2023 01:11
> Kopie: martina.jae...@stuttgarter.de, user@jspwiki.apache.org
> Betreff: Re: Re: "Workflow-Problems"
>
> Resending as plaint text, as user@jspwiki.a.o doesn't seem to like
> inlined attechments, apologies for the noise
>
> On Fri, Jun 16, 2023 at 1:00 AM Juan Pablo Santos Rodríguez
>  wrote:
> >
> > Hi Frank, Martina,
> >
> > would you mind testing 2.12.1-git-01? It should fix this issue, all 
> > workflow related fields should appear same as in 2.11.0.M5.
> >
> > Our Jenkins build should be deploying an snapshot to 
> > https://repository.apache.org/content/repositories/snapshots in a few 
> > minutes, or you can build it locally..
> >
> >
> > thanks + best regards,
> > juan pablo
> >
> > On Thu, Jun 15, 2023 at 11:08 AM  wrote:
> >>
> >> Hello juan pablo
> >>
> >> thank you very much for your reply.
> >> i changed ${decision.workflowId}
> >> now i get the error:
> >> /templates/default/WorkflowContent.jsp(69,14) 
> >> '${decision.messageArguments}' Property [messageArguments] not found on 
> >> type [org.apache.wiki.workflow.SimpleDecision]
> >> at 
> >> org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:120)
> >>
> >> my colleague Martina identified another three points (see below):
> >> with her modifications it works, we hope this helps you.
> >>
> >> thank you once again,
> >> greetings
> >> frank
> >> -Martina Jänel/Stuttgarter-Versicherung/DE schrieb: -
> >> An: Frank Fausel/Stuttgarter-Versicherung/DE@Stuttgarter-Versicherung
> >> Von: Martina Jänel/Stuttgarter-Versicherung/DE
> >> Datum: 15.06.2023 10:36
> >> Betreff: Antwort: WG: Re: "Workflow-Problems"
> >>
> >>
> >>
> >> 1: There is no more an ${decision.owner.name}, just a 
> >> ${decision.actor.name}
> >> 2: There are no more ${decision.messageArguments}.
> >> For a prettier german localized message we inserted the (not pretty) code 
> >> snippet  >> value=""/>
> >> In a "2.12.1"-Version the localized message should probably be edited, so 
> >> it doesn't require arguments.
> >> 3: Because the ${decision.actor.name} makes no sense as 
> >> requester/initiator (because it's always the admin and not the actual 
> >> initiator), we eliminated this column.
> >>
> >>
> >> Frank
> >> -"Juan Pablo Santos Rodríguez"  schrieb: 
> >> -
> >> An: user@jspwiki.apache.org, "frank.fau...@stuttgarter.de" 
> >> 
> >> Von: "Juan Pablo Santos Rodríguez" 
> >> Datum: 15.06.2023 00:14
> >> Betreff: Re: "Workflow-Problems"
> >>
> >> Hi Frank,
> >>
> >> Seems a refactor [#1] I made three years ago was incomplete and has 
> >> rendered the workflow page useless since then :-/ This line [#2] should be 
> >> instead
> >>
> >> ${decision.workflowId}
> >>
> >> I trusted the JSPs precompilation build process to catch these kind of 
> >> errors, but it seems that it doesn't look for EL expressions correctness 
> >> (in hindsight, that seems really difficult to do without the application 
> >> running).
> >>
> >> Would you mind checking if the above fix is enough to fix the issue? I 
> >> think this would warrant a 2.12.1 by itself..
> >>
> >> Thanks in advance + sorry for not seeing this before
> >>
> >> juan pablo
> >>
> >>
> >> [#1] 
> >> https://github.com/apache/jspwiki/commit/01ee8a5d43b529dcd5cd98bd17a4e0e13c271ba8
> >> [#2] 
> >> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/m

Re: Re: "Workflow-Problems"

[Juan Pablo Santos Rodríguez]

Resending as plaint text, as user@jspwiki.a.o doesn't seem to like
inlined attechments, apologies for the noise

On Fri, Jun 16, 2023 at 1:00 AM Juan Pablo Santos Rodríguez
 wrote:
>
> Hi Frank, Martina,
>
> would you mind testing 2.12.1-git-01? It should fix this issue, all workflow 
> related fields should appear same as in 2.11.0.M5.
>
> Our Jenkins build should be deploying an snapshot to 
> https://repository.apache.org/content/repositories/snapshots in a few 
> minutes, or you can build it locally..
>
>
> thanks + best regards,
> juan pablo
>
> On Thu, Jun 15, 2023 at 11:08 AM  wrote:
>>
>> Hello juan pablo
>>
>> thank you very much for your reply.
>> i changed ${decision.workflowId}
>> now i get the error:
>> /templates/default/WorkflowContent.jsp(69,14) '${decision.messageArguments}' 
>> Property [messageArguments] not found on type 
>> [org.apache.wiki.workflow.SimpleDecision]
>> at 
>> org.apache.jasper.el.JspValueExpression.getValue(JspValueExpression.java:120)
>>
>> my colleague Martina identified another three points (see below):
>> with her modifications it works, we hope this helps you.
>>
>> thank you once again,
>> greetings
>> frank
>> -Martina Jänel/Stuttgarter-Versicherung/DE schrieb: -
>> An: Frank Fausel/Stuttgarter-Versicherung/DE@Stuttgarter-Versicherung
>> Von: Martina Jänel/Stuttgarter-Versicherung/DE
>> Datum: 15.06.2023 10:36
>> Betreff: Antwort: WG: Re: "Workflow-Problems"
>>
>>
>>
>> 1: There is no more an ${decision.owner.name}, just a ${decision.actor.name}
>> 2: There are no more ${decision.messageArguments}.
>> For a prettier german localized message we inserted the (not pretty) code 
>> snippet > value=""/>
>> In a "2.12.1"-Version the localized message should probably be edited, so it 
>> doesn't require arguments.
>> 3: Because the ${decision.actor.name} makes no sense as requester/initiator 
>> (because it's always the admin and not the actual initiator), we eliminated 
>> this column.
>>
>>
>> Frank
>> -"Juan Pablo Santos Rodríguez"  schrieb: 
>> -
>> An: user@jspwiki.apache.org, "frank.fau...@stuttgarter.de" 
>> 
>> Von: "Juan Pablo Santos Rodríguez" 
>> Datum: 15.06.2023 00:14
>> Betreff: Re: "Workflow-Problems"
>>
>> Hi Frank,
>>
>> Seems a refactor [#1] I made three years ago was incomplete and has rendered 
>> the workflow page useless since then :-/ This line [#2] should be instead
>>
>> ${decision.workflowId}
>>
>> I trusted the JSPs precompilation build process to catch these kind of 
>> errors, but it seems that it doesn't look for EL expressions correctness (in 
>> hindsight, that seems really difficult to do without the application 
>> running).
>>
>> Would you mind checking if the above fix is enough to fix the issue? I think 
>> this would warrant a 2.12.1 by itself..
>>
>> Thanks in advance + sorry for not seeing this before
>>
>> juan pablo
>>
>>
>> [#1] 
>> https://github.com/apache/jspwiki/commit/01ee8a5d43b529dcd5cd98bd17a4e0e13c271ba8
>> [#2] 
>> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/webapp/templates/default/WorkflowContent.jsp#L63
>>
>> El mié, 14 jun 2023, 10:36,  escribió:
>>>
>>> Hello,
>>>
>>> we want new user's to approve in our JSP-WIKI's.  So we defined in
>>>  /WEB-INF/classes/jspwiki-custom.properties
>>>
>>>  jspwiki.approver.workflow.createUserProfile = Admin
>>>
>>>  Normally (in version JSPWiki v2.11.0-M5) if a "User" registers, we get an 
>>> workflow and we can approv the new user.
>>>  but in Version 2.11.3 or 2.12.0
>>>  the workflow is "overwritten" by the left-menu.
>>>
>>> And we get the following exception, which is shown below.
>>>
>>>
>>> what is going wrong? can we do something?
>>>
>>> we use:
>>> Tomcat 9.0.31
>>>  java zulu-11
>>>
>>> Any help is welcome.
>>>  thank you
>>>  greeting
>>>  frank
>>>
>>>   2023-06-02 08:16:11.200 [http-nio-8080-exec-3] o.a.w.t.WikiTagBase  - 
>>> Property [workflow] not readable on type  
>>> [org.apache.wiki.workflow.SimpleDecision]
>>>   javax.el.PropertyNotFoundException: Property [workflow] not readable on 
>>> type [org.apache.wiki.workflow.SimpleDecision]
>>> a

Re: "Workflow-Problems"

[Juan Pablo Santos Rodríguez]

Hi Frank,

Seems a refactor [#1] I made three years ago was incomplete and has
rendered the workflow page useless since then :-/ This line [#2] should be
instead

${decision.workflowId}

I trusted the JSPs precompilation build process to catch these kind of
errors, but it seems that it doesn't look for EL expressions correctness
(in hindsight, that seems really difficult to do without the application
running).

Would you mind checking if the above fix is enough to fix the issue? I
think this would warrant a 2.12.1 by itself..

Thanks in advance + sorry for not seeing this before

juan pablo


[#1]
https://github.com/apache/jspwiki/commit/01ee8a5d43b529dcd5cd98bd17a4e0e13c271ba8
[#2]
https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/webapp/templates/default/WorkflowContent.jsp#L63

El mié, 14 jun 2023, 10:36,  escribió:

> Hello,
>
> we want new user's to approve in our JSP-WIKI's.  So we defined in
>  /WEB-INF/classes/jspwiki-custom.properties
>
>  jspwiki.approver.workflow.createUserProfile = Admin
>
>  Normally (in version JSPWiki v2.11.0-M5) if a "User" registers, we get an
> workflow and we can approv the new user.
>  but in Version 2.11.3 or 2.12.0
>  the workflow is "overwritten" by the left-menu.
>
> And we get the following exception, which is shown below.
>
>
> what is going wrong? can we do something?
>
> we use:
> Tomcat 9.0.31
>  java zulu-11
>
> Any help is welcome.
>  thank you
>  greeting
>  frank
>
>   2023-06-02 08:16:11.200 [http-nio-8080-exec-3] o.a.w.t.WikiTagBase  -
> Property [workflow] not readable on type
> [org.apache.wiki.workflow.SimpleDecision]
>   javax.el.PropertyNotFoundException: Property [workflow] not readable on
> type [org.apache.wiki.workflow.SimpleDecision]
> at
> javax.el.BeanELResolver$BeanProperty.read(BeanELResolver.java:313)
> at
> javax.el.BeanELResolver$BeanProperty.access$000(BeanELResolver.java:271)
> at javax.el.BeanELResolver.getValue(BeanELResolver.java:92)
> at
> org.apache.jasper.el.JasperELResolver.getValue(JasperELResolver.java:125)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:169)
> at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:190)
> at
> org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:701)
>
> at
> org.apache.jsp.templates.default_.WorkflowContent_jsp._jspx_meth_c_005fforEach_005f0(WorkflowContent_jsp.java:733)
>
> at
> org.apache.jsp.templates.default_.WorkflowContent_jsp._jspx_meth_c_005fif_005f2(WorkflowContent_jsp.java:546)
>
> at
> org.apache.jsp.templates.default_.WorkflowContent_jsp._jspx_meth_wiki_005fUserCheck_005f0(WorkflowContent_jsp.java:295)
>
> at
> org.apache.jsp.templates.default_.WorkflowContent_jsp._jspService(WorkflowContent_jsp.java:184)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477)
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
>
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:712)
>
> at
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:580)
>
> at
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:516)
>
> at
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:955)
>
> at
> org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:490)
> at org.apache.wiki.tags.ContentTag.doEndTag(ContentTag.java:182)
> at
> org.apache.jsp.templates.default_.ViewTemplate_jsp._jspx_meth_wiki_005fContent_005f0(ViewTemplate_jsp.java:947)
>
> at
> org.apache.jsp.templates.default_.ViewTemplate_jsp._jspService(ViewTemplate_jsp.java:221)
>
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:477)
>
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
>
> at
> 

CVE-2022-46907: Apache JSPWiki Cross-site scripting on several plugins

[Juan Pablo Santos Rodríguez]

Severity: moderate

Description:
A carefully crafted request on several JSPWiki plugins could trigger
an XSS vulnerability on Apache JSPWiki, which could allow the attacker
to execute javascript in the victim's browser and get some sensitive
information about the victim.

Mitigation:
Apache JSPWiki users should upgrade to 2.12.0 or later.

Credit:
This issue was discovered by Eugene Lim and Sng Jay Kai from
Government Technology Agency of Singapore

References:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-46907

[ANNOUNCE] Apache JSPWiki 2.12.0 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki 2.12.0.

This is the first release on the 2.12 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.12.0

A curated change log is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.12

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/

The Apache JSPWiki Team

RE: Restrict access for Anonymous

[Juan Pablo Santos Rodríguez]

Hi Harald,

you may wish to take a look at the department policy file [#1] of jspwiki's
portable build; IIRC, anonymous users aren't granted any permission,
whereas authenticated ones can view, edit, etc. Please let me know if that
policy works out for you or if further help is needed.


cheers,
juan pablo

[#1]
https://github.com/apache/jspwiki/blob/master/jspwiki-portable/src/overlay/woas/webapps/department/WEB-INF/jspwiki.policy

On 2023/02/06 18:36:27 Harald Krammer wrote:
> Hello !
>
> Currently we have allowed anonymous access (only view) and set the
> permissions in the pages. This allows us to limit access from Anonymous.
>
> So far everything is fine, but I now have to change our policy. We must
> explicitly specify the pages that are publicly (anonymous access) allowed.
>
>
> e.g. for OLD-Page:
>
> * to protect a  side we did it with  e.g.
> [{ALLOW edit grdev }]
>
> Without an ACL, public access is allowed (but without write permission).
>
>
>
> I have to change that now, that I explicitly allow the page.
> e.g. possibly like this?
>
> *  To allow public access
>   [{ALLOW view  ALL }]
>
> Without ACL you have to be authenticated!
>
>
> Unfortunately, it is not clear to me how I can set this in
> jspwiki.policy. All my attempts have failed so far.
>
> My used documentation:
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security
>
> Any tip is welcome.
> Nice greetings,
> Harald
>
>
>

Re: Alternative to SpreadSheetFilter (specifically sum)

[Juan Pablo Santos Rodríguez]

Hi Lars,

There are have been some code changes between 2.8.4 and now (package
rename, some internal changes on the wiki engine) that prevents pre-apache
filters and plugins to continue working on newer installations.

Migrating them is straightforward, however in the case of the spreadsheet
filter, the code doesn't seem to be available anymore. If you could point
me to an url containing the filter's source I'll put a newer, compatible
version at github so you can keep using it on newer installations.


Best regards,
juan pablo


El mié, 19 oct 2022 17:39, Lars Gußmann  escribió:

> Greetings JSPWiki Community,
>
> I'm in the process of updating a wiki from version 2.8.4 (last before
> the move to Apache)
> to the latest version 2.11.3 and encountered some incompatibilities I
> see no immediate solution to.
> Maybe I was looking in the wrong places or I just didn't see it,
> but is there no solution for calculating the sum of a row or column of
> cells of a table anymore?
> There used to be %CALC using the SpreadSheetFilter, which is no longer
> supported.
>
> Is there a possibility to calculate these sums in 2.11.3?
>
> Thanks,
> Lars Gußmann
> lars.gussman...@gmx.de
>
>

Re: Excerpts with ReferringPagesPlugin

[Juan Pablo Santos Rodríguez]

Hi Gary,

that's a good idea! I don't know what Confluence understands as excerpt. I
know it has some macro to mark some section of the page, so you can include
excerpts of pages on other pages, but surely that's not what it's shown on
the Content by Label macro. ReferringPagesPlugin currently only stores page
references, so either we store the first N characters of the page as
metadata and make page requests to grab the first N characters, or we store
them on memory, along with the page references.

In memory would increase memory usage (most probably it would still be ok)
and would entail a page request for each reference, and we'd have to sync
with page saves. OTOH, having the excerpt as metadata would allow third
party plugins/filters/etc. to work with them, but most probably we would
want to cache it to avoid page metadata requests. May be something
in-between :-?

Would you mind filing a jira issue for this?


thanks + best regards,
juan pablo

On Fri, Sep 23, 2022 at 5:01 PM Gary Kephart  wrote:

> Have you considered displaying excerpts along with the page name/link
> for the ReferringPagesPlugin ? It's something I could use. See
> https://encyclopaedia-wot.org/Wiki.jsp?page=Warder for an example. I'd
> like to use ReferringPagesPlugin but don't want to lose that extra
> information that I'm displaying.
> I know Confluence has that ability with their Content By Label. They
> even have named excerpts, but I don't know if I need that.
>
> Thanks,
>Gary
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to
> be governed by lesser men." -- Plato.
>
>

Re: CSRF protection causing errors in previews

[Juan Pablo Santos Rodríguez]

Hi Jim,

Glad it helped; right now I think the only way to trigger it is clearing
the cache, as the file doesn't change too much (IIRC, it's the first change
on that file in 8 or 10 releases or something like that). Would you mind
filling a jira so we don't forget about the proposed improvement?


thanks + best regards,
juan pablo

El jue, 4 ago 2022 17:38, Jim Wise  escribió:

> Clearing cache did it.
>
> Is there any way to trigger this via header if the cached data is from a
> previous version?
>
> Thanks,
> --
> Jim Wise (he/him)
> jw...@draga.com
>
>
>
>
>
> > On Aug 4, 2022, at 10:58, Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
> >
> > Hi Jim,
> >
> > Most probably is a caching issue, please try to empty your browser's
> cache and retry, that should be all that is needed.
> >
> > If you have a custom template, please ensure that all s (and your
> commonheader.jsp fine) contain a wiki:CsrfProtection custom tag, there's a
> note with examples in the NewIn2.11 page.
> >
> >
> > HTH,
> > juan pablo
> >
> > El jue, 4 ago 2022 16:51, Jim Wise  jw...@draga.com>> escribió:
> > I just updated to 2.11.3, and it appears that the recent CSRC protection
> fixes are interfering with previews.
> >
> > When editing pages, I see this in the preview pane:
> >
> >
> >
> > Accompanied by this in Catalina.out:
> >
> >  [ERROR] 2022-08-04 10:43:29.379 [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-2]
> o.a.w.h.f.CsrfProtectionFilter - Incorrect X-XSRF-TOKEN param with value
> 'null' received for null
> >
> > Are others seeing this?  Is there a workaround?
> >
> > Thanks,
> > --
> >   Jim Wise (he/him)
> >   jw...@draga.com <mailto:jw...@draga.com>
> >
> >
> >
> >
> >
> > 
>
>

Re: CVE-2022-28730: Apache JSPWiki Cross-site scripting vulnerability on AJAXPreview.jsp

[Juan Pablo Santos Rodríguez]

On Wed, Aug 3, 2022 at 10:45 PM Juan Pablo Santos Rodríguez
 wrote:
>
> Severity: moderate
>
> Description:
>
> A carefully crafted request on AJAXPreview.jsp could trigger an XSS 
> vulnerability on Apache JSPWiki, which could allow the attacker to execute 
> javascript in the victim's browser and get some sensitive information about 
> the victim.
>
> This vulnerability leverages CVE-2021-40369, where the Denounce plugin 
> dangerously renders user-supplied URLs. Upon re-testing CVE-2021-40369, it 
> appears that the patch was incomplete as it was still possible to insert 
> malicious input via the Denounce plugin.
>
> Mitigation:
>
> Apache JSPWiki users should upgrade to 2.11.3 or later.
>
> Credit:
>
> This issue was discovered by Poh Jia Hao, from Star Labs  DOT sg>
>
> References:
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732
>

Re: CVE-2022-34158: Apache JSPWiki: User Group Privilege Escalation

[Juan Pablo Santos Rodríguez]

On Wed, Aug 3, 2022 at 10:46 PM Juan Pablo Santos Rodríguez
 wrote:
>
> Severity: critical
>
> Description:
>
> A carefully crafted invocation on the Image plugin could trigger an CSRF 
> vulnerability on Apache JSPWiki, which could allow a group privilege 
> escalation of the attacker's account. Further examination of this issue 
> established that it could also be used to modify the email associated with 
> the attacked account, and then a reset password request from the login page.
>
> Mitigation:
>
> Apache JSPWiki users should upgrade to 2.11.3 or later.
>
> Credit:
>
> This issue was discovered by Huiseong Seo (t0rchwo0d),  com>
>
> References:
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-34158
>

Re: CVE-2022-28732: Apache JSPWiki Cross-site scripting vulnerability on WeblogPlugin

[Juan Pablo Santos Rodríguez]

On Wed, Aug 3, 2022 at 10:46 PM Juan Pablo Santos Rodríguez
 wrote:
>
> Severity: moderate
>
> Description:
>
> A carefully crafted request on WeblogPlugin could trigger an XSS 
> vulnerability on Apache JSPWiki, which could allow the attacker to execute 
> javascript in the victim's browser and get some sensitive information about 
> the victim.
>
> Mitigation:
>
> Apache JSPWiki users should upgrade to 2.11.3 or later.
>
> Credit:
>
> This issue was discovered by Wang Ran, from JDArmy, @jd.com
>
> References:
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732
>

Re: CVE-2022-28731: Apache JSPWiki CSRF in UserPreferences.jsp

[Juan Pablo Santos Rodríguez]

On Wed, Aug 3, 2022 at 10:46 PM Juan Pablo Santos Rodríguez
 wrote:
>
> Severity: critical
>
> Description:
>
> A carefully crafted request on UserPreferences.jsp could trigger an CSRF 
> vulnerability on Apache JSPWiki, which could allow the attacker to modify the 
> email associated with the attacked account, and then a reset password request 
> from the login page.
>
> Mitigation:
>
> Apache JSPWiki users should upgrade to 2.11.3 or later. Installations >= 
> 2.7.0 can also enable user management workflows' manual approval to mitigate 
> the issue.
>
> Credit:
>
> This issue was discovered by Fabrice Perez, 
>
> References:
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732
>

Re: CVE-2022-27166: Apache JSPWiki: XSS vulnerability on XHRHtml2Markup.jsp in JSPWiki 2.11.2

[Juan Pablo Santos Rodríguez]

On Wed, Aug 3, 2022 at 10:45 PM Juan Pablo Santos Rodríguez
 wrote:
>
> Severity: moderate
>
> Description:
>
> A carefully crafted request on XHRHtml2Markup.jsp could trigger an XSS 
> vulnerability on Apache JSPWiki, which could allow the attacker to execute 
> javascript in the victim's browser and get some sensitive information about 
> the victim
>
> Credit:
>
> Issue was discovered by Salt, 
>
> References:
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2022-28732
>

[ANNOUNCE] Apache JSPWiki 2.11.3 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki
2.11.3.

This is the fourth release on the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.3

The full change log is available here:
https://issues.apache.org/jira/browse/JSPWIKI/fixforversion/12351386

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/


The Apache JSPWiki Team

Re: [External] Re: Search not working on unmodified files

[Juan Pablo Santos Rodríguez]

Hi Andrew, Jim,

all these issues should've been fixed in 2.11.3-git-07, so no more
ehcache tweaking should be needed (unless you want it to), would you
mind trying with latest master and confirm it?

thx,
juan pablo

On Fri, Apr 22, 2022 at 5:24 PM Andrew Ducker
 wrote:
>
> Hi,
>
> I created the ehcache file, dropped it into the same folder as 
> jspwiki-custom.properties, stopped the service, cleared the WorkingDir, 
> restarted the service.
>
> The good news is that it now logs all 13,000 entries!
>
> I then had to assign more memory to Tomcat, but that’s understandable.
>
> Thank you for this!
>
> Andy
>
> From: Juan Pablo Santos Rodríguez [mailto:juanpablo.san...@gmail.com]
> Sent: 21 April 2022 22:21
> To: user@jspwiki.apache.org
> Subject: Re: [External] Re: Search not working on unmodified files
>
> Alert! This is an external email sent from juanpablo.san...@gmail.com.
>
> Hi Andrew, Jim,
>
> hmm upon closer looking, seems LuceneSearchProvider requests all pages
> to the page manager, which in turn delegates
> to the caching provider, which, by default, holds up to 1.000
> elements, and that's why no more pages appear indexed on a
> full reindex. I'll push a fix for that tomorrow / this weekend.
>
> In the meantime, you can use [#1] as an example of an ehcache file.
> Please see [#2] to see the appropiate parameters
> needed to use a custom ehcache file. Would you mind testing if the
> error persist while using a custom ehcache file with
> more elements than pages available?
>
>
> best regards,
> juan pablo
>
>
> [#1] 
> https://github.com/apache/jspwiki/blob/master/jspwiki-cache/src/main/resources/ehcache-jspwiki.xml<https://github.com/apache/jspwiki/blob/master/jspwiki-cache/src/main/resources/ehcache-jspwiki.xml>
> [#2] 
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11#section-NewIn2.11-NewInJSPWiki2.11.1ReleasedOn18122021<https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11#section-NewIn2.11-NewInJSPWiki2.11.1ReleasedOn18122021>
>
> On Thu, Apr 21, 2022 at 2:38 PM Jim Willeke  wrote:
> >
> > I found this one:
> > https://jar-download.com/artifacts/org.apache.jspwiki/jspwiki-war/2.10.1/source-code/ehcache.xml<https://jar-download.com/artifacts/org.apache.jspwiki/jspwiki-war/2.10.1/source-code/ehcache.xml>
> >
> > --
> > -jim
> > Jim Willeke
> >
> >
> > On Thu, Apr 21, 2022 at 6:41 AM Andrew Ducker <
> > andrew_duc...@thephoenixgroup.com> wrote:
> >
> > > Is there an example ehcache file somewhere? It doesn’t get created
> > > anywhere automatically that I can see, and it’s not in the
> > > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Configuration<https://jspwiki-wiki.apache.org/Wiki.jsp?page=Configuration>
> > >  documentation.
> > >
> > > Cheers,
> > >
> > > Andy
> > >
> > > From: Jim Willeke [mailto:j...@willeke.com]
> > > Sent: 20 April 2022 21:35
> > > To: user@jspwiki.apache.org
> > > Subject: Re: [External] Re: Search not working on unmodified files
> > >
> > > Alert! This is an external email sent from j...@willeke.com.
> > >
> > > I have observed something similar.
> > >
> > > Active Sessions 51
> > > Uptime 0d, 18h 30m 39s
> > > Number of pages 16390FYI: I too am seeing similar issues on 2.11.0-M8.
> > >
> > > I have NOT observed the issues on 2.10.1.
> > >
> > > The instance on version 2.10.1 
> > > (https://ldapwiki.com/wiki/SystemInfo<https://ldapwiki.com/wiki/SystemInfo><
> > > https://ldapwiki.com/wiki/SystemInfo<https://ldapwiki.com/wiki/SystemInfo>>)
> > >  is
> > > busy
> > > and the 2.11.0-M8 instance on has very low traffic.
> > >
> > > On the version 2.11.0-M8, Cleared the Lucene and work directory and
> > > restarted:
> > >
> > > Active Sessions 1
> > > Uptime 0d, 9h 11m 7s
> > > Number of pages 16499
> > >
> > > And one day later is shows:
> > > Active Sessions 1
> > > Uptime 1d, 10h 15m 43s
> > > Number of pages 46
> > >
> > > Then after using for a few minutes it now says:
> > > Active Sessions 1
> > > Uptime 1d, 10h 35m 52s
> > > Number of pages 16500
> > > (And yes one page was really added over the day)
> > >
> > > Where Number of pages is the [{$totalpages}]
> > >
> > > On the version 2.10.1 below is typical:
> > >
> > > Active Sessions 51
> > > Uptime 0d, 18h 30m 39s
> > > Number of pages 16390
> &g

Re: [External] Re: Search not working on unmodified files

[Juan Pablo Santos Rodríguez]

Hi Andrew, Jim,

hmm upon closer looking, seems LuceneSearchProvider requests all pages
to the page manager, which in turn delegates
to the caching provider, which, by default, holds up to 1.000
elements, and that's why no more pages appear indexed on a
full reindex. I'll push a fix for that tomorrow / this weekend.

In the meantime, you can use [#1] as an example of an ehcache file.
Please see [#2] to see the appropiate parameters
needed to use a custom ehcache file. Would you mind testing if the
error persist while using a custom ehcache file with
more elements than pages available?


best regards,
juan pablo


[#1] 
https://github.com/apache/jspwiki/blob/master/jspwiki-cache/src/main/resources/ehcache-jspwiki.xml
[#2] 
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11#section-NewIn2.11-NewInJSPWiki2.11.1ReleasedOn18122021

On Thu, Apr 21, 2022 at 2:38 PM Jim Willeke  wrote:
>
> I found this one:
> https://jar-download.com/artifacts/org.apache.jspwiki/jspwiki-war/2.10.1/source-code/ehcache.xml
>
> --
> -jim
> Jim Willeke
>
>
> On Thu, Apr 21, 2022 at 6:41 AM Andrew Ducker <
> andrew_duc...@thephoenixgroup.com> wrote:
>
> > Is there an example ehcache file somewhere?  It doesn’t get created
> > anywhere automatically that I can see, and it’s not in the
> > https://jspwiki-wiki.apache.org/Wiki.jsp?page=Configuration documentation.
> >
> > Cheers,
> >
> > Andy
> >
> > From: Jim Willeke [mailto:j...@willeke.com]
> > Sent: 20 April 2022 21:35
> > To: user@jspwiki.apache.org
> > Subject: Re: [External] Re: Search not working on unmodified files
> >
> > Alert! This is an external email sent from j...@willeke.com.
> >
> > I have observed something similar.
> >
> > Active Sessions 51
> > Uptime 0d, 18h 30m 39s
> > Number of pages 16390FYI: I too am seeing similar issues on 2.11.0-M8.
> >
> > I have NOT observed the issues on 2.10.1.
> >
> > The instance on version 2.10.1 (https://ldapwiki.com/wiki/SystemInfo<
> > https://ldapwiki.com/wiki/SystemInfo>) is
> > busy
> > and the 2.11.0-M8 instance on has very low traffic.
> >
> > On the version 2.11.0-M8, Cleared the Lucene and work directory and
> > restarted:
> >
> > Active Sessions 1
> > Uptime 0d, 9h 11m 7s
> > Number of pages 16499
> >
> > And one day later is shows:
> > Active Sessions 1
> > Uptime 1d, 10h 15m 43s
> > Number of pages 46
> >
> > Then after using for a few minutes it now says:
> > Active Sessions 1
> > Uptime 1d, 10h 35m 52s
> > Number of pages 16500
> > (And yes one page was really added over the day)
> >
> > Where Number of pages is the [{$totalpages}]
> >
> > On the version 2.10.1 below is typical:
> >
> > Active Sessions 51
> > Uptime 0d, 18h 30m 39s
> > Number of pages 16390
> >
> > The ability to perform a search appears to be related to the
> > [{$totalpages}] variable. That is when it shows 46 almost nothing can be
> > found.
> >
> > I do see in the log:
> > 2022-04-20 10:12:22,050 [main] WARN
> > org.apache.wiki.providers.CachingProvider - seems
> > Ldapwiki.jspwiki.pageCache can't hold all pages from your page repository,
> > so we're delegating on the underlying provider instead. Please consider
> > increasing your cache sizes on ehcache.xml to avoid this behaviour
> >
> > Which led to the finding the entry in
> >
> > https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/main/resources/ini/jspwiki.properties
> > <
> > https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/main/resources/ini/jspwiki.properties
> > >
> >
> > "
> > *# By default, JSPWiki caches will hold up to 1.000 elements, except the
> > RSS cache, which will hold up to 250
> > elementsjspwiki.cache.custom-config-file = jspwiki-ehcache.xml*"
> >
> > Both are behind nginx.
> >
> > --
> > -jim
> > Jim Willeke
> >
> >
> > On Mon, Apr 18, 2022 at 3:40 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> > > Hi!
> > >
> > > Looking at the source code, at jspwiki init, a full reindex is triggered.
> > > The full reindex is only performed if the Lucene dir is empty. As this is
> > > not the case, the initial full reindex isn't executed, and that's why you
> > > are not seeing anything on searches. Pages saves do trigger a partial
> > > reindex, though, so that explains the other side of the behaviour you're
> > > seeing.
> > >
> > > What files 

Re: [External] Re: Search not working on unmodified files

[Juan Pablo Santos Rodríguez]

Hi!

Looking at the source code, at jspwiki init, a full reindex is triggered.
The full reindex is only performed if the Lucene dir is empty. As this is
not the case, the initial full reindex isn't executed, and that's why you
are not seeing anything on searches. Pages saves do trigger a partial
reindex, though, so that explains the other side of the behaviour you're
seeing.

What files are inside the Lucene dir? If there are Lucene index files, can
you open then with Luke to see where they came from, or the Lucene index
version, or any other information? Is there any chance other jspwiki
instance is using the same workDir?

Last, emptying the lucene dir will enforce a full reindex next time the
background thread responsible of performing Lucene reindexes runs, but it
would be better to know why some files are getting created there outside
your jspwiki instance.


HTH,
juan pablo

El lun., 18 abr. 2022 12:32, Andrew Ducker <
andrew_duc...@thephoenixgroup.com> escribió:

> Hi,
>
> Thanks for the reply.
>
> We completely cleared the WorkDir, to be on the safe side, and that didn’t
> help.
>
> It has access to the Work and wikipages folders, as it can create them
> from scratch, and you can edit the Wiki files.
>
> No mentions of “unable to index” in the logs.
>
> In the jspwiki-custom.properties file there’s the following:
> jspwiki.applicationName =IS Wiki
> jspwiki.baseURL = 
> jspwiki.frontPage = Main
> jspwiki.pageProvider =VersioningFileProvider
> jspwiki.fileSystemProvider.pageDir =d:/JSPWiki/JSPWikiPages/Pages/wiki/
> jspwiki.basicAttachmentProvider.storageDir
> =d:/JSPWiki/JSPWikiPages/Attachments/wiki/
> jspwiki.interWikiRef.Notes = Notes:%s
> jspwiki.translatorReader.inlinePattern.1 = *.jpg
> jspwiki.translatorReader.inlinePattern.2 = *.png
> jspwiki.translatorReader.inlinePattern.3 = http://images.com/*
> jspwiki.rss.generate =true
> jspwiki.rss.channelDescription = IS Wiki
> mail.from =@mail.from@
> mail.smtp.host =@mail.smtp.host@
> jspwiki.workDir =d:/JSPWiki/WorkingDirectory/iswiki/
> jspwiki.security = jaas
>
> Lucene-specific things in the logs:
> [INFO ] 2022-04-13 13:44:48.094 [main] o.a.w.s.LuceneSearchProvider -
> Lucene enabled, cache will be in: d:\JSPWiki\WorkingDirectory\iswiki\lucene
> [WARN ] 2022-04-13 13:44:48.725 [JSPWiki Lucene Indexer]
> o.a.w.WikiBackgroundThread - Starting up background thread: JSPWiki Lucene
> Indexer.
> [INFO ] 2022-04-13 13:45:48.732 [JSPWiki Lucene Indexer]
> o.a.w.s.LuceneSearchProvider - Files found in Lucene directory, not
> reindexing.
>
> So could it be starting to index, thinking it’s already indexed (despite
> the whole WorkingDir being cleared out) and then stopping near-instantly?
>
> Thanks again,
>
> Andy
>
>
> From: Juan Pablo Santos Rodríguez [mailto:juanpablo.san...@gmail.com]
> Sent: 14 April 2022 16:25
> To: user@jspwiki.apache.org
> Subject: [External] Re: Search not working on unmodified files
>
> Alert! This is an external email sent from juanpablo.san...@gmail.com.
>
> Hi Andrew,
>
> haven't had the time to look in depth at JSPWIKI-1171, so just some
> questions / random thoughts:
>
> JSPWiki has changed a lot since 2.8, but the wiki pages itself shouldn't
> require any change, and should be readable by any version of JSPWiki. The
> Lucene version has been upgraded several times, so it was definitely ok to
> clear your Lucene folder. Also there is the refmgr.ser file and refmgr-attr
> dir inside your workDir, which contain serialized information about page
> references. I'm not 100% sure, but most probably the internal format has
> changed since 2.8 (there was a global package rename on 2.9, when entering
> the Apache incubator, and somewhat later a public API was pushed which may
> have affected this format too) so you should delete those too and try to
> restart your JSPWiki instance again and see if the situation persists;
> perhaps deleting the entire workDir would be the safest approach. That's
> what seems to be happening from the stacktrace attached at JSPWIKI-1171
> (this list strips attachments, IIRC).
>
> Also, regarding the searches, would you mind confirming that the new
> JSPWiki instance has permissions to read/write either the work and
> wikipages directories/files? Also are there any errors logged when starting
> JSPWiki? Specifically, the Lucene indexing is done on startup (if needed)
> on the background, so eventually you should get all your pages indexed or
> see log errors stating something like "Unable to index page $pageName,
> continuing to next".
>
> Are you using a vanilla JSPWiki installation or do you have some
> customizations? What parameters do you have on your
> jspwiki-custom.properties file? I'm assuming you're deloying the war

Re: Search not working on unmodified files

[Juan Pablo Santos Rodríguez]

Hi Andrew,

haven't had the time to look in depth at JSPWIKI-1171, so just some
questions / random thoughts:

JSPWiki has changed a lot since 2.8, but the wiki pages itself shouldn't
require any change, and should be readable by any version of JSPWiki. The
Lucene version has been upgraded several times, so it was definitely ok to
clear your Lucene folder. Also there is the refmgr.ser file and refmgr-attr
dir inside your workDir, which contain serialized information about page
references. I'm not 100% sure, but most probably the internal format has
changed since 2.8 (there was a global package rename on 2.9, when entering
the Apache incubator, and somewhat later a public API was pushed which may
have affected this format too) so you should delete those too and try to
restart your JSPWiki instance again and see if the situation persists;
perhaps deleting the entire workDir would be the safest approach. That's
what seems to be happening from the stacktrace attached at JSPWIKI-1171
(this list strips attachments, IIRC).

Also, regarding the searches, would you mind confirming that the new
JSPWiki instance has permissions to read/write either the work and
wikipages directories/files? Also are there any errors logged when starting
JSPWiki? Specifically, the Lucene indexing is done on startup (if needed)
on the background, so eventually you should get all your pages indexed or
see log errors stating something like "Unable to index page $pageName,
continuing to next".

Are you using a vanilla JSPWiki installation or do you have some
customizations? What parameters do you have on your
jspwiki-custom.properties file? I'm assuming you're deloying the war file?


best regards,
juan pablo

On Thu, Apr 14, 2022 at 4:51 PM Andrew Ducker <
andrew_duc...@thephoenixgroup.com> wrote:

> Hi!
>
>
>
> I am having a problem with an upgraded JSPWiki not indexing pages.
>
>
>
> I wasn’t sure where to report it, so added an issue on Jira:
>
> https://issues.apache.org/jira/browse/JSPWIKI-1171
>
>
>
> I’m recreating it here, in case this is the right place to report things:
>
>
>
> Lots of pages aren't turning up in search.
>
>
>
> We cleared the lucene folder from the working directory, and it rebuilt it
> - but quite quickly for 13,000 pages.  And the total size of the Lucene
> files was around 2.5MB, which seemed far too small.
>
>
>
> Doing a search failed to bring back pages that had the given word in their
> name and content.
>
>
>
> Editing one of those pages (adding a space) caused it to then appear in
> the searches.
>
>
>
> Checking the logs I found a lot of errors in the form:
>
>
>
> [ERROR] 2022-04-12 15:50:17.274 [main] o.a.w.r.DefaultReferenceManager -
> Error while trying to fetch a page name; trying to cope with the situation.
>
> org.apache.wiki.api.exceptions.ProviderException: Illegal page name
>
>
>
> (See attachment for whole exception trace)
>
>
>
> Sadly, it doesn't tell me what the illegal page names are.
>
>
>
> This wiki has been upgraded from version 2.8 - are there compatibility
> issues with page names there?
>
>
>
> Any help you can give me gratefully received!
>
>
>
> Andy
>
>
>
> --
>
>
>
>
>
> 
> *Andrew Ducker* | Senior Systems Developer
> office: +441312458823 | mobile: 07980 86 86 39 | email:
> andrew_duc...@thephoenixgroup.com
> P Please help save the environment, print only if necessary.
> [image: logobadgefinal]
>
>
>
> Confidentiality - This email is confidential.
> Not meant for you? - If you don't think this email is meant for you,
> please let us know. Do not copy or forward the information it contains, and
> delete this email from your system.
> Views expressed - Any personal views or opinions expressed in this email
> are the sender's, and do not necessarily reflect the views of the Phoenix
> Group (Phoenix Group Holdings plc and its subsidiaries).
> Monitoring - We filter and monitor emails to protect our systems and to
> keep them running smoothly.
> Emailing us - Email isn't a secure form of communication. If you want to
> send us confidential information please send it by post. However, if you do
> communicate with us by email on any subject, you are giving us permission
> to email you back.
> Phoning us - Calls may be monitored and/or recorded to protect both you
> and us and help with our training. Call charges will vary.
> Standard Life Assurance Limited is registered in Scotland (SC286833) at
> Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH and authorised by
> the Prudential Regulation Authority and regulated by the Financial Conduct
> Authority and the Prudential Regulation Authority. www.standardlife.co.uk
> Standard Life Assurance Limited and Standard Life Assets and Employee
> Services Limited are companies in the Phoenix Group (Phoenix Group Holdings
> plc and its subsidiaries). www.thephoenixgroup.com
>

Re: Security Manager Removal

[Juan Pablo Santos Rodríguez]

Hi Jürgen

IIRC, the freshcookies dependency uses the security manager under the
covers, and there's also some code inside JSPWiki using the security
manager.

We even have https://issues.apache.org/jira/browse/JSPWIKI-129
(JSPWiki cannot run under a security manager), which was meant to
fully support it.

I suppose we'll have to replace all the security manager calls
somewhere down the road..


best regards,
juan pablo

On Thu, Mar 31, 2022 at 4:48 PM Jürgen Weber  wrote:
>
> There is a JEP to deprecate the Security Manager.
>
> Is that relevant for JSPWiki? There is the jspwiki.policy, does
> anybody know, if that needs the security manager?
>
> JEP 411: Deprecate the Security Manager for Removal
> https://openjdk.java.net/jeps/411

Re: Two Servers Sharing Common Wiki

[Juan Pablo Santos Rodríguez]

Hi Jerry,

Most probably, each JSPWiki instance is running with the cache enabled,
with its default values, and that's why they don't "see" the changes made
by the other instance.

One option is to provide a custom ehcache file which shared the cache with
the other instance. IIRC, that kind of setups require to enable multicast
ports to run, but you'd better check ehcache docs for that. If you're
running 2.11.1 or later you can pass a property on your
jspwiki[-custom].properties file with the file's location on classpath. If
you're below that version you'll have to do some wear surgery and edit the
ehcache file.

Another option could be disabling the cache, but that will impact your
performance. Depending on the setup and your requirements, the resulting
performance might be enough for you.

Last thing that comes to mind involves a more complex setup around your
JSPWiki instances: don't share the wiki files folder and put some balancer
in front of the instances (Apache web server, Nginx, etc.). Configure it so
that when a post request arrives, it is sent to both instances, so they
keep in sync. When you receive a get, just forward it to whatever instance
you see fit.


HTH,
juan pablo

El sáb., 5 mar. 2022 20:02, Jerry Malcolm  escribió:

> I have an environment on Amazon Web Services with 2 EC2s hosting 2
> different domains.  I have a separate common EFS (Elastic File System)
> drive that is mounted to both EC2s that holds the wiki pages.
>
> My objective is to share the same wiki on both domains.  But when I
> update the wiki on one domain, the changes don't show up on the other
> domain.  The updates are present in the 'pages' folder on the 2nd wiki.
> But I can't get the wiki to refresh and pick up the changes.  I have to
> reboot tomcat on the 2nd server in order to pick up the wiki changes.
> Is there anything I can configure or do in the 2nd wiki to force it to
> refresh from the repository and pick up the latest changes short of a
> Tomcat or Wiki restart?
>
> Thanks.
>
> Jerry
>
>

[CVE-2022-24948] Apache JSPWiki Cross-site scripting vulnerability on User Preferences screen

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.1

Description
A carefully crafted user preferences for submission could trigger an
XSS vulnerability on Apache JSPWiki, related to the user preferences
screen, which could allow the attacker to execute javascript in the
victim's browser and get some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.2 or later.

Credit
This issue was discovered by Paulos Yibelo, from Octagon Networks.

[CVE-2022-24947] Apache JSPWiki CSRF Account Takeover

[Juan Pablo Santos Rodríguez]

Severity
Critical

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.1

Description
Apache JSPWiki user preferences form is vulnerable to CSRF attacks,
which can lead to account takeover.

Mitigation
Apache JSPWiki users should upgrade to 2.11.2 or later. Installations
>= 2.7.0 can also enable user management workflows' manual approval to
mitigate the issue.

Credit
This issue was discovered initially by Cristian Borlovan from Ounce
Labs Security (ref. JSPWIKI-79), and later on and independently from
this by Paulos Yibelo, from Octagon Networks.

[ANNOUNCE] Apache JSPWiki 2.11.2 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki 2.11.2.

This is the third release on the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.2

The full change log is available here:
https://issues.apache.org/jira/browse/JSPWIKI/fixforversion/12351120

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/

The Apache JSPWiki Team

Re: logger changes for 2.11.0

[Juan Pablo Santos Rodríguez]

Hi Jürgen,

in order to ease file logging, last push adds an (unused) rolling file
appender with some sensible defaults. This way, to enable file logging
it'd only be needed to add the reference to the logger, f.ex.,
something like:
rootLogger.appenderRef.rolling.ref = RollingFile

in the jspwiki-custom.properties file. Also, every property from this
new appender can be overwritten on the jspwiki-custom.properties file,
as log4j is configured from the resulting properties parsed by
JSPWiki. Hope that this makes the logging customization easier.

cheers and happy new year everyone!

On Sun, Dec 26, 2021 at 5:09 PM Jürgen Weber  wrote:
>
> This config below in jspwiki-custom.properties works for me now, at
> least it writes the log, will see in some days, if it indeed rolls.
> Unfortunately log4j2 chose not to have a common prefix and thus a
> namespace for their property names, so it is kind of messy.
>
> # Give directory path where log files should get stored
> property.basePath = /home/wiki/JSPWiki
>
> # RollingFileAppender will print logs in file which can be rotated
> based on time or size
> appender.rolling.type = RollingFile
> appender.rolling.name = fileLogger
> appender.rolling.fileName= ${basePath}/jspwiki.log
> appender.rolling.filePattern= ${basePath}/jspwiki_%d{-MM-dd}.log.gz
> appender.rolling.layout.type = PatternLayout
> appender.rolling.layout.pattern = %d{-MM-dd HH:mm:ss.SSS} %level
> [%t] [%c] [%M] [%l] - %msg%n
> appender.rolling.policies.type = Policies
>
> rootLogger.level = info
> rootLogger.additivity = false
> rootLogger.appenderRef.rolling.ref = fileLogger
>
> Am Sa., 18. Dez. 2021 um 09:04 Uhr schrieb Juan Pablo Santos Rodríguez
> :
> >
> > Hi Jim,
> >
> > for a quick check, I set up the log level to debug and saw the file with
> > contents (I did the test with the cargo maven plugin, but that shouldn't
> > matter).
> >
> > Would you mind trying that? If you also have the log redirected to the
> > stdout, do you see log there? Also, setting status=debug on the properties
> > file, that should output all the loaded log4j2 configuration. What does it
> > show?
> >
> > Another difference between 2.10 and 2.11 is that the PropertyReader class
> > was making a lot of info log statements that are now debug statements, but
> > given some time, you'd definitely should see log messages on the file..
> >
> >
> > Best regards,
> > juan pablo
> >
> > El sáb., 18 dic. 2021 0:45, Jim Wise  escribió:
> >
> > > Does this work for you?
> > >
> > > I have this config (albeit with a different fileName), and while the files
> > > are created, they do not receive any log messages.
> > > --
> > > Jim Wise
> > > jw...@draga.com
> > >
> > >
> > >
> > >
> > >
> > > > On Dec 17, 2021, at 16:31, Juan Pablo Santos Rodríguez <
> > > juanpablo.san...@gmail.com> wrote:
> > > >
> > > > Hi Jürgen,
> > > >
> > > > there's a commented section on the jspwiki.properties file setting up
> > > > a rolling appender for the security log. The default configuration
> > > > should be the same as before, translated from the equivalent log4j1
> > > > configuration that was in place. With that example, the following
> > > > works for me:
> > > >
> > > > status = warn
> > > > name = jspwiki-log4j2-configuration
> > > >
> > > > apenders=console
> > > > appender.console.type = Console
> > > > appender.console.name = STDOUT
> > > > appender.console.layout.type = PatternLayout
> > > > appender.console.layout.pattern = %highlight{[%-5level]} %d{-MM-dd
> > > > HH:mm:ss.SSS} [%t] %c{1.} - %msg%n %ex
> > > >
> > > > appender.rolling.type = RollingFile
> > > > appender.rolling.name = RollingFile
> > > > appender.rolling.fileName = /tmp/jspwiki.log
> > > > appender.rolling.filePattern = jspwiki.log.%d{dd-MMM}.log.gz
> > > > appender.rolling.layout.type = PatternLayout
> > > > appender.rolling.layout.pattern = %d{-MM-dd HH:mm:ss} %-5p %m%n
> > > > appender.rolling.policies.type = Policies
> > > > appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
> > > > appender.rolling.policies.size.size=10MB
> > > > appender.rolling.strategy.type = DefaultRolloverStrategy
> > > > appender.rolling.strategy.max = 5
> > > >
> > > > # Log to 

Re: suggestions for a long loading page

[Juan Pablo Santos Rodríguez]

Hi Gary,

been doing some more tests. I've noticed that that page has a call to
the ReferringPagesPlugin, would you mind removing that line and seeing
if that speeds up the page load? I've set up a page with the same wiki
markup on a local wiki, and renders faster than what you're
experiencing, about 300ms. The ReferringPagesPlugin relies on the
ReferenceManager, which does a big amount of use of synchronized
methods, so if you're having a lot of people coming in, it may slow
down things. Also, I suspect that your cache may be full, so the page
may getting re-rendered every time and again, affecting page load
time.


regards,
juan pablo

On Thu, Dec 23, 2021 at 12:09 AM Juan Pablo Santos Rodríguez
 wrote:
>
> Hi Gary,
>
> Don't have the source in front of me right now, so mostly a hunch: looking at 
> your systeminfo page, cache hits vs misses is 5.4M vs 3.6M. That seems to me 
> like too many misses...
>
> Default cache configuration is for a thousand elements for each cache, so 
> given the amount of pages may be tweaking the cache configuration is the way 
> to go?
>
> Latest release allows to provide a custom ehcache file (please see changelog 
> file for details). If you're not on latest you'll have to manually edit the 
> file (IIRC, it is on the jspwiki-main jar, but I'm not completely sure right 
> now).
>
>
> HTH,
> juan pablo
>
> El mié., 22 dic. 2021 21:22, Gary Kephart  escribió:
>>
>>
>> I have a page that takes over 30 seconds to load. I've no doubt that
>> this is due to the 2200+ page links it has in it. It seems as though
>> there's still something that I could do to decrease that time.
>>
>> I have "jspwiki.usePageCache = true" in my jspwiki-custom.properties.
>>
>> I have tried to use ReferringPagesPlugin and tagging sets of the
>> referenced pages together using categories, like "Category A Character"
>> and "Category B Character". That would reduce the page to just 26 calls
>> to the ReferringPagesPlugin. But when adding 3-4 of those, it seemed to
>> make the page loading even longer.
>>
>> Here's the page:
>>
>> https://encyclopaedia-wot.org/Wiki.jsp?page=Characters%2C%20Aliases%20%26%20Nicknames
>>
>>
>> Any ideas?
>>
>>
>> Gary
>>
>> --
>> Gary Kephart
>> Facebook: gary.kephart
>> Twitter: @garykephart
>>
>> "The penalty that good men pay for not being interested in politics is to be 
>> governed by lesser men." -- Plato.
>>

Re: suggestions for a long loading page

[Juan Pablo Santos Rodríguez]

Hi Gary,

Don't have the source in front of me right now, so mostly a hunch: looking
at your systeminfo page, cache hits vs misses is 5.4M vs 3.6M. That seems
to me like too many misses...

Default cache configuration is for a thousand elements for each cache, so
given the amount of pages may be tweaking the cache configuration is the
way to go?

Latest release allows to provide a custom ehcache file (please see
changelog file for details). If you're not on latest you'll have to
manually edit the file (IIRC, it is on the jspwiki-main jar, but I'm not
completely sure right now).


HTH,
juan pablo

El mié., 22 dic. 2021 21:22, Gary Kephart  escribió:

>
> I have a page that takes over 30 seconds to load. I've no doubt that
> this is due to the 2200+ page links it has in it. It seems as though
> there's still something that I could do to decrease that time.
>
> I have "jspwiki.usePageCache = true" in my jspwiki-custom.properties.
>
> I have tried to use ReferringPagesPlugin and tagging sets of the
> referenced pages together using categories, like "Category A Character"
> and "Category B Character". That would reduce the page to just 26 calls
> to the ReferringPagesPlugin. But when adding 3-4 of those, it seemed to
> make the page loading even longer.
>
> Here's the page:
>
>
> https://encyclopaedia-wot.org/Wiki.jsp?page=Characters%2C%20Aliases%20%26%20Nicknames
>
>
> Any ideas?
>
>
> Gary
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to
> be governed by lesser men." -- Plato.
>
>

[ANNOUNCE] Apache JSPWiki 2.11.1 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki 2.11.1.

This is the second release on the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki
groupId, version 2.11.1

The full change log is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12350872

Apache JSPWiki contains a mitigation to log4j's CVE-2021-44228 by
upgrading to log4j 2.16.0
as well as a few other improvements and bug fixes. A curated change
log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to
get involved visit the project website at http://jspwiki.apache.org/


The Apache JSPWiki Team

Re: logger changes for 2.11.0

[Juan Pablo Santos Rodríguez]

Hi Jim,

for a quick check, I set up the log level to debug and saw the file with
contents (I did the test with the cargo maven plugin, but that shouldn't
matter).

Would you mind trying that? If you also have the log redirected to the
stdout, do you see log there? Also, setting status=debug on the properties
file, that should output all the loaded log4j2 configuration. What does it
show?

Another difference between 2.10 and 2.11 is that the PropertyReader class
was making a lot of info log statements that are now debug statements, but
given some time, you'd definitely should see log messages on the file..


Best regards,
juan pablo

El sáb., 18 dic. 2021 0:45, Jim Wise  escribió:

> Does this work for you?
>
> I have this config (albeit with a different fileName), and while the files
> are created, they do not receive any log messages.
> --
> Jim Wise
> jw...@draga.com
>
>
>
>
>
> > On Dec 17, 2021, at 16:31, Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
> >
> > Hi Jürgen,
> >
> > there's a commented section on the jspwiki.properties file setting up
> > a rolling appender for the security log. The default configuration
> > should be the same as before, translated from the equivalent log4j1
> > configuration that was in place. With that example, the following
> > works for me:
> >
> > status = warn
> > name = jspwiki-log4j2-configuration
> >
> > apenders=console
> > appender.console.type = Console
> > appender.console.name = STDOUT
> > appender.console.layout.type = PatternLayout
> > appender.console.layout.pattern = %highlight{[%-5level]} %d{-MM-dd
> > HH:mm:ss.SSS} [%t] %c{1.} - %msg%n %ex
> >
> > appender.rolling.type = RollingFile
> > appender.rolling.name = RollingFile
> > appender.rolling.fileName = /tmp/jspwiki.log
> > appender.rolling.filePattern = jspwiki.log.%d{dd-MMM}.log.gz
> > appender.rolling.layout.type = PatternLayout
> > appender.rolling.layout.pattern = %d{-MM-dd HH:mm:ss} %-5p %m%n
> > appender.rolling.policies.type = Policies
> > appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
> > appender.rolling.policies.size.size=10MB
> > appender.rolling.strategy.type = DefaultRolloverStrategy
> > appender.rolling.strategy.max = 5
> >
> > # Log to console, file
> > loggers=jspwiki
> > logger.jspwiki.name = org.apache.wiki
> > logger.jspwiki.level = info
> > logger.jspwiki.additivity = false
> > logger.jspwiki.appenderRef.stdout.ref = STDOUT
> > logger.jspwiki.appenderRef.rolling.ref = RollingFile
> >
> > I agree that's somewhat verbose. Maybe another option could be use the
> > 'jspwiki.use.external.logconfig=true' property and provide custom
> > log4j2.[xml|properties|whatever expected by log4j] file? That's what's
> > done f.ex. on the Docker image. What other default configuration would
> > be more suitable? Perhaps providing some file appenders, but no using
> > them by default? I don't have a strong opinion on that so, for the
> > default log configuration with Log4J2 I went with the same as with
> > Log4J.
> >
> > Regarding the API change, it's not mandatory to do it in order to
> > migrate to 2.11 (although I'd recommend it to do it as soon as
> > possible, as the old methods should disappear on a-not-yet-defined
> > moment in the future). The jspwiki-210-adapters artifact should
> > reroute old methods to new ones. The jspwiki-210-test-adaptees tests
> > that the former module behaves as expected so, if it doesn't, then
> > that should be a bug :-/
> >
> > The rationale of the change began on JSPWIKI-303 (to provide an API
> > library); unfortunately this was easier said than done, as the
> > signature of the methods included the WikiContext, which is tied to
> > the WikiEngine, which in turn is tied to almost all JSPWiki code.
> > Thus, all the interfaces extraction for the api module, and the
> > changes on the WikiEngine et all between 2.10 and 2.11.
> >
> >
> > HTH,
> > juan pablo
> >
> > On Fri, Dec 17, 2021 at 8:39 PM Jürgen Weber  wrote:
> >>
> >> Finally found some time to update to 2.11.0.
> >> Experience was mixed.
> >> Had to port my plugins to the changed API (kind of frivolous to change
> >> the API of a mature product, I dare to say, and break all existing
> >> plugins), but this went rather smoothly.
> >> But I didn't get the new logging to work. Do I really have to add some
> >> 50 lines to my jspwiki-custom.properties to get a simple file logging?
> >> Aren't there defaults?
> >> Has anybody some simple lines to get a file log?
> >>
> >> Thanks,
> >> Juergen
>
>

Re: logger changes for 2.11.0

[Juan Pablo Santos Rodríguez]

Hi Jürgen,

there's a commented section on the jspwiki.properties file setting up
a rolling appender for the security log. The default configuration
should be the same as before, translated from the equivalent log4j1
configuration that was in place. With that example, the following
works for me:

status = warn
name = jspwiki-log4j2-configuration

apenders=console
appender.console.type = Console
appender.console.name = STDOUT
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = %highlight{[%-5level]} %d{-MM-dd
HH:mm:ss.SSS} [%t] %c{1.} - %msg%n %ex

appender.rolling.type = RollingFile
appender.rolling.name = RollingFile
appender.rolling.fileName = /tmp/jspwiki.log
appender.rolling.filePattern = jspwiki.log.%d{dd-MMM}.log.gz
appender.rolling.layout.type = PatternLayout
appender.rolling.layout.pattern = %d{-MM-dd HH:mm:ss} %-5p %m%n
appender.rolling.policies.type = Policies
appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
appender.rolling.policies.size.size=10MB
appender.rolling.strategy.type = DefaultRolloverStrategy
appender.rolling.strategy.max = 5

# Log to console, file
loggers=jspwiki
logger.jspwiki.name = org.apache.wiki
logger.jspwiki.level = info
logger.jspwiki.additivity = false
logger.jspwiki.appenderRef.stdout.ref = STDOUT
logger.jspwiki.appenderRef.rolling.ref = RollingFile

I agree that's somewhat verbose. Maybe another option could be use the
'jspwiki.use.external.logconfig=true' property and provide custom
log4j2.[xml|properties|whatever expected by log4j] file? That's what's
done f.ex. on the Docker image. What other default configuration would
be more suitable? Perhaps providing some file appenders, but no using
them by default? I don't have a strong opinion on that so, for the
default log configuration with Log4J2 I went with the same as with
Log4J.

Regarding the API change, it's not mandatory to do it in order to
migrate to 2.11 (although I'd recommend it to do it as soon as
possible, as the old methods should disappear on a-not-yet-defined
moment in the future). The jspwiki-210-adapters artifact should
reroute old methods to new ones. The jspwiki-210-test-adaptees tests
that the former module behaves as expected so, if it doesn't, then
that should be a bug :-/

The rationale of the change began on JSPWIKI-303 (to provide an API
library); unfortunately this was easier said than done, as the
signature of the methods included the WikiContext, which is tied to
the WikiEngine, which in turn is tied to almost all JSPWiki code.
Thus, all the interfaces extraction for the api module, and the
changes on the WikiEngine et all between 2.10 and 2.11.


HTH,
juan pablo

On Fri, Dec 17, 2021 at 8:39 PM Jürgen Weber  wrote:
>
> Finally found some time to update to 2.11.0.
> Experience was mixed.
> Had to port my plugins to the changed API (kind of frivolous to change
> the API of a mature product, I dare to say, and break all existing
> plugins), but this went rather smoothly.
> But I didn't get the new logging to work. Do I really have to add some
> 50 lines to my jspwiki-custom.properties to get a simple file logging?
> Aren't there defaults?
> Has anybody some simple lines to get a file log?
>
> Thanks,
> Juergen

[SECURITY] Apache JSPWiki affected by Apache Log4J CVE-2021-44228

[Juan Pablo Santos Rodríguez]

Hi all,

apologies for the cross-posting, please see below notice on how to
mitigate recent Log4J's RCE on existing JSPWiki 2.11.0 installations.

*
2021-12-13, Apache JSPWiki affected by Apache Log4J CVE-2021-44228

Severity: Critical

Versions Affected: 2.11.0

Description: Apache JSPWiki, 2.11.0 release is using a bundled version
of the Apache Log4J library vulnerable to Remote Code Execution. For
full impact and additional detail consult the Log4J security page.

Apache JSPWiki releases prior to 2.11.0 use Log4J 1.2.17 which may be
vulnerable for installations using non-default logging configurations
that include the JMS Appender, see
https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
for discussion.

Mitigation: Any of the following are enough to prevent this
vulnerability for Apache JSPWiki installations:
* Upgrade to upcoming Apache JSPWiki 2.11.1, which will include an
updated version of the log4j2 dependency. Alternatively, you can build
2.11.1-git-02 from master branch which also includes the updated
dependency.
* Manually update the version of Log4J2 on your runtime classpath and
restart your JSPWiki application.
* Adding the -Dlog4j2.formatMsgNoLookups=true to the JVM launching the
application (f.ex., adding it to the CATALINA_OPTS variable under
tomcat).

As noted above, an upcoming release of Apache JSPWiki 2.11.1 with the
updated library is to be expected this week.

References: https://logging.apache.org/log4j/2.x/security.html

**

best regards,
juan pablo

[CVE-2021-44140] Apache JSPWiki Arbitrary file deletion on logout

[Juan Pablo Santos Rodríguez]

Severity
Critical

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M8

Description
Remote attackers may delete arbitrary files in a system hosting a
JSPWiki instance by using a carefuly crafted http request on logout,
given that those files are reachable to the user running the JSPWiki
instance.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0 or later.

Credit
This issue was discovered by haby0 (forha...@gmail.com) from Duxiaoman
Financial Security Team, who also proposed the fix for this issue.

[CVE-2021-40369] Apache JSPWiki Cross-site scripting vulnerability on Denounce plugin

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M8

Description
A carefully crafted plugin link invocation could trigger an XSS
vulnerability on Apache JSPWiki, related to the Denounce plugin, which
could allow the attacker to execute javascript in the victim's browser
and get some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0 or later.

Credit
This issue was discovered by map1e (r...@lazymaple.pw).

[ANNOUNCE] Apache JSPWiki 2.11.0 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki
2.11.0.

This is the first release after eight milestones on the 2.11 series of
Apache JSPWiki,
a feature-rich and extensible WikiWiki engine built around the standard JEE
components.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.0

The full change log is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12345152

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/


The Apache JSPWiki Team

Re: ReferringPagesPlugin with columns

[Juan Pablo Santos Rodríguez]

Hi Gary,

latest push allows ReferredPagesPlugin, ReferringPagesPlugin,
ReferringUndefinedPagesPlugin, UndefinedPagesPlugin and UnusedPagesPlugin
to accept a columns parameter, so the use of CSS will no longer be
necessary. This enhacement should make it for incoming 2.11.0.


cheers,
juan pablo

On Fri, Nov 5, 2021 at 9:38 PM Gary Kephart  wrote:

> On 11/5/2021 3:58 AM, Juan Pablo Santos Rodríguez wrote:
> > Hi Gary,
> >
> > the plugin itself doesn't have any parameters to have that kind of
> output.
> > However, you could add a custom CSS style [#1] so the list gets as many
> > columns as you need.
> >
> > This CSS could be built into all the referral plugins, it would be a nice
> > feature to have, so there's no need to have the custom CSS style and
> > instead have a 'columns' parameter. Would you mind opening a JIRA for
> this?
> > Or even better, a PR if you want to tackle this directly, should be
> > relatively easy, and you can always ask if you need guidance.
>
> I would tackle it myself, but I'm super busy converting my regular
> website to the wiki. Maybe in a month or two I could look at it.
> I've used a bunch of source control tools, most recently svn and TFVC,
> but haven't used Git yet. Something I need to learn.
>
> Gary
>
> >
> >
> > HTH,
> > juan pablo
> >
> >
> > [#1]
> >
> https://www.w3docs.com/snippets/html/how-to-display-an-unordered-list-in-two-columns.html
> >
> > On Tue, Nov 2, 2021 at 11:10 PM Gary Kephart 
> wrote:
> >
> >> The ReferringPagesPlugin is very handy, thanks. For my site, it would be
> >> very useful to be able to put the output in separate columns. I don't
> >> see a parameter for that, though. Is there any way I could get that sort
> >> of thing to work?
> >>
> >> Thanks,
> >> Gary
> >>
> >> --
> >> Gary Kephart
> >> Facebook: gary.kephart
> >> Twitter: @garykephart
> >>
> >> "The penalty that good men pay for not being interested in politics is
> to
> >> be governed by lesser men." -- Plato.
> >>
> >>
>
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to
> be governed by lesser men." -- Plato.
>
>

Re: ReferringPagesPlugin with columns

[Juan Pablo Santos Rodríguez]

Hi Gary,

the plugin itself doesn't have any parameters to have that kind of output.
However, you could add a custom CSS style [#1] so the list gets as many
columns as you need.

This CSS could be built into all the referral plugins, it would be a nice
feature to have, so there's no need to have the custom CSS style and
instead have a 'columns' parameter. Would you mind opening a JIRA for this?
Or even better, a PR if you want to tackle this directly, should be
relatively easy, and you can always ask if you need guidance.


HTH,
juan pablo


[#1]
https://www.w3docs.com/snippets/html/how-to-display-an-unordered-list-in-two-columns.html

On Tue, Nov 2, 2021 at 11:10 PM Gary Kephart  wrote:

> The ReferringPagesPlugin is very handy, thanks. For my site, it would be
> very useful to be able to put the output in separate columns. I don't
> see a parameter for that, though. Is there any way I could get that sort
> of thing to work?
>
> Thanks,
>Gary
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to
> be governed by lesser men." -- Plato.
>
>

Re: Converting JSPWiki to HTML

[Juan Pablo Santos Rodríguez]

Hi,

you can also use a RenderingManager + MarkupParser, you can see an example
at [#1]. Note that wiki markup may contain
plugins, acls, variables, etc., tldr: you'll need a running WikiEngine to
do the wiki -> html conversion. If you need to run this
conversion on a standalone basis, the TestEngine from the
org.apache.jspwiki:jspwiki-main:LATEST:test-jar artifact may be
suitable for this task; although it's meant to ease testing, nothing stops
you to use it on a standalone application. You can
see some doc on how to use it at [#2].

On a related note, and similar to this, you can also use JSPWiki to perform
markdown -> html conversion, see markdown
renderer tests at [#3].


HTH,
juan pablo

[#1]:
https://github.com/apache/jspwiki/blob/master/jspwiki-main/src/test/java/org/apache/wiki/render/RenderingManagerTest.java#L118-L126
[#2]:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=JSPWikiPublicAPI#section-JSPWikiPublicAPI-Testing
[#3]:
https://github.com/apache/jspwiki/blob/master/jspwiki-markdown/src/test/java/org/apache/wiki/render/markdown/MarkdownRendererTest.java#L305

On Tue, Oct 5, 2021 at 11:10 PM Jürgen Weber  wrote:

> There is
>
>
> https://jspwiki.apache.org/apidocs/2.11.0.M4/org/apache/wiki/WikiEngine.html#getHTML-java.lang.String-
>
> Guess you could add a servlet/service/tag to JSPWiki that calls it
>
> Am Di., 5. Okt. 2021 um 12:27 Uhr schrieb Archan Ranade
> :
> >
> > Hi,
> >
> > Please let me know how to convert JSPWiki to HTML as a standalone
> utility? I do not want to deploy the JSPWiki to a Tomcat server. Instead, I
> want to achieve the functionality of converting JSPWiki to HTML through a
> main program as a standalone utility. Please let me know how to do this.
> The other way around seems simple enough by using
> HtmlStringToWikiTranslator for HTML to JSPWiki conversion. Please let me
> know how to do JSPWiki to HTML.
> >
> >
> > Thanks,
> > Archan Ranade
> >
> > [Logo]
> >
> > Archan Ranade | Software Engineer
> >
> > e: archan.ran...@opshub.com  | w:
> https://www.opshub.com/
> > p:  +1.650.701.1800
> >
> > [facebook icon] [twitter icon] <
> https://twitter.com/opshub/>  [youtube icon] <
> https://www.youtube.com/channel/UCuUvJx7xB1vQDRf6w8VwKIw?view_as=subscriber>
> [linkedin icon] 
> >
> >
>

Re: ImageMapPlus

[Juan Pablo Santos Rodríguez]

Hi,

yep, plugin should be recompiled using the classes under
jspwiki-api-LATEST.jar.

Another option would be using the %%maps style present on the Haddock
template [#1]


best regards,
juan pablo

[#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=Maps

On Wed, Sep 8, 2021 at 8:34 AM Ulf Dittmer
 wrote:

> Given "com/ecyrd/jspwiki/plugin/WikiPlugin", it can't work with current
> JSPWiki versions. These days, the corresponding class would
> be org.apache.wiki.api.plugin.WikiPlugin. So you'd have to modify the
> source code to use the org.apache.wiki package and classes rather
> than com.ecyrd.jspwiki. I don't know if merely changing class and package
> names will do, or if the API has changed in other ways as well.
>
> On Wed, Sep 8, 2021 at 3:26 AM Gary Kephart 
> wrote:
>
> > Is ImageMapPlus working for this version of JSPWiki? I followed the
> > directions here: https://www.ecyrd.com/JSPWiki/wiki/ImageMapPlus but got
> > the following error.
> >
> > Thanks,
> >Gary
> >
> >
> >   JSPWiki has detected an error
> >
> > Error Message
> > Failed to link org/nascif/jspwiki/plugin/imagemapplus/ImageMapPlus
> > (Module "deployment.ewot-2.11.0.M6.local.war" from Service Module
> > Loader): com/ecyrd/jspwiki/plugin/WikiPlugin
> > Exception
> > java.lang.NoClassDefFoundError
> > Place where detected
> > native methodjava.lang.ClassLoader.defineClass1(), line -2
> >
> > If you have changed the templates, please do check them. This error
> > message may show up because of that. If you have not changed them, and
> > you are either installing JSPWiki for the first time or have changed
> > configuration, then you might want to check your configuration files. If
> > you are absolutely sure that JSPWiki was running quite okay or you can't
> > figure out what is going on, then by all means, come over to
> > jspwiki.apache.org  and tell us. There is
> > more information in the log file (like the full stack trace, which you
> > should add to any error report).
> >
> > And don't worry - it's just a computer program. Nothing really serious
> > is probably going on: at worst you can lose a few nights sleep. It's not
> > like it's the end of the world.
> >
> > --
> > Gary Kephart
> > Facebook: gary.kephart
> > Twitter: @garykephart
> >
> > "The penalty that good men pay for not being interested in politics is to
> > be governed by lesser men." -- Plato.
> >
> >
>

Re: Ordered lists broken into columns restart numbering

[Juan Pablo Santos Rodríguez]

Hi Gary,

there's a multi-column style [#1] that can be combined with some in-place
css magic to achieve that:

%%add-css
.columns {
  counter-reset: mycounter
}
.columns ol {
  list-style: none;
}
.columns ol li:before {
  counter-increment: mycounter;
  content: counter(mycounter) ". ";
}
/%

#qwe
#qwe

%%columns
#asd
#asd

#asd
#asd

#asd
#asd
/%

#zxc
#zxc
#zxc

should retain numbering inside the columns, but not for the other numbered
lists (qwe and zxc should begin at 1, whereas asd lists on second and third
column should begin at 3 and 5). Each %%column section should begin at 1
too.

HTH,
juan pablo


[#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=Multi Columns Style

On Tue, Sep 7, 2021 at 8:34 AM Gary Kephart  wrote:

> Is there any way to break a long ordered list into columns and still
> retain the same numbering?
>
> Thanks,
>Gary
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to
> be governed by lesser men." -- Plato.
>
>

Re: Detect data directory changes

[Juan Pablo Santos Rodríguez]

Hi Alex,

perhaps the fastest way is to modify jspwiki's own ehcache.xml file,
building a differente war with different ehcache.xml setting up
ehcache file for each instance.

ehcache reference can be found at https://www.ehcache.org/ehcache.xml, but
perhaps following an example is easier.
https://javaheap.wordpress.com/2011/07/22/distributed-ehcache-setup/
(although old) seems to be a good starting point


HTH,
juan pablo

On Tue, Aug 17, 2021 at 10:08 AM Alex Rydzewski 
wrote:

> Kind times, Juan!
>
> Thanks for your explanations!
>
> In my case does not suppose to change wiki from external, if that may
> say. I have two VMs with jspwiki and frontend nginx (with load balance
> configuration) for reliability in cases when one instance will be
> stopped. People which changes wiki pages do it on one of instance and my
> problem is nothing changes on second without reload corresponding tomcat
> context.
>
> I will try implement first variant from your suggestions. Any additional
> information or ideas greatly appreciated.
>
>
> On 2021/07/27 13:31:13, Juan Pablo Santos Rodríguez 
> wrote:
>  > Hi Alex,>
>  >
>  > apologies for the delayed response.>
>  >
>  > JSPWiki by default uses ehcache to request pages faster. If a page is>
>  > changed externally to JSPWiki, it won't be able to detect that a
> change has>
>  > been made on that page, and won't see it until the cache expires.>
>  >
>  > Also, modifying a page externally to JSPWiki isn't usually a good idea,>
>  > when the new page content is picked up, the associated page metadata>
>  > changes (i.e., author) will be lost.>
>  >
>  > For this particular case though, given that you want to synchronize a
> page>
>  > repository for 2 JSPWiki installations, I can think of the following
> options>
>  >
>  > * configure ehcache so it runs on cluster, syncing both JSPWiki caches.>
>  > This is the most complex setup of all the options (requires some
> presumably>
>  > complex ehcache configuration which I haven't looked into, it'll be>
>  > specific to your installation, you'll have to tweak JSPWiki's ehcache>
>  > configuration).>
>  > * deactivate the caching mechanism on both instances, or at least in
> the>
>  > one which is being synced. Every time you hit JSPWiki you'll go to
> disk (or>
>  > where your page provider uses), so it'll be slower than the first
> case. How>
>  > slower will depend (again) on multiple factors and might be
> reasonable to>
>  > you. You might gain the lost speed if you put a web server (Apache,
> Nginx)>
>  > in front of JSPWiki to cache its requests.>
>  > * cron some JSPWiki restarts, purging cache data between shutdown and>
>  > start. Ugly, but it is another option too.>
>  >
>  >
>  > best regards,>
>  > juan pablo>
>  >
>  > El lun., 19 jul. 2021 11:11, Alex Rydzewski >
>  > escribió:>
>  >
>  > > Kind times, jspwiki community!>
>  > >>
>  > > I have some trouble with next case...>
>  > >>
>  > > In my environment two virtual servers with tomcat9 and jspwiki has>
>  > > configured, which have ceph-fs shared the data directory. When any>
>  > > changes for jspwiki was did on one of the server, the changes applied>
>  > > only on that server.>
>  > >>
>  > > Tell me please, which is adecuate method for detect changes in data>
>  > > directory and apply them to jspwiki server.>
>  > >>
>  > > Thanks in advance.>
>  > >>
>  > > -->
>  > > З найкращими побажаннями, Олександр Ридзевський |With best regards,
> Mr.>
>  > > Alexander Rydzewski, |С наилучшими пожеланиями, Александр Рыдзевский>
>  > > Системний та мережевий інженер, Elyland ltd. |System and Network>
>  > > Engineer at Elyland ltd. |Системный и сетевой инженер, Elyland ltd.>
>  > >>
>  > >>
>  >
>
> --
> З найкращими побажаннями, Олександр Ридзевський |With best regards, Mr.
> Alexander Rydzewski,|С наилучшими пожеланиями, Александр Рыдзевский
> Системний та мережевий інженер, Elyland ltd.|System and Network
> Engineer at Elyland ltd.|Системный и сетевой инженер, Elyland ltd.
>
>

Re: Detect data directory changes

[Juan Pablo Santos Rodríguez]

Hi Alex,

apologies for the delayed response.

JSPWiki by default uses ehcache to request pages faster. If a page is
changed externally to JSPWiki, it won't be able to detect that a change has
been made on that page, and won't see it until the cache expires.

Also, modifying a page externally to JSPWiki isn't usually a good idea,
when the new page content is picked up, the associated page metadata
changes (i.e., author) will be lost.

For this particular case though, given that you want to synchronize a page
repository for 2 JSPWiki installations, I can think of the following options

* configure ehcache so it runs on cluster, syncing both JSPWiki caches.
This is the most complex setup of all the options (requires some presumably
complex ehcache configuration which I haven't looked into, it'll be
specific to your installation, you'll have to tweak JSPWiki's ehcache
configuration).
* deactivate the caching mechanism on both instances, or at least in the
one which is being synced. Every time you hit JSPWiki you'll go to disk (or
where your page provider uses), so it'll be slower than the first case. How
slower will depend (again) on multiple factors and might be reasonable to
you. You might gain the lost speed if you put a web server (Apache, Nginx)
in front of JSPWiki to cache its requests.
* cron some JSPWiki restarts, purging cache data between shutdown and
start. Ugly, but it is another option too.


best regards,
juan pablo

El lun., 19 jul. 2021 11:11, Alex Rydzewski 
escribió:

> Kind times, jspwiki community!
>
> I have some trouble with next case...
>
> In my environment two virtual servers with tomcat9 and jspwiki has
> configured, which have ceph-fs shared the data directory. When any
> changes for jspwiki was did on one of the server, the changes applied
> only on that server.
>
> Tell me please, which is adecuate method for detect changes in data
> directory and apply them to jspwiki server.
>
> Thanks in advance.
>
> --
> З найкращими побажаннями, Олександр Ридзевський |With best regards, Mr.
> Alexander Rydzewski,|С наилучшими пожеланиями, Александр Рыдзевский
> Системний та мережевий інженер, Elyland ltd.|System and Network
> Engineer at Elyland ltd.|Системный и сетевой инженер, Elyland ltd.
>
>

Re: DEBUG org.apache.wiki.WatchDog - http-nio-8080-exec-39: Exiting state Filtering for URL /JSPWiki/Edit.jsp

[Juan Pablo Santos Rodríguez]

Hi,

could hoy provide more details about your setup? I.e. any custom
configuration, log stacktraces (if any), etc.

Is this related to the previous access issue you had?


regards,
juan pablo

El sáb., 24 abr. 2021 14:05, Олександр Ридзевський 
escribió:

> Kind times!
>
> I have problem with jspwiki 2.11.0.M8 when try edit page. Logs of
> context show this:
> DEBUG org.apache.wiki.WatchDog  - http-nio-8080-exec-39: Exiting state
> Filtering for URL /JSPWiki/Edit.jsp
>
> Thanks for help in advance.
>
> --
> З найкращими побажаннями,   |With best regards,
> Олександр Ридзевський   |Alexander Rydzewski
>
>

Re: Any way for 2.11x to insert arbitrary page by URL

[Juan Pablo Santos Rodríguez]

Hi,

No need of custom plugins, you can use the viewer style, see [#1] :-)

Be aware rendering external sites might not be a great idea, due to it's
security implications.


Regards,
juan pablo

[#1]:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Viewer#section-Viewer-Usage

El dom., 25 abr. 2021 11:13, Олександр Ридзевський 
escribió:

> Good day, community!
>
> Does exist any way for insert arbitrary web page to wiki page by URL
> like this https://www.ecyrd.com/JSPWiki/wiki/AnyPluginToInsertArbitraryUrl
> For me the plugin does not work with 2.11x unfortunatly :(
>
>
> On 2021/04/24 09:57:47, Олександр Р...@gmail.com> wrote:
>  > Kind times!>
>  >
>  > I have problem with jspwiki 2.11.0.M8 when try edit page. Logs of >
>  > context show this:>
>  > DEBUG org.apache.wiki.WatchDog  - http-nio-8080-exec-39: Exiting state >
>  > Filtering for URL /JSPWiki/Edit.jsp>
>  >
>  > Thanks for help in advance.>
>  >
>  > -- >
>  > З найкращими побажаннями, |With best regards,>
>  > Олександр Ридзевський |Alexander Rydzewski>
>  >
>  >
>
> --
> З найкращими побажаннями,   |With best regards,
> Олександр Ридзевський   |Alexander Rydzewski
>
>

Re: JSPWiki: Unable to load and setup properties from jspwiki.properties

[Juan Pablo Santos Rodríguez]

Hi Alex,

(apologies for brevity & typos, on mobile)

Inside the 2nd stacktrace you can see the root cause:
java.io.IOException: Page directory is not writable: /var/lib/jspwiki/pages

First stacktrace contains a similar error, but for a different folder,
please check permissions on those files for the user running JSPWiki.

Best regards,
juan pablo

El mié., 21 abr. 2021 12:09, Alex Rydzewski 
escribió:

> Kind times!
>
> I have the same problems which referenced here
> https://www.mail-archive.com/user@jspwiki.apache.org/msg00903.html
> with Debian 10, Tomcat9 (9.0.31) installed from distro deb, and JSPWiki
> installed as webapps.
>
> After deploy JSPWiki.war (2.11.0.M8) I see next.
>
> With #export CATALINA_OPTS="-log4j.rootCategory=DEBUG,ConsoleLog"
>
> Catalina.out:
>
> [2021-04-21 11:56:30] [info] Deploying web application archive
> [/var/lib/tomcat9/webapps/JSPWiki.war]
> [2021-04-21 11:56:31] [info] At least one JAR was scanned for TLDs yet
> contained no TLDs. Enable debug logging for this logger for a complete
> list of JARs that were scanned but no TLDs were found in them. Skipping
> unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> [2021-04-21 11:56:32] [info] log4j:WARN No appenders could be found for
> logger (org.apache.wiki.util.PropertyReader).
> [2021-04-21 11:56:32] [info] log4j:WARN Please initialize the log4j
> system properly.
> [2021-04-21 11:56:32] [info] log4j:WARN See
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,132 [main] INFO
> org.apache.wiki.util.PropertyReader  - No jspwiki.custom.config defined
> for this context, looking for custom properties file with default name
> of: /jspwiki-custom.properties
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,133 [main] INFO
> org.apache.wiki.util.PropertyReader  - No custom property file found,
> relying on JSPWiki defaults.
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,134 [main] INFO
> org.apache.wiki.WikiEngine  - ***
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,134 [main] INFO
> org.apache.wiki.WikiEngine  - JSPWiki 2.11.0-M8 starting. Whee!
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,137 [main] INFO
> org.apache.wiki.WikiEngine  - Servlet container: Apache Tomcat/9.0.31
> (Debian)
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,137 [main] INFO
> org.apache.wiki.WikiEngine  - JSPWiki working directory is
> '/tmp/JSPWiki-865835113'
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,334 [main] ERROR
> org.apache.wiki.pages.DefaultPageManager  - An I/O exception occurred
> while trying to create a new page provider:
> org.apache.wiki.providers.CachingProvider
> [2021-04-21 11:56:32] [info] java.io.IOException: Failed to create page
> directory /jspwiki-files , please check property
> jspwiki.fileSystemProvider.pageDir
> [2021-04-21 11:56:32] [info] #011at
>
> org.apache.wiki.providers.AbstractFileProvider.initialize(AbstractFileProvider.java:125)
> [2021-04-21 11:56:32] [info] #011at
>
> org.apache.wiki.providers.CachingProvider.initialize(CachingProvider.java:156)
> [2021-04-21 11:56:32] [info] #011at
>
> org.apache.wiki.pages.DefaultPageManager.(DefaultPageManager.java:131)
> [2021-04-21 11:56:32] [info] #011at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>
> Method)
> [2021-04-21 11:56:32] [info] #011at
>
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [2021-04-21 11:56:32] [info] #011at
>
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [2021-04-21 11:56:32] [info] #011at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> [2021-04-21 11:56:32] [info] #011at
> org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:308)
> [2021-04-21 11:56:32] [info] #011at
> org.apache.wiki.WikiEngine.initComponent(WikiEngine.java:401)
> [2021-04-21 11:56:32] [info] 2021-04-21 11:56:32,337 [main] FATAL
> org.apache.wiki.WikiEngine  - JSPWiki could not start, due to an unknown
> exception when starting.
> [2021-04-21 11:56:32] [info] java.lang.reflect.InvocationTargetException
> [2021-04-21 11:56:32] [info] #011at
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>
> Method)
> [2021-04-21 11:56:32] [info] #011at
>
> java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> [2021-04-21 11:56:32] [info] #011at
>
> java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> [2021-04-21 11:56:32] [info] #011at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
> [2021-04-21 11:56:32] [info] #011at
> org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:308)
> [2021-04-21 11:56:32] [info] 

Re: Left Menu width (Haddock)

[Juan Pablo Santos Rodríguez]

Hi,

as a side note, and because I remember noticing / asking time ago, why the
21.654752221994123% and not anything else,
rounder, like f.ex 20%? Well it is so the Sidebar and the page content
mantain a golden ratio based proportion; even more,
phi is declared as a less variable on source! [#1]

This way the page layout is more visually appealing; on the former source
link there is also a link to an article with a formal
explanation on the reasoning of this kind of layouts.

It is one of those things that really catches my eye every time I stumble
upon it - you have to put a lot care and attention to
details to came up with things like this. Every time I pass through there
it's like, hats off, Dirk!


cheers,
juan pablo

[#1]:
https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/styles/haddock/default/variables.less#L97-L103

On Mon, Apr 19, 2021 at 7:33 AM Gary Kephart  wrote:

> That worked very nicely.
>
> Thanks,
>Gary
>
> On 4/18/2021 4:34 AM, Dirk Frederickx wrote:
> > Hi Gary,
> >
> > Tx for the question.
> > Changing the style of the left-menu is not trivial, because of the way it
> > is currently set up.  (ref. compatibility with older browsers)
> > Hence I created a how-to page:
> >
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=How%20to%20change%20the%20width%20of%20the%20LeftMenu
> >
> > Hope this helps,
> > dirk
> >
> >
> > On Sun, Apr 18, 2021 at 1:25 AM Gary Kephart 
> wrote:
> >
> >> What's the best way to change the LeftMenu width?
> >>
> >> I can tell that it's actually the "sidebar" class's width that needs to
> >> be changed. It's currently set to 21.654752221994123% and I'd like it
> >> more like 15%. The "page" class width is 78.34524777800587%. Obviously,
> >> there's some computation that's going on, and I'm betting it's with
> >> Bootstrap, but I'm not very familiar with Bootstrap.
> >>
> >> Thanks,
> >> Gary
> >>
> >> --
> >> Gary Kephart
> >> Facebook: gary.kephart
> >> Twitter: @garykephart
> >>
> >> "The penalty that good men pay for not being interested in politics is
> to
> >> be governed by lesser men." -- Plato.
> >>
> >>
>
>
> --
> Gary Kephart
> Facebook: gary.kephart
> Twitter: @garykephart
>
> "The penalty that good men pay for not being interested in politics is to
> be governed by lesser men." -- Plato.
>
>

Re: JSPWiki: Unable to load and setup properties from jspwiki.properties

[Juan Pablo Santos Rodríguez]

Hi,

apologies on not answering before. Couple things to try:

- would you mind start your tomcat instance passing as env variable
"log4j.rootCategory=DEBUG,ConsoleLog" and attach the contents of
catalina.out? You can see a couple examples on how to do this at [#1]

- would you mind trying to start your JSPWiki with latest snapshot (you can
obtain it at [#2])? This snapshot should log the stacktrace, which should
at least give a hint of what is happening


HTH,
juan pablo

[#1]:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Getting%20Started#section-Getting+Started-Configuration
[#2]:
https://repository.apache.org/service/local/artifact/maven/redirect?r=snapshots=org.apache.jspwiki=jspwiki-war=2.11.0-SNAPSHOT=war

On Fri, Jan 1, 2021 at 2:35 PM Jim Willeke  wrote:

> I am still stuck.
> Have repeated this process a few times and still obtain the same results.
>
> The file ldapwiki.war was deployed to /var/lib/tomcat9/webapps/ldapwiki.war
> -rw-r--r-- 1 root root 24143885 Dec 20 12:23
> /var/lib/tomcat9/webapps/ldapwiki.war
>
> We see that the ldapwiki.war was expanded to:
> drwxr-x--- 10 tomcat tomcat 4096 Dec 20 12:25 ldapwiki/
>
> When started we see: less /var/log/tomcat9/localhost.2021-01-01.log
>
> 01-Jan-2021 12:47:59.264 INFO [main]
> org.apache.catalina.core.ApplicationContext.log  Assigning new engine to
> 1027332579
> 01-Jan-2021 12:48:00.149 INFO [main]
> org.apache.catalina.core.ApplicationContext.log JSPWiki: *Unable to load
> and setup properties from jspwiki.properties*. Failed to start. Caused by:
> null; please check log files for better information.
>
>
> Verified that the file exists:
> -rw-r- 1 tomcat tomcat 1055100 Dec 9 19:16
> /var/lib/tomcat9/webapps/ldapwiki/WEB-INF/lib/jspwiki-main-2.11.0.M8.jar
>
> Verified that the jspwiki.properties file exists:
> jar tvf
> /var/lib/tomcat9/webapps/ldapwiki/WEB-INF/lib/jspwiki-main-2.11.0.M8.jar |
> grep 'jspwiki.properties'
>  44746 Wed Dec 09 19:16:24 UTC 2020 ini/jspwiki.properties
>
> Any ideas why Tomcat9 did not find the jspwiki.properties file?
> --
> -jim
> Jim Willeke
>
>
> On Sun, Dec 27, 2020 at 3:34 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi,
> >
> > it's located in
> > JSPWiki.war!WEB-INF/lib/jspwiki-main-2.11.0.M8.jar!ini/jspwiki.properties
> >
> >
> > br,
> > juan pablo
> >
> > On Sun, Dec 27, 2020 at 12:46 PM Jim Willeke  wrote:
> >
> > > Where is jspwiki.properties located within the JSPWiki.war file?
> > >
> > > I see it nowhere in
> > >
> https://apache.osuosl.org/jspwiki/2.11.0.M8/binaries/webapp/JSPWiki.war
> > >
> > > --
> > > -jim
> > > Jim Willeke
> > >
> > >
> > > On Mon, Dec 21, 2020 at 3:22 PM Jim Willeke  wrote:
> > >
> > > > And that is what I have attempted.
> > > > And even that does not work.
> > > > --
> > > > -jim
> > > > Jim Willeke
> > > >
> > > >
> > > > On Mon, Dec 21, 2020 at 12:29 PM Juan Pablo Santos Rodríguez <
> > > > juanpablo.san...@gmail.com> wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> given that the OS, Let's Encrypt, Tomcat, etc. are correctly
> > installed,
> > > >> I'd
> > > >> begin with a simple, non-customized jspwiki war to make sure it
> > deploys
> > > >> OK. If there are problems, what's the log saying? Are you able to
> set
> > it
> > > >> to
> > > >> debug level (through JAVA_OPTS, or whatever method)?
> > > >>
> > > >> Once you have that, I'd begin with JSPWiki customizations, f.ex., to
> > set
> > > >> the page directory you should be using a jspwiki-custom.properties
> > file.
> > > >> Where is it located? (the other option is that you've modified the
> > > >> ini/jspwiki.properties inside the jspwiki-main jar, but that's
> > > >> discouraged,
> > > >> since it
> > > >> would made JSPWiki upgrades more complex).
> > > >>
> > > >>
> > > >> best regards,
> > > >> juan pablo
> > > >>
> > > >> On Sat, Dec 19, 2020 at 10:44 PM Jim Willeke 
> wrote:
> > > >>
> > > >> > The issue I have always run into is that upgrading is a huge pain.
> > > >> > It is never Just JSPwiki but all the dependencies.
> > > >> >
> > > >> > These are the facets for upgrades I came up with

Re: wro4j upgrade

[Juan Pablo Santos Rodríguez]

Hi Dirk,

ugh :-( I'll revert it later today, didn't see on the release notes
provided by dependabot any reference to newer JDKs needed, but in fact it
is noted there; I'm seeing now that beginning with wro4j 1.9.0, it requires
JDK >= 9. At home I use JDK 15, so didn't catch it here either..

Will also look into enhancing the Jenkinsfile to ensure JSPWiki builds
against JDKs 8 (minimum required by JSPWiki), 11 (latest LTS, also minimum
needed to run sonar analysis) and 15 (latest jdk).

Apologies for the inconveniences caused by this.


best regards,
juan pablo


El dom., 3 ene. 2021 23:35, Dirk Frederickx 
escribió:

> Hi Juan,
>
> In the latest commit, the wro4j version was bumped from 1.8.0 to 1.10.1.
>
> Unfortunately this requires JSPWiki to step-up its minimum JAVA versions to
> 9.
>
> Was this intentional ?
>
>
> dirk
>

Re: JSPWiki: Unable to load and setup properties from jspwiki.properties

[Juan Pablo Santos Rodríguez]

Hi,

it's located in
JSPWiki.war!WEB-INF/lib/jspwiki-main-2.11.0.M8.jar!ini/jspwiki.properties


br,
juan pablo

On Sun, Dec 27, 2020 at 12:46 PM Jim Willeke  wrote:

> Where is jspwiki.properties located within the JSPWiki.war file?
>
> I see it nowhere in
> https://apache.osuosl.org/jspwiki/2.11.0.M8/binaries/webapp/JSPWiki.war
>
> --
> -jim
> Jim Willeke
>
>
> On Mon, Dec 21, 2020 at 3:22 PM Jim Willeke  wrote:
>
> > And that is what I have attempted.
> > And even that does not work.
> > --
> > -jim
> > Jim Willeke
> >
> >
> > On Mon, Dec 21, 2020 at 12:29 PM Juan Pablo Santos Rodríguez <
> > juanpablo.san...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> given that the OS, Let's Encrypt, Tomcat, etc. are correctly installed,
> >> I'd
> >> begin with a simple, non-customized jspwiki war to make sure it deploys
> >> OK. If there are problems, what's the log saying? Are you able to set it
> >> to
> >> debug level (through JAVA_OPTS, or whatever method)?
> >>
> >> Once you have that, I'd begin with JSPWiki customizations, f.ex., to set
> >> the page directory you should be using a jspwiki-custom.properties file.
> >> Where is it located? (the other option is that you've modified the
> >> ini/jspwiki.properties inside the jspwiki-main jar, but that's
> >> discouraged,
> >> since it
> >> would made JSPWiki upgrades more complex).
> >>
> >>
> >> best regards,
> >> juan pablo
> >>
> >> On Sat, Dec 19, 2020 at 10:44 PM Jim Willeke  wrote:
> >>
> >> > The issue I have always run into is that upgrading is a huge pain.
> >> > It is never Just JSPwiki but all the dependencies.
> >> >
> >> > These are the facets for upgrades I came up with:
> >> >
> >> >- Operating System
> >> >- let's Encrypt
> >> >- nginx
> >> >- Java
> >> >- Tomcat
> >> >- JSPWiki
> >> >   - jspwiki engine
> >> >   - jspwiki pages
> >> >
> >> > Frankly speaking, this is a real pain.
> >> >
> >> > Install setup created:
> >> > CATALINA_BASE: /var/lib/tomcat9
> >> > CATALINA_HOME: /usr/share/tomcat9
> >> >
> >> > tomcat user home as:
> >> > /opt/tomcat and using /bin/false
> >> >
> >> > And I thought page directory should be:
> >> > /opt/tomcat/jspwikipages/ldapwiki/
> >> >
> >> > Then I should be able to run:
> >> >
> >> >- sudo apt update
> >> >- sudo apt upgrade
> >> >
> >> > and the Operating system, let's Encrypt, nginx, Tomcat, and Java would
> >> all
> >> > be upgraded as needed.
> >> >
> >> > any thoughts?
> >> >
> >> > --
> >> > -jim
> >> > Jim Willeke
> >> >
> >> >
> >> > On Thu, Dec 17, 2020 at 2:19 PM Juan Pablo Santos Rodríguez <
> >> > juanpablo.san...@gmail.com> wrote:
> >> >
> >> > > Hi Jim,
> >> > >
> >> > > I've always have worked with an environment in which CATALINA_BASE
> ==
> >> > > CATALINA_HOME, said that, yes, your setup seems correct to
> >> > > me (also 2 min of google https://stackoverflow.com/a/29398713 seem
> to
> >> > > confirm that).
> >> > >
> >> > >
> >> > > best regards,
> >> > > juan pablo
> >> > >
> >> > > On Thu, Dec 17, 2020 at 2:19 PM Jim Willeke 
> wrote:
> >> > >
> >> > > > My setup is now:
> >> > > > DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
> >> > > > Apache Tomcat/9.0.31 (Ubuntu)
> >> > > > Java Home:  /usr/lib/jvm/java-13-openjdk-amd64
> >> > > > JVM Version:13.0.4+8-Ubuntu-120.04
> >> > > > CATALINA_BASE:  /var/lib/tomcat9
> >> > > > CATALINA_HOME:  /usr/share/tomcat9
> >> > > >
> >> > > > So I am assuming we would place the jspwiki.war (regardless of
> name)
> >> > into
> >> > > > the
> >> > > > $CATALINA_BASE/tomcat9/webapps/
> >> > > > And that is where we would expect to see the folder "jspwiki"
> >> created
> >> > > when
> >> > > > t

Re: JSPWiki: Unable to load and setup properties from jspwiki.properties

[Juan Pablo Santos Rodríguez]

Hi,

given that the OS, Let's Encrypt, Tomcat, etc. are correctly installed, I'd
begin with a simple, non-customized jspwiki war to make sure it deploys
OK. If there are problems, what's the log saying? Are you able to set it to
debug level (through JAVA_OPTS, or whatever method)?

Once you have that, I'd begin with JSPWiki customizations, f.ex., to set
the page directory you should be using a jspwiki-custom.properties file.
Where is it located? (the other option is that you've modified the
ini/jspwiki.properties inside the jspwiki-main jar, but that's discouraged,
since it
would made JSPWiki upgrades more complex).


best regards,
juan pablo

On Sat, Dec 19, 2020 at 10:44 PM Jim Willeke  wrote:

> The issue I have always run into is that upgrading is a huge pain.
> It is never Just JSPwiki but all the dependencies.
>
> These are the facets for upgrades I came up with:
>
>- Operating System
>- let's Encrypt
>- nginx
>- Java
>- Tomcat
>- JSPWiki
>   - jspwiki engine
>   - jspwiki pages
>
> Frankly speaking, this is a real pain.
>
> Install setup created:
> CATALINA_BASE: /var/lib/tomcat9
> CATALINA_HOME: /usr/share/tomcat9
>
> tomcat user home as:
> /opt/tomcat and using /bin/false
>
> And I thought page directory should be:
> /opt/tomcat/jspwikipages/ldapwiki/
>
> Then I should be able to run:
>
>- sudo apt update
>- sudo apt upgrade
>
> and the Operating system, let's Encrypt, nginx, Tomcat, and Java would all
> be upgraded as needed.
>
> any thoughts?
>
> --
> -jim
> Jim Willeke
>
>
> On Thu, Dec 17, 2020 at 2:19 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi Jim,
> >
> > I've always have worked with an environment in which CATALINA_BASE ==
> > CATALINA_HOME, said that, yes, your setup seems correct to
> > me (also 2 min of google https://stackoverflow.com/a/29398713 seem to
> > confirm that).
> >
> >
> > best regards,
> > juan pablo
> >
> > On Thu, Dec 17, 2020 at 2:19 PM Jim Willeke  wrote:
> >
> > > My setup is now:
> > > DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
> > > Apache Tomcat/9.0.31 (Ubuntu)
> > > Java Home:  /usr/lib/jvm/java-13-openjdk-amd64
> > > JVM Version:13.0.4+8-Ubuntu-120.04
> > > CATALINA_BASE:  /var/lib/tomcat9
> > > CATALINA_HOME:  /usr/share/tomcat9
> > >
> > > So I am assuming we would place the jspwiki.war (regardless of name)
> into
> > > the
> > > $CATALINA_BASE/tomcat9/webapps/
> > > And that is where we would expect to see the folder "jspwiki" created
> > when
> > > the war is expanded.
> > >
> > > And the jspwiki.war would be owned by tomcat.
> > > Is that correct?
> > >
> > > --
> > > -jim
> > > Jim Willeke
> > >
> > >
> > > On Tue, Dec 15, 2020 at 3:44 PM Juan Pablo Santos Rodríguez <
> > > juanpablo.san...@gmail.com> wrote:
> > >
> > > > Hi Jim,
> > > >
> > > > apologies, the e-mail got stuck in drafts and I didn't notice :-/
> > > >
> > > > the contents of the work folder were to see which war was deployed if
> > > > ldapwiki.war or folder.war.. The unfound jspwiki.properties file
> should
> > > be
> > > > inside the jspwiki-main jar, under the ini folder.
> > > >
> > > > As for starting tomcat passing some system properties and as it seems
> > > that
> > > > the jspwiki.properties file can't be found when starting JSPWiki, on
> > your
> > > > $TOMCAT_HOME/bin/catalina.sh file, locate the commented line were the
> > > > JAVA_OPTS variable is set and uncomment it and set it to something
> > like:
> > > >
> > > > JAVA_OPTS="$JAVA_OPTS -Dlog4j.rootCategory=DEBUG,ConsoleLog" and that
> > > > should be fine to start tomcat.
> > > >
> > > > Also, do you have any jspwiki-custom.properties file set? is so, how?
> > > >
> > > > Last but not least, would you mind trying with new 2.11.0.M8? it
> > > contains a
> > > > couple of serious fixes related to search indexing + workflows'
> > > persistence
> > > > on disk
> > > >
> > > >
> > > > best regards,
> > > > juan pablo
> > > >
> > > > On Mon, Dec 7, 2020 at 4:13 PM Jim Willeke  wrote:
> > > >
> > > > > I changed to folder.war, as I was making a feeble attempt to hide
> > >

Re: JSPWiki: Unable to load and setup properties from jspwiki.properties

[Juan Pablo Santos Rodríguez]

Hi Jim,

I've always have worked with an environment in which CATALINA_BASE ==
CATALINA_HOME, said that, yes, your setup seems correct to
me (also 2 min of google https://stackoverflow.com/a/29398713 seem to
confirm that).


best regards,
juan pablo

On Thu, Dec 17, 2020 at 2:19 PM Jim Willeke  wrote:

> My setup is now:
> DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS"
> Apache Tomcat/9.0.31 (Ubuntu)
> Java Home:  /usr/lib/jvm/java-13-openjdk-amd64
> JVM Version:13.0.4+8-Ubuntu-120.04
> CATALINA_BASE:  /var/lib/tomcat9
> CATALINA_HOME:  /usr/share/tomcat9
>
> So I am assuming we would place the jspwiki.war (regardless of name) into
> the
> $CATALINA_BASE/tomcat9/webapps/
> And that is where we would expect to see the folder "jspwiki" created when
> the war is expanded.
>
> And the jspwiki.war would be owned by tomcat.
> Is that correct?
>
> --
> -jim
> Jim Willeke
>
>
> On Tue, Dec 15, 2020 at 3:44 PM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi Jim,
> >
> > apologies, the e-mail got stuck in drafts and I didn't notice :-/
> >
> > the contents of the work folder were to see which war was deployed if
> > ldapwiki.war or folder.war.. The unfound jspwiki.properties file should
> be
> > inside the jspwiki-main jar, under the ini folder.
> >
> > As for starting tomcat passing some system properties and as it seems
> that
> > the jspwiki.properties file can't be found when starting JSPWiki, on your
> > $TOMCAT_HOME/bin/catalina.sh file, locate the commented line were the
> > JAVA_OPTS variable is set and uncomment it and set it to something like:
> >
> > JAVA_OPTS="$JAVA_OPTS -Dlog4j.rootCategory=DEBUG,ConsoleLog" and that
> > should be fine to start tomcat.
> >
> > Also, do you have any jspwiki-custom.properties file set? is so, how?
> >
> > Last but not least, would you mind trying with new 2.11.0.M8? it
> contains a
> > couple of serious fixes related to search indexing + workflows'
> persistence
> > on disk
> >
> >
> > best regards,
> > juan pablo
> >
> > On Mon, Dec 7, 2020 at 4:13 PM Jim Willeke  wrote:
> >
> > > I changed to folder.war, as I was making a feeble attempt to hide
> details
> > > about ldapwiki.
> > >
> > > Not sure what you are looking for here:
> > > ll /var/lib/tomcat9/work/Catalina/localhost/
> > > total 24
> > > drwxr-x--- 6 tomcat tomcat 4096 Dec  4 10:43 ./
> > > drwxr-x--- 3 tomcat tomcat 4096 Dec  4 09:49 ../
> > > drwxr-x--- 3 tomcat tomcat 4096 Dec  4 11:55 host-manager/
> > > drwxr-x--- 2 tomcat tomcat 4096 Dec  4 10:43 ldapwiki/
> > > drwxr-x--- 3 tomcat tomcat 4096 Dec  6 10:48 manager/
> > > drwxr-x--- 2 tomcat tomcat 4096 Dec  4 09:49 ROOT/
> > >
> > > /var/lib/tomcat9/work/Catalina/localhost/ldapwiki/
> > > total 8
> > > drwxr-x--- 2 tomcat tomcat 4096 Dec  4 10:43 ./
> > > drwxr-x--- 6 tomcat tomcat 4096 Dec  4 10:43 ../
> > >
> > > Sorry, No idea how I would start tomcat using
> > > "-Dlog4j.rootCategory=DEBUG,ConsoleLog"
> > >
> > > systemctl status tomcat9
> > > ● tomcat9.service - Apache Tomcat 9 Web Application Server
> > >  Loaded: loaded (/lib/systemd/system/tomcat9.service; enabled;
> vendor
> > > preset: enabled)
> > >  Active: active (running) since Sun 2020-12-06 10:48:37 UTC; 1 day
> 4h
> > > ago
> > >Docs: https://tomcat.apache.org/tomcat-9.0-doc/index.html
> > > Process: 549
> > ExecStartPre=/usr/libexec/tomcat9/tomcat-update-policy.sh
> > > (code=exited, status=0/SUCCESS)
> > >Main PID: 574 (java)
> > >   Tasks: 37 (limit: 4620)
> > >  Memory: 255.9M
> > >  CGroup: /system.slice/tomcat9.service
> > >  └─574 /usr/lib/jvm/default-java/bin/java
> > >
> -Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
> > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> > > -Djava.awt.headless=true -Djdk.tls.ephemeralDHKe>
> > >
> > >
> > > --
> > > -jim
> > > Jim Willeke
> > >
> > >
> > > On Mon, Dec 7, 2020 at 9:09 AM Juan Pablo Santos Rodríguez <
> > > juanpablo.san...@gmail.com> wrote:
> > >
> > > > Hi Jim,
> > > >
> > > > you mention initially that the war is deployed as folder.war instead
> of
> > > > ldapwiki.war, is that correct? What files are plac

Re: JSPWiki: Unable to load and setup properties from jspwiki.properties

[Juan Pablo Santos Rodríguez]

Hi Jim,

apologies, the e-mail got stuck in drafts and I didn't notice :-/

the contents of the work folder were to see which war was deployed if
ldapwiki.war or folder.war.. The unfound jspwiki.properties file should be
inside the jspwiki-main jar, under the ini folder.

As for starting tomcat passing some system properties and as it seems that
the jspwiki.properties file can't be found when starting JSPWiki, on your
$TOMCAT_HOME/bin/catalina.sh file, locate the commented line were the
JAVA_OPTS variable is set and uncomment it and set it to something like:

JAVA_OPTS="$JAVA_OPTS -Dlog4j.rootCategory=DEBUG,ConsoleLog" and that
should be fine to start tomcat.

Also, do you have any jspwiki-custom.properties file set? is so, how?

Last but not least, would you mind trying with new 2.11.0.M8? it contains a
couple of serious fixes related to search indexing + workflows' persistence
on disk


best regards,
juan pablo

On Mon, Dec 7, 2020 at 4:13 PM Jim Willeke  wrote:

> I changed to folder.war, as I was making a feeble attempt to hide details
> about ldapwiki.
>
> Not sure what you are looking for here:
> ll /var/lib/tomcat9/work/Catalina/localhost/
> total 24
> drwxr-x--- 6 tomcat tomcat 4096 Dec  4 10:43 ./
> drwxr-x--- 3 tomcat tomcat 4096 Dec  4 09:49 ../
> drwxr-x--- 3 tomcat tomcat 4096 Dec  4 11:55 host-manager/
> drwxr-x--- 2 tomcat tomcat 4096 Dec  4 10:43 ldapwiki/
> drwxr-x--- 3 tomcat tomcat 4096 Dec  6 10:48 manager/
> drwxr-x--- 2 tomcat tomcat 4096 Dec  4 09:49 ROOT/
>
> /var/lib/tomcat9/work/Catalina/localhost/ldapwiki/
> total 8
> drwxr-x--- 2 tomcat tomcat 4096 Dec  4 10:43 ./
> drwxr-x--- 6 tomcat tomcat 4096 Dec  4 10:43 ../
>
> Sorry, No idea how I would start tomcat using
> "-Dlog4j.rootCategory=DEBUG,ConsoleLog"
>
> systemctl status tomcat9
> ● tomcat9.service - Apache Tomcat 9 Web Application Server
>  Loaded: loaded (/lib/systemd/system/tomcat9.service; enabled; vendor
> preset: enabled)
>  Active: active (running) since Sun 2020-12-06 10:48:37 UTC; 1 day 4h
> ago
>Docs: https://tomcat.apache.org/tomcat-9.0-doc/index.html
> Process: 549 ExecStartPre=/usr/libexec/tomcat9/tomcat-update-policy.sh
> (code=exited, status=0/SUCCESS)
>Main PID: 574 (java)
>   Tasks: 37 (limit: 4620)
>  Memory: 255.9M
>  CGroup: /system.slice/tomcat9.service
>  └─574 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/var/lib/tomcat9/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.awt.headless=true -Djdk.tls.ephemeralDHKe>
>
>
> --
> -jim
> Jim Willeke
>
>
> On Mon, Dec 7, 2020 at 9:09 AM Juan Pablo Santos Rodríguez <
> juanpablo.san...@gmail.com> wrote:
>
> > Hi Jim,
> >
> > you mention initially that the war is deployed as folder.war instead of
> > ldapwiki.war, is that correct? What files are placed inside
> > $TOMCAT_HOME/work? Also, would you mind starting tomcat providing it a
> > "-Dlog4j.rootCategory=DEBUG,ConsoleLog" argument?
> > That should provide more information on catalina.out
> >
> >
> > best regards,
> > juan pablo
> >
> > On Sun, Dec 6, 2020 at 11:55 AM Jim Willeke  wrote:
> >
> > > Here is what I see:
> > >
> > > less /var/log/tomcat9/catalina.2020-12-06.log
> > > 06-Dec-2020 10:48:43.248 INFO [main]
> > > org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of
> > > deployment descriptor
> [/etc/tomcat9/Catalina/localhost/host-manager.xml]
> > > has finished in [416] ms
> > > 06-Dec-2020 10:48:43.252 INFO [main]
> > > org.apache.catalina.startup.HostConfig.deployWAR Deploying web
> > application
> > > archive [/var/lib/tomcat9/webapps/ldapwiki.war]
> > > 06-Dec-2020 10:48:45.254 INFO [main]
> > > org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was
> > scanned
> > > for TLDs yet contained no TLDs. Enable debug logging for this logger
> for
> > a
> > > complete list of JARs that were scanned but no TLDs were found in them.
> > > Skipping unneeded JARs during scanning can improve startup time and JSP
> > > compilation time.
> > > 06-Dec-2020 10:48:46.202 SEVERE [main]
> > > org.apache.catalina.core.StandardContext.startInternal One or more
> > Filters
> > > failed to start. Full details will be found in the appropriate
> container
> > > log file
> > > 06-Dec-2020 10:48:46.202 SEVERE [main]
> > > org.apache.catalina.core.StandardContext.startInternal Context
> > [/ldapwiki]
> > > startup failed due to previous errors
> > >

[ANNOUNCE] Apache JSPWiki 2.11.0.M8 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki
2.11.0.M8.

This is the eighth release towards the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components. M#
releases are as
production-ready as any other JSPWiki release, please see [#1] to know how
this label
is used on Apache JSPWiki releases.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.0.M8

The full change log is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12349271

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/


The Apache JSPWiki Team

[#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=VersioningProposal

Re: attachment security policy

[Juan Pablo Santos Rodríguez]

Hi Gary,

that's weird, before writting previous e-mail I double checked the
suggested approach using the following unit test

@Test
public void testAttachmentAcl() throws Exception {
m_engine.saveText( "TestDefaultPage", "Foo" );
final Attachment att = Wiki.contents().attachment( m_engine,
"TestDefaultPage", "TestAtt.txt" );
att.setAuthor( "FirstPost" );
m_engine.getManager( AttachmentManager.class ).storeAttachment(
att, m_engine.makeAttachmentFile() );

final Permission view = PermissionFactory.getPagePermission(
"*:TestDefaultPage/TestAtt.txt", "view" );
final Permission edit = PermissionFactory.getPagePermission(
"*:TestDefaultPage/TestAtt.txt", "edit" );

final Session session = WikiSessionTest.anonymousSession( m_engine );
Assertions.assertTrue( m_auth.checkPermission( session, view ),
"anonymous view" );
Assertions.assertTrue( m_auth.checkPermission( session, edit ),
"anonymous edit" );
}

and it passes for each of the following permissions on the policy file

grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
//permission org.apache.wiki.auth.permissions.PagePermission "*:*", "edit";
//permission org.apache.wiki.auth.permissions.PagePermission
"*:TestDefaultPage", "edit";
permission org.apache.wiki.auth.permissions.PagePermission
"*:TestDefaultPage/TestAtt.txt", "edit";
};

(same for view permissions on the policy file except for the test's last
assertion) Said that, I misunderstood your original e-mail, I was thinking
that anonymous
users weren't allowed to see (not edit) the wiki. Your policy file should
be enough to allow http://mysite.org/attach/LeftMenu/mylogo.png for
anonymous
users. Does the log show something unsual while accessing/requesting that
file? Would you mind setting the log level to debug to see if anything else
pops up?

I'm preparing the release for 2.11.0-M8 in a while, but will have a closer
look at this after that.


best regards,
juan pablo


On Tue, Dec 8, 2020 at 1:23 AM Gary Kephart  wrote:

> Juan Pablo,
>
> Thanks for responding. I tried your suggestion but it's still not
> working. Below is my complete jspwiki.policy.
>
> Thanks,
>Gary
>
> grant principal org.apache.wiki.auth.authorize.Role "All" {
>  permission org.apache.wiki.auth.permissions.PagePermission "*:*",
> "view";
>  permission org.apache.wiki.auth.permissions.PagePermission
> "*:LeftMenu/mylogo.png", "view";
>  permission org.apache.wiki.auth.permissions.WikiPermission "*",
> "editPreferences";
>  permission org.apache.wiki.auth.permissions.WikiPermission "*",
> "editProfile";
>  permission org.apache.wiki.auth.permissions.WikiPermission "*",
> "login";
> };
>
>
> // read-only for Anonymous users
> grant principal org.apache.wiki.auth.authorize.Role "Anonymous" {
>  permission org.apache.wiki.auth.permissions.PagePermission "*:*",
> "view";
> };
>
>
> // read-only for Asserted users
> grant principal org.apache.wiki.auth.authorize.Role "Asserted" {
> }permission org.apache.wiki.auth.permissions.PagePermission "*:*",
> "view";
> ;
>
>
> // read-only for Authenticated users
> grant principal org.apache.wiki.auth.authorize.Role "Authenticated" {
>  permission org.apache.wiki.auth.permissions.PagePermission "*:*",
> "view";
> };
>
>
> // Members of the group "RegisteredUsers" can create, edit and rename
> pages.
> // They can also view all the groups.
> grant principal org.apache.wiki.auth.GroupPrincipal "RegisteredUsers" {
>  permission org.apache.wiki.auth.permissions.PagePermission "*:*",
> "modify,rename";
>  permission org.apache.wiki.auth.permissions.GroupPermission "*:*",
> "view";
>  permission org.apache.wiki.auth.permissions.GroupPermission
> "*:", "edit";
>  permission org.apache.wiki.auth.permissions.WikiPermission "*",
> "createPages,createGroups";
> };
>
>
> 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 12/7/2020 6:00 AM, Juan Pablo Santos Rodríguez wrote:
> > Hi Gary,
> >
> > inside JSPWiki, Attachments are consider

Re: JSPWiki: Unable to load and setup properties from jspwiki.properties

[Juan Pablo Santos Rodríguez]

Hi Jim,

you mention initially that the war is deployed as folder.war instead of
ldapwiki.war, is that correct? What files are placed inside
$TOMCAT_HOME/work? Also, would you mind starting tomcat providing it a
"-Dlog4j.rootCategory=DEBUG,ConsoleLog" argument?
That should provide more information on catalina.out


best regards,
juan pablo

On Sun, Dec 6, 2020 at 11:55 AM Jim Willeke  wrote:

> Here is what I see:
>
> less /var/log/tomcat9/catalina.2020-12-06.log
> 06-Dec-2020 10:48:43.248 INFO [main]
> org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of
> deployment descriptor [/etc/tomcat9/Catalina/localhost/host-manager.xml]
> has finished in [416] ms
> 06-Dec-2020 10:48:43.252 INFO [main]
> org.apache.catalina.startup.HostConfig.deployWAR Deploying web application
> archive [/var/lib/tomcat9/webapps/ldapwiki.war]
> 06-Dec-2020 10:48:45.254 INFO [main]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 06-Dec-2020 10:48:46.202 SEVERE [main]
> org.apache.catalina.core.StandardContext.startInternal One or more Filters
> failed to start. Full details will be found in the appropriate container
> log file
> 06-Dec-2020 10:48:46.202 SEVERE [main]
> org.apache.catalina.core.StandardContext.startInternal Context [/ldapwiki]
> startup failed due to previous errors
> 06-Dec-2020 10:48:46.206 WARNING [main]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [ldapwiki] appears to have started a thread named
> [__DEFAULT__] but has failed to stop it. This is very likely to create a
> memory leak. Stack trace of thread:
>  java.base@11.0.9.1/java.lang.Object.wait(Native Method)
>  java.base@11.0.9.1/java.lang.Object.wait(Object.java:328)
>  java.base@11.0.9.1/java.util.TimerThread.mainLoop(Timer.java:527)
>  java.base@11.0.9.1/java.util.TimerThread.run(Timer.java:506)
> 06-Dec-2020 10:48:46.206 WARNING [main]
> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
> web application [ldapwiki] appears to have started a thread named
> [Statistics Thread-__DEFAULT__-1] but has failed to stop it. This is very
> likely to create a memory leak. Stack trace of thread:
>  java.base@11.0.9.1/jdk.internal.misc.Unsafe.park(Native Method)
>
>
> java.base@11.0.9.1/java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:234)
>
>
> java.base@11.0.9.1/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2123)
>
>
> java.base@11.0.9.1/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1182)
>
>
> java.base@11.0.9.1/java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:899)
>
>
> java.base@11.0.9.1/java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1054)
>
>
> java.base@11.0.9.1/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1114)
>
>
> java.base@11.0.9.1/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>  java.base@11.0.9.1/java.lang.Thread.run(Thread.java:834)
> 06-Dec-2020 10:48:46.215 INFO [main]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive [/var/lib/tomcat9/webapps/ldapwiki.war] has finished in
> [2,963] ms
>
>
> --
> -jim
> Jim Willeke
>
>
> On Sat, Dec 5, 2020 at 10:23 AM Harry Metske 
> wrote:
>
> > does catalina.out reveal any more detail?
> >
> > regards,
> > Harry
> >
> > On Fri, 4 Dec 2020 at 13:31, Jim Willeke  wrote:
> >
> > > New install.
> > > Apache Tomcat/9.0.31 (Ubuntu)
> > > 11.0.9.1+1-Ubuntu-0ubuntu1.20.04
> > > JspWiki: 2.11.0.M7 (Binary download)
> > > java --version openjdk 11.0.9.1 2020-11-04
> > > OpenJDK 64-Bit Server VM (build 11.0.9.1+1-Ubuntu-0ubuntu1.20.04, mixed
> > > mode, sharing)
> > >
> > > No Issue accessing
> > > http://:8080/manager/
> > >
> > > CATALINA_BASE="/var/lib/tomcat9"
> > > CATALINA_HOME="/usr/share/tomcat9"
> > >
> > > Copied war file to /var/lib/tomcat9/webapps/
> > > drwxr-x--- 10 tomcat tomcat 4096 Dec  4 10:43 folder/
> > > -rw-r--r--  1 tomcat tomcat 23277026 Dec  4 10:19 folder.war
> > > drwxr-xr-x  3 tomcat tomcat 4096 Dec  4 09:49 ROOT/
> > >
> > > Seems like appropriate files are expanded at:
> > > /var/lib/tomcat9/webapps/folder/ (jsps and WEB-INF/ etc)
> > >
> > > INFO [main] org.apache.catalina.core.ApplicationContext.log ERROR:
> Failed
> > > to create a Wiki engine: JSPWiki: *Unable to load and setup properties
> > from
> > > jspwiki.properties. Failed to start.* Caused by: null; please check log
> > > files for better information.
> > >
> > > find /var/lib/tomcat9/webapps/ldapwiki/ -type f -name "*.properties"
> > >
> 

Re: How to extract PlainText from JSPWiki syntax

[Juan Pablo Santos Rodríguez]

+ Emanuele, thought you were subscribed to user@jspwiki.a.o


best regards,
juan pablo


El lun., 23 nov. 2020 22:41, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> escribió:

> Hi Emanuele,
>
> I'm afraid to say that the WikiEngine is very needed: JSPWiki syntax not
> only covers direct to html syntax (i.e., * translating
> to an html list), but also variable resolution, plugin
> execution,authorization.. There are also filters which, not being present
> in
> the syntax, modify the html presented to the user. All those things need a
> WikiEngine to be parsed. And there's also some
> markup which is directly tied to configuration present on the Engine,
> f.ex., interwiki links, or toggling image inlining.
>
> A WikiEngine acts nowadays mostly as a DI container, so, given that it may
> take a bit to start, it shouldn't affect too much
> to your application, and doesn't force you to declare JSPWiki's servlets /
> filters whatever on your application. In fact, for tests
> we tend to use a TestEngine (an implementation of the WikiEngine suitable
> for tests), so it's not that it will make your application
> unusable.
>
> A couple of things could be done to speed up the Engine initialization.
> Easiest that comes to mind would be to provide mock
> implementations for most of the Engine's managers.
>
> As for the syntax to text conversion, JSPWiki's markup parsers generate a
> WikiDocument, which is a specialization of a JDom2's
> Document. Providing that to the CleanTextRenderer should be enough for
> what you want.
>
> HTH,
> juan pablo
>
> p.s.: out of curiosity, which version of JSPWiki are you working with? Do
> you know in what version Codebeamer forked the wiki,
> or if they keep it up to date with latest JSPWiki?
>
>
>
> On Mon, Nov 23, 2020 at 1:18 PM Emanuele Pecchioli <
> epecchi...@florence-consulting.it> wrote:
>
>> Hello everybody,
>>
>> we have to convert a String containing JSPWiki syntax into Plain Text.
>> We would like to do this conversion without having installed the JSPWiki
>> application.
>> Is there any way to do it? Any available library?
>>
>> We found some very useful classes in *jspwiki-main* jar on maven central
>> (classes JSPWikiMarkupParser and CleanTextRenderer)
>>
>> http://jspwiki.apache.org/apidocs/2.11.0.M6/org/apache/wiki/render/CleanTextRenderer.html
>>
>> https://jspwiki.apache.org/apidocs/2.11.0.M4/org/apache/wiki/parser/JSPWikiMarkupParser.html
>>
>> however they both require a WikiContext that, from what we understood, can
>> be obtained only by a running JSPWiki engine.
>>
>> Just for more information we are doing an integration with *codebeamer
>> *software
>> that we found out is using JSPWiki modules inside to support rich text.
>> Please find below the credit we found on their system:
>> *Credit:* CodeBeamer's Wiki implementation includes many source code
>> modules and ideas from the Open Source JSPWiki <http://www.jspwiki.org/
>> >system.
>> It uses the same Wiki syntax. Many JSPWiki plugins were implemented and
>> ported to CodeBeamer. Thanks to *Janne Jalkanen* and to the JSPWiki
>> community for the contribution.
>>
>> *P.S: if this is not the correct place to ask about this topic, I
>> apologize, but could you please point us in the right direction?*
>>
>> Thanks a lot in advance for your support
>> Best regards
>> Emanuele Pecchioli
>>
>>
>> --
>> --
>> [image: Logo Florence]
>> *Emanuele Pecchioli *
>> Senior Software Developer - Integration Architect
>> Viale Luciano Lama, 23 Centralino: +39055.5383250
>> Interno: +39055.5383277
>> Sede Milano: +3902.87323142
>> Viale Luciano Lama, 23 - 50019 Sesto F.no (FI)
>> Viale Enrico Forlanini, 23 - 20134 Milano
>> https://www.florence-consulting.it/  <https://www.florence-consulting.it/
>> >
>> 
>> epecchi...@florence-consulting.it
>> 
>> --
>> PRIVACY NOTICEThe information contained in this transmittal, including any
>> attachments hereto, are confidential and privileged, and intended solely
>> for the specified addressee(s). This e-mail has a confidential nature
>> which
>> is protected by the Italian law. Moreover, the recipient(s) may not
>> disclose, forward, or copy this e-mail or attachments, or any portion
>> thereof, or permit the use of this information, by anyone not entitled to
>> it, or in a way that may be damaging to the sender. If you are not the
>> intended addressee, or if you receive this message by error, please notify

Re: How to extract PlainText from JSPWiki syntax

[Juan Pablo Santos Rodríguez]

Hi Emanuele,

I'm afraid to say that the WikiEngine is very needed: JSPWiki syntax not
only covers direct to html syntax (i.e., * translating
to an html list), but also variable resolution, plugin
execution,authorization.. There are also filters which, not being present
in
the syntax, modify the html presented to the user. All those things need a
WikiEngine to be parsed. And there's also some
markup which is directly tied to configuration present on the Engine,
f.ex., interwiki links, or toggling image inlining.

A WikiEngine acts nowadays mostly as a DI container, so, given that it may
take a bit to start, it shouldn't affect too much
to your application, and doesn't force you to declare JSPWiki's servlets /
filters whatever on your application. In fact, for tests
we tend to use a TestEngine (an implementation of the WikiEngine suitable
for tests), so it's not that it will make your application
unusable.

A couple of things could be done to speed up the Engine initialization.
Easiest that comes to mind would be to provide mock
implementations for most of the Engine's managers.

As for the syntax to text conversion, JSPWiki's markup parsers generate a
WikiDocument, which is a specialization of a JDom2's
Document. Providing that to the CleanTextRenderer should be enough for what
you want.

HTH,
juan pablo

p.s.: out of curiosity, which version of JSPWiki are you working with? Do
you know in what version Codebeamer forked the wiki,
or if they keep it up to date with latest JSPWiki?



On Mon, Nov 23, 2020 at 1:18 PM Emanuele Pecchioli <
epecchi...@florence-consulting.it> wrote:

> Hello everybody,
>
> we have to convert a String containing JSPWiki syntax into Plain Text.
> We would like to do this conversion without having installed the JSPWiki
> application.
> Is there any way to do it? Any available library?
>
> We found some very useful classes in *jspwiki-main* jar on maven central
> (classes JSPWikiMarkupParser and CleanTextRenderer)
>
> http://jspwiki.apache.org/apidocs/2.11.0.M6/org/apache/wiki/render/CleanTextRenderer.html
>
> https://jspwiki.apache.org/apidocs/2.11.0.M4/org/apache/wiki/parser/JSPWikiMarkupParser.html
>
> however they both require a WikiContext that, from what we understood, can
> be obtained only by a running JSPWiki engine.
>
> Just for more information we are doing an integration with *codebeamer
> *software
> that we found out is using JSPWiki modules inside to support rich text.
> Please find below the credit we found on their system:
> *Credit:* CodeBeamer's Wiki implementation includes many source code
> modules and ideas from the Open Source JSPWiki  >system.
> It uses the same Wiki syntax. Many JSPWiki plugins were implemented and
> ported to CodeBeamer. Thanks to *Janne Jalkanen* and to the JSPWiki
> community for the contribution.
>
> *P.S: if this is not the correct place to ask about this topic, I
> apologize, but could you please point us in the right direction?*
>
> Thanks a lot in advance for your support
> Best regards
> Emanuele Pecchioli
>
>
> --
> --
> [image: Logo Florence]
> *Emanuele Pecchioli *
> Senior Software Developer - Integration Architect
> Viale Luciano Lama, 23 Centralino: +39055.5383250
> Interno: +39055.5383277
> Sede Milano: +3902.87323142
> Viale Luciano Lama, 23 - 50019 Sesto F.no (FI)
> Viale Enrico Forlanini, 23 - 20134 Milano
> https://www.florence-consulting.it/  
> 
> epecchi...@florence-consulting.it
> 
> --
> PRIVACY NOTICEThe information contained in this transmittal, including any
> attachments hereto, are confidential and privileged, and intended solely
> for the specified addressee(s). This e-mail has a confidential nature which
> is protected by the Italian law. Moreover, the recipient(s) may not
> disclose, forward, or copy this e-mail or attachments, or any portion
> thereof, or permit the use of this information, by anyone not entitled to
> it, or in a way that may be damaging to the sender. If you are not the
> intended addressee, or if you receive this message by error, please notify
> the sender and delete this information from your computer. The statements
> and opinions expressed in this e-mail message are those of the author of
> the message and do not necessarily represent those of Florence Consulting
> Group Srl. Besides, The contents of this message shall be understood as
> neither given nor endorsed by Florence Consulting Group Srl. Florence
> Consulting Group Srl does not accept liability for corruption, interception
> or amendment, if any, or the consequences thereof.
>
>
> --
> --
> [image: Logo Florence]
> *Emanuele Pecchioli *
> Senior Software Developer - Integration Architect
> Viale Luciano Lama, 23 Centralino: +39055.5383250
> Interno: +39055.5383277
> Sede Milano: +3902.87323142
> Viale Luciano Lama, 23 - 50019 Sesto F.no (FI)
> Viale Enrico Forlanini, 23 - 20134 

Re: Edit preview interferes with JavaScript

[Juan Pablo Santos Rodríguez]

Forgot to add, regarding maps integration, you can also check haddock
built-in support at https://jspwiki-wiki.apache.org/Wiki.jsp?page=Maps


HTH,
JP

El mar., 23 jun. 2020 19:46, Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> escribió:

> Hi Ulf,
>
> You can also set jspwiki.translatorReader.allowHTML = true on your
> jspwiki.properties but that opens up a security risk on your installation,
> so it may not be a suitable option (e.g. public facing wikis).
>
> Regarding the sameSite cookie attribute, would you mind filling a jira?
>
> (on mobile + broken hand pls excuse brevity + typos)
>
> best regards,
> JP
>
> El mar., 23 jun. 2020 10:13, Ulf Dittmer
>  escribió:
>
>> >
>> > You may want to check an older plugin (
>> > https://www.ecyrd.com/JSPWiki/wiki/JSPluginScripts)
>>
>> who allows you to do this, but not sure if this would still work.
>> >
>>
>> That executes JavaScript on the server using Rhino, but I'm trying to add
>> client-side JavaScript so it can interact with the browser and other
>> JavaScript code, e.g. Google Maps. I had written a plugin for that purpose
>> -which works fine- and was wondering if there were other ways of adding
>> arbitrary JavaScript code to a page.
>>
>

Re: Edit preview interferes with JavaScript

[Juan Pablo Santos Rodríguez]

Hi Ulf,

You can also set jspwiki.translatorReader.allowHTML = true on your
jspwiki.properties but that opens up a security risk on your installation,
so it may not be a suitable option (e.g. public facing wikis).

Regarding the sameSite cookie attribute, would you mind filling a jira?

(on mobile + broken hand pls excuse brevity + typos)

best regards,
JP

El mar., 23 jun. 2020 10:13, Ulf Dittmer 
escribió:

> >
> > You may want to check an older plugin (
> > https://www.ecyrd.com/JSPWiki/wiki/JSPluginScripts)
>
> who allows you to do this, but not sure if this would still work.
> >
>
> That executes JavaScript on the server using Rhino, but I'm trying to add
> client-side JavaScript so it can interact with the browser and other
> JavaScript code, e.g. Google Maps. I had written a plugin for that purpose
> -which works fine- and was wondering if there were other ways of adding
> arbitrary JavaScript code to a page.
>

[ANNOUNCE] Apache JSPWiki 2.11.0.M7 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki
2.11.0.M7.

This is the seventh release towards the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components. M#
releases are as
production-ready as any other JSPWiki release, please see [#1] to know how
this label
is used on Apache JSPWiki releases.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.0.M7

The full change log is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12346642

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/

The Apache JSPWiki Team

[#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=VersioningProposal

Re: call for translators

[Juan Pablo Santos Rodríguez]

forgot to add, the styling on
https://jspwiki.apache.org/development/i18n.html was done using JSPWiki
built-in support for graphbars [#1], which made really easy to have that
nice looking page. Congrats again Dirk
on having so many, so well done surprises inside the default template!


best regards,
juan pablo


[#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=GraphBars

On Sun, Apr 5, 2020 at 1:00 PM Juan Pablo Santos Rodríguez <
juanpablo.san...@gmail.com> wrote:

> Hi all,
>
> the static part of the Apache JSPWiki website now features
> https://jspwiki.apache.org/development/i18n.html,
> which has up-to-date translations' status for each language supported by
> JSPWiki. This page gets updated with
> every push to the master branch.
>
> Almost all of the languages' translations are nearly complete (at 88% of
> the entries transalted or better) so this
> is a call for people speaking those languages. Adding/Improving
> translations is an easy way to contribute to JSPWiki,
> the process is documented at
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=HowToI18n
>
> And of course, improvements on either of those two pages are also welcome!
>
>
> best regards,
> juan pablo
>

Re: Stuck on Authentication

[Juan Pablo Santos Rodríguez]

Hi Alex,

I've to run from my computer, so can't have a look at this right now, but a
couple of guesses:

- as for 1) check that the user running your tomcat instance has write
permissions on /etc/tomcat/jspwiki.. files
- re. 2), I'd first check that your jspwiki-custom file is being readed
(should appear on logs). Seems that you can login b/c
the default login mechanism is still in place. IIRC, it allows anyone to
log in, and the moment you try to save your profile
you come again with the error on 1).. Would you mind checking your
jspwiki.log file? You should have there clear indications
of what's going on and what configuration is being loaded. Would you mind
sharing the logs when you try to save your profile?

Also, I've cc'ed user@jspwiki.apache.org, may be someone else has
experience something similar and can give some advice?

Last,
https://github.com/apache/jspwiki/tree/master/jspwiki-it-tests/jspwiki-it-test-cma
builds a jspwiki war that uses container
managed authentication (and runs some integration tests if you mvn install
-Pintegration-tests, you by default just only need
chrome available on your path).


thx + best regards,
juan pablo

On Sun, Jan 12, 2020 at 1:03 AM Alex Machina  wrote:

> Juan,
>
> Sorry to bother you again, but I wonder if you can give some advice and
> references as to what to read to configure what I want?
>
> 1) My attempt to update my wiki profile results in "Could not save
> profile: /etc/tomcat/jspwiki-users.xml.new: (Permission denied)"
>
> 2) Yet a login to JSPWiki with my Linux UID/PSWD succeeds. Where is
> JSPWiki getting this information, since my jspwiki-custom.properties file
> specifies a place to look for this information (which happens to be
> currently empty)?
>
> The /usr/share/tomcat/lib/jspwiki-custom.properties file:
>
> #Sat Jan 11 01:41:36 EST 2020
> jspwiki.basicAttachmentProvider.storageDir=/opt/JSPWiki
> jspwiki.fileSystemProvider.pageDir=/opt/JSPWiki
> jspwiki.pageProvider=VersioningFileProvider
> jspwiki.applicationName=JSPWiki
> jspwiki.workDir=/opt/work
> # Manually added after initial creation by Install.jsp:
> #http://localhost:8080/JSPWiki/Install.jsp
> jspwiki.pageNameComparator.class=HumanComparator
> jspwiki.translatorReader.camelCaseLinks=true
> jspwiki.xmlGroupDatabaseFile=/etc/tomcat/jspwiki-groups.xml
> jspwiki.xmlUserDatabaseFile=/etc/tomcat/jspwiki-users.xml
> jspwiki.defaultprefs.template.dateformat =dd.MM., HH:mm
> log4j.rootCategory=INFO,FileLog
> log4j.appender.FileLog =org.apache.log4j.RollingFileAppender
> log4j.appender.FileLog.MaxFileSize=4MB
> log4j.appender.FileLog.MaxBackupIndex=4
> log4j.appender.FileLog.File=/var/log/JSPWiki.log
> log4j.appender.FileLog.layout=org.apache.log4j.PatternLayout
> log4j.appender.FileLog.layout.ConversionPattern=%d [%t] %p %c %x - %m%n
>
> Files /etc/tomcat/jspwiki-groups.xml and /etc/tomcat/jspwiki-users.xml are
> currently empty, and file /etc/tomcat/tomcat-users.xml is still in its
> initial state after the install of tomcat (i.e. it has not been modified).
> So the question is, why does my local instance of JSPWiki allow me to login
> at all, and then when I attempt to modify my JSPWiki profile, it attempts
> to create a new file (/etc/tomcat/jspwiki-users.xml.new)?
>
> What I want to do is for JSPWiki to use the contents of
> /etc/tomcat/jspwiki-groups.xml and ./jspwiki-users.xml. Although I am
> not wedded to that outcome, if I continue to use the currently working
> Linux UID/PSWD as my login credentials to JSPWiki, I want to at least
> understand where/how JSPWiki is getting that information.
>
> I don't want to impose on your time, so just a quick pointer to
> documentation and a short answer to get me started would be sufficient.
>
> Thanks,
> Alex
>
> PS - I am currently reading:
>
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=JSPWikiContainerManagedAuthenticationInstallation
>
> and
>
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=Wiki.Admin.Security
>
> in an attempt to wrap my head around this, but a few pointers in the right
> direction would help.
>
>
>

[ANNOUNCE] Apache JSPWiki 2.11.0.M6 released

[Juan Pablo Santos Rodríguez]

The Apache JSPWiki team is pleased to announce the release of JSPWiki
2.11.0.M6.

This is the sixth release towards the 2.11 series of Apache JSPWiki, a
feature-rich and
extensible WikiWiki engine built around the standard JEE components. M#
releases are as
production-ready as any other JSPWiki release, please see [#1] to know how
this label
is used on Apache JSPWiki releases.

The release is available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=Downloads

JSPWiki Maven artifacts are available under org.apache.jspwiki groupId,
version 2.11.0.M6

The full change log is available here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310732=12346489

A curated change log is also available here:
https://jspwiki-wiki.apache.org/Wiki.jsp?page=NewIn2.11

We welcome your help and feedback. For more information on how to
report problems, and to get involved visit the project website at
http://jspwiki.apache.org/

The Apache JSPWiki Team

[#1]: https://jspwiki-wiki.apache.org/Wiki.jsp?page=VersioningProposal

Launch of the 2020 ASF Community Survey

[Juan Pablo Santos Rodríguez]

Hi all,

please see below e-mail, everyone is encouraged to take the survey


thx + best regards,
juan pablo

-- Forwarded message -
From: Sally Khudairi 
Date: Thu, Dec 5, 2019 at 8:42 PM
Subject: [PMCs] Launch of the 2020 ASF Community Survey
To: ASF Marketing & Publicity 


Dear Apache PMC (and PPMC) members,

This week we are launching the 2020 ASF Community Survey. We need your
support spreading the word about this project, so we can get a high
response rate before the survey deadline, on January 4th, 2020.

Please  invite the user and dev mailing lists of your project to take the
survey. We are sharing a templated email below, with a link to the survey.
This email is ready to copy and send:

Hello everyone,

If you have an apache.org email, you should have received an email with an
invitation to take the 2020 ASF Community Survey. Please take 15 minutes to
complete it.

If you do not have an apache.org email address or you didn’t receive a
link, please follow this link to the survey:
https://communitysurvey.limequery.org/454363

This survey is important because it will provide us with scientific
information about our community, and shed some light on how we can
collaborate better and become more diverse. Our last survey of this kind
was implemented in 2016, which means that our existing data about Apache
communities is outdated. The deadline to complete the survey is January
4th, 2020. You can find information about privacy on the survey’s
Confluence page [1].

Your participation is paramount to the success of this project! Please
consider filling out the survey, and share this news with your fellow
Apache contributors. As individuals form the Apache community, your opinion
matters: we want to hear your voice.

If you have any questions about the survey or otherwise, please reach out
to us!

Kindly,
ASF Diversity & Inclusion
https://diversity.apache.org/


[1]
https://cwiki.apache.org/confluence/display/EDI/Launch+Plan+-+The+2020+ASF+Community+Survey

[CVE-2019-12407] Apache JSPWiki Cross-site scripting vulnerability related to the remember parameter

[Juan Pablo Santos Rodríguez]

 Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M4

Description
A carefully crafted plugin link invocation could trigger an XSS
vulnerability on Apache JSPWiki, related to the remember parameter on some
of the JSPs, which could allow the attacker to execute javascript in the
victim's browser and get some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0.M5 or later.

Credit
This issue was discovered by ADLab of VenusTech.

ref: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-12407

Re: [CVE-2019-12407] Apache JSPWiki Cross-site scripting vulnerability related to the remember parameter

[Juan Pablo Santos Rodríguez]

small correction: the appropiate reference url is
https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-12407

On Fri, Sep 20, 2019 at 3:17 PM Juan Pablo Santos Rodríguez <
juanpa...@apache.org> wrote:

> Severity
> Medium
>
> Vendor
> The Apache Software Foundation
>
> Versions Affected
> Apache JSPWiki up to 2.11.0.M4
>
> Description
> A carefully crafted plugin link invocation could trigger an XSS
> vulnerability on Apache JSPWiki, related to the remember parameter on some
> of the JSPs, which could allow the attacker to execute javascript in the
> victim's browser and get some sensitive information about the victim.
>
> Mitigation
> Apache JSPWiki users should upgrade to 2.11.0.M5 or later.
>
> Credit
> This issue was discovered by ADLab of VenusTech.
>
> ref: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-12404
>

[CVE-2019-12404] Apache JSPWiki Cross-site scripting vulnerability on InfoContent.jsp

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M4

Description
A carefully crafted plugin link invocation could trigger an XSS
vulnerability on Apache JSPWiki, related to InfoContent.jsp, which could
allow the attacker to execute javascript in the victim's browser and get
some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0.M5 or later.

Credit
This issue was discovered by ADLab of VenusTech.

rel: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-12404

[CVE-2019-12407] Apache JSPWiki Cross-site scripting vulnerability related to the remember parameter

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M4

Description
A carefully crafted plugin link invocation could trigger an XSS
vulnerability on Apache JSPWiki, related to the remember parameter on some
of the JSPs, which could allow the attacker to execute javascript in the
victim's browser and get some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0.M5 or later.

Credit
This issue was discovered by ADLab of VenusTech.

ref: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-12404

[CVE-2019-10090] Apache JSPWiki Cross-site scripting vulnerability on plain editor

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M4

Description
A carefully crafted plugin link invocation could trigger an XSS
vulnerability on Apache JSPWiki, related to the plain editor, which could
allow the attacker to execute javascript in the victim's browser and get
some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0.M5 or later.

Credit
This issue was discovered by Dirk Frederickx, from Apache JSPWiki.

ref: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-10090

[CVE-2019-10089] Apache JSPWiki Cross-site scripting vulnerability on WYSIWYG editor

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M4

Description
A carefully crafted plugin link invocation could trigger an XSS
vulnerability on Apache JSPWiki, related to the WYSIWYG editor, which could
allow the attacker to execute javascript in the victim's browser and get
some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0.M5 or later.

Credit
This issue was discovered by Jegatheesh A, from ZOHO-CRM Security team.

ref: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-10089

[CVE-2019-10087] Apache JSPWiki Cross-site scripting vulnerability in Page Revision History

[Juan Pablo Santos Rodríguez]

Severity
Medium

Vendor
The Apache Software Foundation

Versions Affected
Apache JSPWiki up to 2.11.0.M4

Description
A carefully crafted plugin link invocation could trigger an XSS
vulnerability on Apache JSPWiki, related to the Page Revision History,
which could allow the attacker to execute javascript in the victim's
browser and get some sensitive information about the victim.

Mitigation
Apache JSPWiki users should upgrade to 2.11.0.M5 or later.

Credit
This issue was discovered by Jegatheesh A, from ZOHO-CRM Security team.

ref: https://jspwiki-wiki.apache.org/Wiki.jsp?page=CVE-2019-10087

Re: Login issues after upgrade - mgr.isContainerAuthenticated() has incorrect value

[Juan Pablo Santos Rodríguez]

Hi Jerry,

just out of curiosity, on what environment do you have deployed JSPWiki? If
possible I'd like to take a look at the integration tests and
see if they can also be reproduced/run on it. Right now they were running
against a vanilla tomcat and the bug wasn't detected.

Also, thanks for your time digging and hunting the issue! :-)


br,
juan pablo

On Fri, Jul 5, 2019 at 3:00 AM Jerry Malcolm  wrote:

> Dirk,
>
> Thank you SO MUCH for your work to get this fixed so quickly. That fixed
> my problem.  I can now successfully log in.  Life is good again with
> JSPWiki and my clients.
>
> Thanks again.
>
> Jerry
>
>
> On 7/4/2019 3:12 PM, Dirk Frederickx wrote:
> > Here is a link to the build artefacts.
> >
> > https://builds.apache.org/job/jspwiki/lastSuccessfulBuild/artifact/
> >
> >
> >
> > On Thu, Jul 4, 2019 at 9:59 PM Jerry Malcolm 
> wrote:
> >
> >> Dirk,
> >>
> >> Does the M5 git fix still require a build?  I can't seem to find a WAR
> >> file in the git tree.
> >>
> >> On 7/4/2019 5:10 AM, Dirk Frederickx wrote:
> >>> Plz try deploying 2.11.0-M5-git-05
> >>>
> >>> On Thu, Jul 4, 2019 at 10:28 AM Dirk Frederickx <
> >> dirk.frederi...@gmail.com>
> >>> wrote:
> >>>
>  Jerry, Ulf,
> 
>  I can try to push a quick fix on WebContainerAuthorizer to github.
>  But I'm not able to fully test ;  so appreciate if you can validate
> >> this.
>  We also need to change the automated tests,  cause those web.xml are
> >> also
>  pointing to the wrong namespace.
>  This can be done later.
> 
> 
>  dirk
> 
>  On Thu, Jul 4, 2019 at 5:49 AM Jerry Malcolm 
>  wrote:
> 
> > Update... I tried changing web.xml namespace back to sun.  I found
> that
> > version 2.10.0 had the sun site in web.xml.  I copied the web-app tag
> > and all of its attributes from 2.10.0 to the web.xml for my
> 2.11.0-M4.
> > No change.  Stills says it's using custom auth.  So I'm assuming the
> >> fix
> > has to be in the WebContainerAuthorizer.java class and requires a
> > rebuild, correct?  Anybody already set up to make that change, do a
> new
> > build, and post a fixed jar file? (I assume turning new fix releases
> is
> > not quick)  I'm not thrilled about having to set up a build
> > environment.  But if that's the only option :-(
> >
> > On 7/3/2019 9:45 PM, Jerry Malcolm wrote:
> >> Hey, Dirk,
> >>
> >> Thanks so much for the info.  You are correct that
> >> WebContainerAuthorizer points to java.sun.com and the web.xml
> points
> >> to the javaee.  What change do I make?  Should I change the web.xml
> to
> >> point to the sun site?  I can't really change the
> >> WebContainerAuthorizer code without doing a full rebuild.  I don't
> >> have a build environment set up.
> >>
> >> Jerry
> >>
> >> On 7/3/2019 4:18 PM, Dirk Frederickx wrote:
> >>> Jerry,  Ulf,
> >>>
> >>>
> >>> Probably the namespace used by
> >>> org.apache.wiki.auth.authorizer.WebContainerAuthorizer.java
> >>> is incorrect, as it still points to java.sun.com :
> >>>
> >>>private static final String J2EE_SCHEMA_25_NAMESPACE = "
> >>> http://java.sun.com/xml/ns/javaee;;
> >>>
> >>>
> >>> The web.xml points to
> >>>
> >>> http://xmlns.jcp.org/xml/ns/javaee
> >>>
> >>>
> >>> Could you check if that would help to fix this issue?
> >>> Not sure why this has not been catched by the tests.
> >>>
> >>>
> >>> Best regards,
> >>> dirk
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Jul 3, 2019 at 10:28 PM Jerry Malcolm <
> >> techst...@malcolms.com>
> >>> wrote:
> >>>
>  Thanks, Ulf.  At least I know it's not just me.  Are any
> developers
> >> of
>  JSPWiki monitoring this forum?
> 
>  I debugged this down to the isConstrained(...) method in
>  org.apache.wiki.auth.authorizer.WebContainerAuthorizer.java. I'm
> not
>  sure of the reason for adding the "j:" tag qualifier prefix.
> Comment
>  says it is required for J2EE 2.3.  But it's searching for
>   and other "j:" tags in web.xml, which aren't
> > there.
>  And the search is failing.  So basically it is not finding
> >> /Login.jsp
>  and /Delete.jsp constraints even though they are present and in
> the
>  correct location (and uncommented).  I tried adding the "j:"
>  prefixes to
>  my web.xml.  But the webapp wouldn't even start with prefixes
> >> manually
>  added.   So the problem is straightforward.  It may have nothing
> to
> >> do
>  with the "j:" prefix.  But that line that search for the
> constraint
> > tag
>  is still failing.  I ultimately get the log entry that says
> "JSPWiki
> > is
>  using custom authentication." from the WebContainerAuthorizer
> class
>  even
>  though web.xml is