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)
[email protected]
> On Aug 17, 2023, at 16:04, Juan Pablo Santos Rodríguez
> <[email protected]> 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 <[email protected]> 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)
>> [email protected]
>>
>>
>>
>>
>>
>>> On Aug 17, 2023, at 14:33, Juan Pablo Santos Rodríguez <
>> [email protected]> 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 <[email protected]> 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)
>>>> [email protected]
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Aug 17, 2023, at 12:40, Jim Wise <[email protected]> wrote:
>>>>>
>>>>> Interestingly, the edit page itself also obeys user preferences. It is
>>>> only Wiki content that is not getting it.
>>>>>
>>>>> --
>>>>> Jim Wise (he/him)
>>>>> [email protected]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Aug 17, 2023, at 12:37, Jim Wise <[email protected]> wrote:
>>>>>>
>>>>>> For completeness, I have also tried with ProxyPass/ProxyPassReverse
>>>> using HTTP instead of AJP, with no change.
>>>>>>
>>>>>> --
>>>>>> Jim Wise (he/him)
>>>>>> [email protected]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Aug 17, 2023, at 11:55, Jim Wise <[email protected]> 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-yyyy 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)
>>>>>>> [email protected]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Aug 17, 2023, at 06:06, Juan Pablo Santos Rodríguez <
>>>> [email protected]> 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 <[email protected]>
>>>> 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 <[email protected]> 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)
>>>>>>>>>> [email protected]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Aug 15, 2023, at 18:21, Jim Wise <[email protected]> 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)
>>>>>>>>>>> [email protected]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 15, 2023, at 16:14, Juan Pablo Santos Rodríguez <
>>>>>>>>>> [email protected]> 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 <[email protected]>
>> 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)
>>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
