Re: Section Editing broken
Will need a little more time to test direct access, but will definitely do so. For comparison, is anyone using the ShortViewURLConstructor and seeing user preferences work for pages under its prefix? Thanks, -- Jim Wise (he/him) jw...@draga.com > On Aug 17, 2023, at 16:04, Juan Pablo Santos Rodríguez > wrote: > > Hi! > > Is it possible that the Apache config, as it is, works for the default url > constructor, but it's not enough for the short url constructor? > > Or the same question, from other point of view: if you access to your > JSPWiki instance directly through your tomcat installation instead of > through the Apache server, does the problem persist if you use the short > url constructor? > > > Thx + best regards, > juan pablo > > El jue, 17 ago 2023, 21:25, Jim Wise escribió: > >> Found the problem, sort of. >> >> We’ve been using jspwiki.urlConstructor = ShortViewURLConstructor, with a >> prefix of /wiki. If I switch to DefaultURLConstructor, everything works >> fine — and I no longer have separate “/“ and “/wiki” versions of the >> JSPWikiUserPrefs cookie. >> >> This may still well be apache related, but at least this narrows the >> search space. >> >> -- >>Jim Wise (he/him) >>jw...@draga.com >> >> >> >> >> >>> On Aug 17, 2023, at 14:33, Juan Pablo Santos Rodríguez < >> juanpablo.san...@gmail.com> wrote: >>> >>> 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 ho
Re: Section Editing broken
Found the problem, sort of.
We’ve been using jspwiki.urlConstructor = ShortViewURLConstructor, with a
prefix of /wiki. If I switch to DefaultURLConstructor, everything works fine —
and I no longer have separate “/“ and “/wiki” versions of the JSPWikiUserPrefs
cookie.
This may still well be apache related, but at least this narrows the search
space.
--
Jim Wise (he/him)
jw...@draga.com
> On Aug 17, 2023, at 14:33, Juan Pablo Santos Rodríguez
> wrote:
>
> 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.
&
Re: Section Editing broken
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
>>>> 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 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
Re: Section Editing broken
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
>>> 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 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
>>>>>
>>>>>
>
Re: Section Editing broken
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
>> 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 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.
>>>>>
>>>&g
Re: Section Editing broken
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
> 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 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
Re: Section Editing broken
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 >> 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
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 > 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 >> >> >> >> >> >>
Section Editing broken
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: CSRF protection causing errors in previews
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 > 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 mailto: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: logger changes for 2.11.0
Excellent — thank you!
--
Jim Wise
jw...@draga.com
> On Dec 31, 2021, at 13:05, Juan Pablo Santos Rodríguez
> wrote:
>
> 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
>>>>> ap
Re: logger changes for 2.11.0
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
> 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
