[jira] [Resolved] (JSPWIKI-1138) Install.jsp UI overhaul
[
https://issues.apache.org/jira/browse/JSPWIKI-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Pablo Santos Rodríguez resolved JSPWIKI-1138.
--
Resolution: Duplicate
fixed on 2.12.0 (Install.jsp now properly displays its styles) + JSPWIKI-1186
> Install.jsp UI overhaul
> ---
>
> Key: JSPWIKI-1138
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1138
> Project: JSPWiki
> Issue Type: Task
> Components: Core storage
>Affects Versions: 2.11.0-M8
> Environment: Windows new version
> Firefox version 84.0.1
>
>Reporter: Nguyen Dang Khai
>Priority: Major
> Labels: pull-request-available
> Attachments: xsswiki.PNG
>
>
> In function *install.jsp* exist multi xss in parameter
> *jspwiki.applicationName, jspwiki.fileSystemProvider.pageDir ,
> jspwiki.workDir*. parameter not sanitize via method *getContentEncoding*().
> * Request :
> {code:java}
> // POST /wiki_jsp_war/Install.jsp HTTP/1.1
> Host: localhost:8080
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101
> Firefox/84.0
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 248
> Origin: http://localhost:8080
> Connection: close
> Referer: http://localhost:8080/wiki_jsp_war/Install.jsp
> Cookie: JSESSIONID=079AB09DC4350BB216A468B15DC9F8BA;
> XDEBUG_SESSION=XDEBUG_ECLIPSE
> Upgrade-Insecure-Requests:
> 1jspwiki.applicationName=%27%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E=%27%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E=F%3A%5C%5CExtension%5C%5Capache-tomcat-8.5.60%5C%5Ctemp=Configure%21
> {code}
> * Response:
> {code:java}
> // HTTP/1.1 200
> Pragma: no-cache
> Expires: -1
> Cache-Control: no-cache
> Content-Type: text/html;charset=UTF-8
> Content-Language: en-US
> Date: Wed, 23 Dec 2020 10:33:46 GMT
> Connection: close
> Content-Length: 4403
> ...
>
>
> BasicsApplication Name class="form-control" type="text" name="jspwiki.applicationName" size="20"
> value="'">alert(1)"/>
>
>
> What should your wiki be called? Try to use a relative short
> name.Page storage class="form-control" type="text" name="jspwiki.fileSystemProvider.pageDir"
> size="40" value="'">alert(1)"/>
>
>
> By default, JSPWiki will use the VersioningFileProvider that stores
> files in a directory. If you specify a directory that does not exist, JSPWiki
> will try to create it for you. All attachments will also be put in the same
> directory.
> SecurityAdministrator
> account
> Enabled
>
> This wiki has an administrator account named admin
> that is part of the wiki group Admin. By default, JSPWiki's
> security policy grants all members of the Admin group the all-powerful
> AllPermission.
> Advanced SettingsWork
> directory size="40" value="F:Extensionapache-tomcat-8.5.60temp"/>
>
>
> This is the place where all caches and other runtime stuff is
> stored.
>
> After you click Configure!, the installer will write your
> settings to
> F:\Extension\apache-tomcat-8.5.60\temp\jspwiki-custom.properties.
> It will also create an Administrator account with a random password and a
> corresponding Admin group.
> value="Configure!" />
> Here is your new jspwiki-custom.properties
>jspwiki.applicationName = '">alert(1)
> jspwiki.fileSystemProvider.pageDir = '">alert(1)
> jspwiki.workDir = F:Extensionapache-tomcat-8.5.60temp
> jspwiki.basicAttachmentProvider.storageDir = '">alert(1)
> jspwiki.pageProvider = VersioningFileProvider
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1186) Windows, install.jsp double escapes the jspwiki.workDir and nothing else
[ https://issues.apache.org/jira/browse/JSPWIKI-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Pablo Santos Rodríguez resolved JSPWIKI-1186. -- Fix Version/s: 2.12.2 Resolution: Fixed fixed in 2.12.2-git-15; also a sensible default for page and attachments dir is presented, instead of asking to fill in the field Note that the dir properties end up having 4 backslashes, which is translated to 2 backslashes when readed by JSPWiki, which is translated to a single backslash when the property ends up being used. Also the install screen presents the properties as entered by the user, instead of the escaped version of the values. > Windows, install.jsp double escapes the jspwiki.workDir and nothing else > > > Key: JSPWIKI-1186 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1186 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Minor > Fix For: 2.12.2 > > > minor issue, but after running through install.jsp (running on latest on > master from github mirror), it produces a properties like this > > jspwiki.applicationName = Test wiki > jspwiki.fileSystemProvider.pageDir = > G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage > jspwiki.workDir = > G:jspwiki-testapache-tomcat-9.0.86workCatalinalocalhostJSPWiki > jspwiki.basicAttachmentProvider.storageDir = > G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage > jspwiki.pageProvider = VersioningFileProvider > > i think it's because install.jsp double escapes the work dir when it's > rendered in browser, then it gets escaped again when rendering again for the > properties file > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1186) Windows, install.jsp double escapes the jspwiki.workDir and nothing else
[ https://issues.apache.org/jira/browse/JSPWIKI-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849397#comment-17849397 ] ASF subversion and git services commented on JSPWIKI-1186: -- Commit 480e900b86e3b153420016988e3667cff23622b8 in jspwiki's branch refs/heads/master from Juan Pablo Santos Rodríguez [ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=480e900b8 ] JSPWIKI-1186: Windows, install.jsp double escapes the jspwiki.workDir and nothing else > Windows, install.jsp double escapes the jspwiki.workDir and nothing else > > > Key: JSPWIKI-1186 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1186 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Minor > > minor issue, but after running through install.jsp (running on latest on > master from github mirror), it produces a properties like this > > jspwiki.applicationName = Test wiki > jspwiki.fileSystemProvider.pageDir = > G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage > jspwiki.workDir = > G:jspwiki-testapache-tomcat-9.0.86workCatalinalocalhostJSPWiki > jspwiki.basicAttachmentProvider.storageDir = > G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage > jspwiki.pageProvider = VersioningFileProvider > > i think it's because install.jsp double escapes the work dir when it's > rendered in browser, then it gets escaped again when rendering again for the > properties file > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1186) Windows, install.jsp double escapes the jspwiki.workDir and nothing else
[ https://issues.apache.org/jira/browse/JSPWIKI-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849398#comment-17849398 ] ASF subversion and git services commented on JSPWIKI-1186: -- Commit 480e900b86e3b153420016988e3667cff23622b8 in jspwiki's branch refs/heads/dependabot/maven/tomcat.version-10.1.24 from Juan Pablo Santos Rodríguez [ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=480e900b8 ] JSPWIKI-1186: Windows, install.jsp double escapes the jspwiki.workDir and nothing else > Windows, install.jsp double escapes the jspwiki.workDir and nothing else > > > Key: JSPWIKI-1186 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1186 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Minor > > minor issue, but after running through install.jsp (running on latest on > master from github mirror), it produces a properties like this > > jspwiki.applicationName = Test wiki > jspwiki.fileSystemProvider.pageDir = > G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage > jspwiki.workDir = > G:jspwiki-testapache-tomcat-9.0.86workCatalinalocalhostJSPWiki > jspwiki.basicAttachmentProvider.storageDir = > G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage > jspwiki.pageProvider = VersioningFileProvider > > i think it's because install.jsp double escapes the work dir when it's > rendered in browser, then it gets escaped again when rendering again for the > properties file > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1191) Wysiwyg editor, pasting in an image produces a data url, but renders an error
[ https://issues.apache.org/jira/browse/JSPWIKI-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842809#comment-17842809 ] Alex O'Ree commented on JSPWIKI-1191: - not currently using markdown, but i'll check the other classes you mentioned. what's the preference for pasted in images? store in the text content of the wiki or auto magically upload them and attach them via the img wiki syntax? > Wysiwyg editor, pasting in an image produces a data url, but renders an error > - > > Key: JSPWIKI-1191 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1191 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-37-49-281.png > > > I'm in search of an easy way for users to put images into wiki content > besides the attachments upload option, then manually linking them. So i tried > to just paste in some content to the wysiwyg editor. which worked in the > editor, however after viewing the page, i got this. note: this happens with > markdown syntax or with the default syntax > > No InterWiki reference defined in properties for Wiki called "data"! > !image-2024-03-31-12-37-49-281.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1191) Wysiwyg editor, pasting in an image produces a data url, but renders an error
[
https://issues.apache.org/jira/browse/JSPWIKI-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842673#comment-17842673
]
Juan Pablo Santos Rodríguez commented on JSPWIKI-1191:
--
Hi Alex!
There's a public api, documented at
https://jspwiki-wiki.apache.org/Wiki.jsp?page=JSPWikiPublicAPI that you can use
to grab {{Engine}} and/or {{Context}}. However, in the case of
{{ImageDecorator}}, {{Engine}} and {{Context}} aren't accesible as it is now.
If there's a need of uploading a file, rather than uploading it as part of the
markup parsing, I'd look for a way in the editor to upload the image first, and
translate to wiki code afterwards.
As for the base64 string, I'm not comlpetely sure without looking into it more
thoroughly (will try to do that soon), but perhaps the mangling is probably
taking place at {{WysiwygEditingRenderer#getString}}? Also, not sure, but from
other issues, are you using the markdown syntax when experiencing this? If yes,
then probably the problem is laying in the equivalent of these classes on the
jspwiki-markdown module.
cheers,
> Wysiwyg editor, pasting in an image produces a data url, but renders an error
> -
>
> Key: JSPWIKI-1191
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1191
> Project: JSPWiki
> Issue Type: Bug
>Reporter: Alex O'Ree
>Priority: Major
> Attachments: image-2024-03-31-12-37-49-281.png
>
>
> I'm in search of an easy way for users to put images into wiki content
> besides the attachments upload option, then manually linking them. So i tried
> to just paste in some content to the wysiwyg editor. which worked in the
> editor, however after viewing the page, i got this. note: this happens with
> markdown syntax or with the default syntax
>
> No InterWiki reference defined in properties for Wiki called "data"!
> !image-2024-03-31-12-37-49-281.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[
https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Pablo Santos Rodríguez resolved JSPWIKI-1190.
--
Fix Version/s: 2.12.2
Resolution: Fixed
Hi Alex!
rather than extracting the unit test as a separate standalone utility, I've
modified it to generate the markdown-flavoured wikipages, and modified the
build so they're now proper artifacts that can be downloaded, instead of making
everyone jumping through the {{WikiSyntaxconverter}} hops. Hopefully this makes
setting up markdown easier for everyone.
The {{WikiSyntaxconverter}} can still be used as an starting point if more
complex conversion scenarios are needed.
> Changing jspwiki.syntax=markdown breaks all the predefined/default wiki
> content
> ---
>
> Key: JSPWIKI-1190
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1190
> Project: JSPWiki
> Issue Type: Bug
>Reporter: Alex O'Ree
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.12.2
>
> Attachments: image-2024-03-31-12-32-13-401.png
>
>
> here's what i'm seeing on the left menu
> !image-2024-03-31-12-32-13-401.png!
>
> i'm not sure how to tackle this, but maybe the fix for this is to have each
> page have a syntax setting. that would enable the existing content to not
> break but still offer additional options for editors
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842658#comment-17842658 ] ASF subversion and git services commented on JSPWIKI-1190: -- Commit f79d41cb5b60942a365000a2a435e1c8f40ae178 in jspwiki's branch refs/heads/master from Juan Pablo Santos Rodríguez [ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=f79d41cb5 ] JSPWIKI-1190: generate markdown flavour of wikipages as part of the build > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Labels: pull-request-available > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1191) Wysiwyg editor, pasting in an image produces a data url, but renders an error
[ https://issues.apache.org/jira/browse/JSPWIKI-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841689#comment-17841689 ] Alex O'Ree commented on JSPWIKI-1191: - progress, i figured out how it's being rendered. JSPWikiMarkupParser#createAnchor i put some hacks in there to render the image as a link, however it appears as if something is putting either spaces or line breaks into the content post save. i can hack a solution for this but i'd like to know the why. maybe it's something we can prevent > Wysiwyg editor, pasting in an image produces a data url, but renders an error > - > > Key: JSPWIKI-1191 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1191 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-37-49-281.png > > > I'm in search of an easy way for users to put images into wiki content > besides the attachments upload option, then manually linking them. So i tried > to just paste in some content to the wysiwyg editor. which worked in the > editor, however after viewing the page, i got this. note: this happens with > markdown syntax or with the default syntax > > No InterWiki reference defined in properties for Wiki called "data"! > !image-2024-03-31-12-37-49-281.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1191) Wysiwyg editor, pasting in an image produces a data url, but renders an error
[ https://issues.apache.org/jira/browse/JSPWIKI-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841517#comment-17841517 ] Alex O'Ree commented on JSPWIKI-1191: - is there an API somewhere where i can get to the Engine or Context object via a static accessor or singleton pattern? looking at where the problem is, it'll require (i think) a number of api changes to either get engine or context access over to the ImageDecorator class. actually, is this even the right pattern? not too sure how to store/attach a file to a wiki page yet > Wysiwyg editor, pasting in an image produces a data url, but renders an error > - > > Key: JSPWIKI-1191 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1191 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-37-49-281.png > > > I'm in search of an easy way for users to put images into wiki content > besides the attachments upload option, then manually linking them. So i tried > to just paste in some content to the wysiwyg editor. which worked in the > editor, however after viewing the page, i got this. note: this happens with > markdown syntax or with the default syntax > > No InterWiki reference defined in properties for Wiki called "data"! > !image-2024-03-31-12-37-49-281.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1191) Wysiwyg editor, pasting in an image produces a data url, but renders an error
[ https://issues.apache.org/jira/browse/JSPWIKI-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841502#comment-17841502 ] Alex O'Ree commented on JSPWIKI-1191: - some research on this. the ImageDecorator class in the WYSIWYG library translates the pasted image (as a data url) to the wiki. That's probably the culprit here. I think the logic needs to be changed to... if it's a data url, detach the image into the wiki storage, then spit out the correct syntax for the link to the newly saved image. > Wysiwyg editor, pasting in an image produces a data url, but renders an error > - > > Key: JSPWIKI-1191 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1191 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-37-49-281.png > > > I'm in search of an easy way for users to put images into wiki content > besides the attachments upload option, then manually linking them. So i tried > to just paste in some content to the wysiwyg editor. which worked in the > editor, however after viewing the page, i got this. note: this happens with > markdown syntax or with the default syntax > > No InterWiki reference defined in properties for Wiki called "data"! > !image-2024-03-31-12-37-49-281.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated JSPWIKI-1190: Labels: pull-request-available (was: ) > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Labels: pull-request-available > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1188) Support system property replacement for jsp wiki configuration properties
[
https://issues.apache.org/jira/browse/JSPWIKI-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Pablo Santos Rodríguez resolved JSPWIKI-1188.
--
Fix Version/s: 2.12.2
Resolution: Fixed
Merged in 2.12.2-git-13, thanks for the PR!
> Support system property replacement for jsp wiki configuration properties
> -
>
> Key: JSPWIKI-1188
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1188
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core storage
>Reporter: Alex O'Ree
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> As a sysadmin/integrator/user of jspwiki, i would really like to automate as
> much as integration work as possible for my use case. This includes
> * generating markdown and attachments to "seed" or initialize the content
> for jsp wiki
> * task automating the deployment of jspwiki's war into tomcat
> * configuring jsp wiki via the properties file
> i also need to be able to run on multiple systems, platforms and containers.
> So that said, jspwiki's properties file has a few settings that require paths
> for storing content, such as
> * jspwiki.fileSystemProvider.pageDir
> * jspwiki.workDir
> * jspwiki.basicAttachmentProvider.storageDir
> When running in tomcat from the command line, the bin path is typically the
> current working directory, meaning relative paths are based on that path.
> However when ran as a windows or systemd service, sometimes the current
> working directory is not bin, it's up folder up. Anyhow, relative paths are a
> poor solution in this case.
> In my experience, since i know i'm running on tomcat, i almost always use the
> system property `catalina.base` for locating paths relative to tomcat for
> extra storage locations for stuff.
> Long story short, most systems support property substitution (maven uses
> velocity for example) and i'd like jspwiki to do the same.
> Example file (as stored)
> * jspwiki.fileSystemProvider.pageDir=${catalina.base}/wiki
> * jspwiki.workDir=${catalina.base}/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=${catalina.base}/wiki
> which would be resolved to something like
> * jspwiki.fileSystemProvider.pageDir=c:/tomcat/wiki
> * jspwiki.workDir=c:/tomcat/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=c:/tomcat/wiki
> where catalina.base = c:/tomcat. This would effectively enable relative paths
> with some safe guards.
>
> Now as far as implementation, i can think of a few options
> * a DIY, 0 dependency approach to location a ${ and a } in a property value
> to do the substitution
> * maybe use velocity to resolve it, assuming you want to add velocity to the
> dependency list for this project
> * maybe apache commons config might be a better option as they already merge
> system environment variables and system properties. but i'm not clear if it
> does property substitution out of the box
> i'm will to support either way
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1188) Support system property replacement for jsp wiki configuration properties
[
https://issues.apache.org/jira/browse/JSPWIKI-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841479#comment-17841479
]
ASF subversion and git services commented on JSPWIKI-1188:
--
Commit 2b06d7a780f5a0baedd93eda495fdf214d336be1 in jspwiki's branch
refs/heads/master from Alex O'Ree
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=2b06d7a78 ]
JSPWIKI-1188 rearranges the config loading to support the property replacement
> Support system property replacement for jsp wiki configuration properties
> -
>
> Key: JSPWIKI-1188
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1188
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core storage
>Reporter: Alex O'Ree
>Priority: Major
> Labels: pull-request-available
>
> As a sysadmin/integrator/user of jspwiki, i would really like to automate as
> much as integration work as possible for my use case. This includes
> * generating markdown and attachments to "seed" or initialize the content
> for jsp wiki
> * task automating the deployment of jspwiki's war into tomcat
> * configuring jsp wiki via the properties file
> i also need to be able to run on multiple systems, platforms and containers.
> So that said, jspwiki's properties file has a few settings that require paths
> for storing content, such as
> * jspwiki.fileSystemProvider.pageDir
> * jspwiki.workDir
> * jspwiki.basicAttachmentProvider.storageDir
> When running in tomcat from the command line, the bin path is typically the
> current working directory, meaning relative paths are based on that path.
> However when ran as a windows or systemd service, sometimes the current
> working directory is not bin, it's up folder up. Anyhow, relative paths are a
> poor solution in this case.
> In my experience, since i know i'm running on tomcat, i almost always use the
> system property `catalina.base` for locating paths relative to tomcat for
> extra storage locations for stuff.
> Long story short, most systems support property substitution (maven uses
> velocity for example) and i'd like jspwiki to do the same.
> Example file (as stored)
> * jspwiki.fileSystemProvider.pageDir=${catalina.base}/wiki
> * jspwiki.workDir=${catalina.base}/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=${catalina.base}/wiki
> which would be resolved to something like
> * jspwiki.fileSystemProvider.pageDir=c:/tomcat/wiki
> * jspwiki.workDir=c:/tomcat/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=c:/tomcat/wiki
> where catalina.base = c:/tomcat. This would effectively enable relative paths
> with some safe guards.
>
> Now as far as implementation, i can think of a few options
> * a DIY, 0 dependency approach to location a ${ and a } in a property value
> to do the substitution
> * maybe use velocity to resolve it, assuming you want to add velocity to the
> dependency list for this project
> * maybe apache commons config might be a better option as they already merge
> system environment variables and system properties. but i'm not clear if it
> does property substitution out of the box
> i'm will to support either way
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1188) Support system property replacement for jsp wiki configuration properties
[
https://issues.apache.org/jira/browse/JSPWIKI-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841477#comment-17841477
]
ASF subversion and git services commented on JSPWIKI-1188:
--
Commit b553be9b9882a529133c414cc9386b32f62743a2 in jspwiki's branch
refs/heads/master from Alex O'Ree
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=b553be9b9 ]
JSPWIKI-1188 system property expansion
> Support system property replacement for jsp wiki configuration properties
> -
>
> Key: JSPWIKI-1188
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1188
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core storage
>Reporter: Alex O'Ree
>Priority: Major
> Labels: pull-request-available
>
> As a sysadmin/integrator/user of jspwiki, i would really like to automate as
> much as integration work as possible for my use case. This includes
> * generating markdown and attachments to "seed" or initialize the content
> for jsp wiki
> * task automating the deployment of jspwiki's war into tomcat
> * configuring jsp wiki via the properties file
> i also need to be able to run on multiple systems, platforms and containers.
> So that said, jspwiki's properties file has a few settings that require paths
> for storing content, such as
> * jspwiki.fileSystemProvider.pageDir
> * jspwiki.workDir
> * jspwiki.basicAttachmentProvider.storageDir
> When running in tomcat from the command line, the bin path is typically the
> current working directory, meaning relative paths are based on that path.
> However when ran as a windows or systemd service, sometimes the current
> working directory is not bin, it's up folder up. Anyhow, relative paths are a
> poor solution in this case.
> In my experience, since i know i'm running on tomcat, i almost always use the
> system property `catalina.base` for locating paths relative to tomcat for
> extra storage locations for stuff.
> Long story short, most systems support property substitution (maven uses
> velocity for example) and i'd like jspwiki to do the same.
> Example file (as stored)
> * jspwiki.fileSystemProvider.pageDir=${catalina.base}/wiki
> * jspwiki.workDir=${catalina.base}/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=${catalina.base}/wiki
> which would be resolved to something like
> * jspwiki.fileSystemProvider.pageDir=c:/tomcat/wiki
> * jspwiki.workDir=c:/tomcat/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=c:/tomcat/wiki
> where catalina.base = c:/tomcat. This would effectively enable relative paths
> with some safe guards.
>
> Now as far as implementation, i can think of a few options
> * a DIY, 0 dependency approach to location a ${ and a } in a property value
> to do the substitution
> * maybe use velocity to resolve it, assuming you want to add velocity to the
> dependency list for this project
> * maybe apache commons config might be a better option as they already merge
> system environment variables and system properties. but i'm not clear if it
> does property substitution out of the box
> i'm will to support either way
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1188) Support system property replacement for jsp wiki configuration properties
[
https://issues.apache.org/jira/browse/JSPWIKI-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841478#comment-17841478
]
ASF subversion and git services commented on JSPWIKI-1188:
--
Commit b10f148f1718ae19dd2ee7111d7a0020ad1b9795 in jspwiki's branch
refs/heads/master from Alex O'Ree
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=b10f148f1 ]
JSPWIKI-1188 additional test coverage
> Support system property replacement for jsp wiki configuration properties
> -
>
> Key: JSPWIKI-1188
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1188
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core storage
>Reporter: Alex O'Ree
>Priority: Major
> Labels: pull-request-available
>
> As a sysadmin/integrator/user of jspwiki, i would really like to automate as
> much as integration work as possible for my use case. This includes
> * generating markdown and attachments to "seed" or initialize the content
> for jsp wiki
> * task automating the deployment of jspwiki's war into tomcat
> * configuring jsp wiki via the properties file
> i also need to be able to run on multiple systems, platforms and containers.
> So that said, jspwiki's properties file has a few settings that require paths
> for storing content, such as
> * jspwiki.fileSystemProvider.pageDir
> * jspwiki.workDir
> * jspwiki.basicAttachmentProvider.storageDir
> When running in tomcat from the command line, the bin path is typically the
> current working directory, meaning relative paths are based on that path.
> However when ran as a windows or systemd service, sometimes the current
> working directory is not bin, it's up folder up. Anyhow, relative paths are a
> poor solution in this case.
> In my experience, since i know i'm running on tomcat, i almost always use the
> system property `catalina.base` for locating paths relative to tomcat for
> extra storage locations for stuff.
> Long story short, most systems support property substitution (maven uses
> velocity for example) and i'd like jspwiki to do the same.
> Example file (as stored)
> * jspwiki.fileSystemProvider.pageDir=${catalina.base}/wiki
> * jspwiki.workDir=${catalina.base}/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=${catalina.base}/wiki
> which would be resolved to something like
> * jspwiki.fileSystemProvider.pageDir=c:/tomcat/wiki
> * jspwiki.workDir=c:/tomcat/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=c:/tomcat/wiki
> where catalina.base = c:/tomcat. This would effectively enable relative paths
> with some safe guards.
>
> Now as far as implementation, i can think of a few options
> * a DIY, 0 dependency approach to location a ${ and a } in a property value
> to do the substitution
> * maybe use velocity to resolve it, assuming you want to add velocity to the
> dependency list for this project
> * maybe apache commons config might be a better option as they already merge
> system environment variables and system properties. but i'm not clear if it
> does property substitution out of the box
> i'm will to support either way
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841471#comment-17841471 ] Alex O'Ree commented on JSPWIKI-1190: - ok i'll see if i can move it around into a utility jar while still maintaining the current unit test setup > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834528#comment-17834528 ] Juan Pablo Santos Rodríguez commented on JSPWIKI-1190: -- Hi Alex, Yup, it's a unit test, but that's only for convenience, it was easier to work for me within my IDE having it as a unit test... it could also easily be a main class as well. The idea is to run the converter to get an initial set of markdown wikipages, place them somewhere and point there on your jspwiki-custom.properties file. I've noted this at [https://jspwiki-wiki.apache.org/Wiki.jsp?page=Markdown%20Support] so hopefully it's clearer now. BTW, That converter could also be used to transform any given set of wiki pages, not only the initial set ones. You'll lose your pages' history, but that could also be worked out on the converter. HTH, > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832621#comment-17832621 ] Alex O'Ree commented on JSPWIKI-1190: - I'm still confused. WikiSyntaxConverter appears to be a unit test in src/test/java. Is there some way to run this within jspwiki? I'm not sure what steps are required to convert everything to markdown, if that's even an option. > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832618#comment-17832618 ] Juan Pablo Santos Rodríguez commented on JSPWIKI-1190: -- Yes, the test is mentioned last bullet on Features section, but re-reading it, it isn't straightforward that you've to run on the default set of wikipages... > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832613#comment-17832613 ] Alex O'Ree commented on JSPWIKI-1190: - Is this the instructions you are referring to? [https://jspwiki-wiki.apache.org/Wiki.jsp?page=Markdown%20Support] > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
[ https://issues.apache.org/jira/browse/JSPWIKI-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832612#comment-17832612 ] Juan Pablo Santos Rodríguez commented on JSPWIKI-1190: -- Hi Alex, It seems you're using the default content with jspwiki syntax. Did you run [WikiSyntaxConcerter|https://github.com/apache/jspwiki/blob/master/jspwiki-markdown/src/test/java/org/apache/wiki/markdown/migration/WikiSyntaxConverter.java] to transform the default content? Perhaps that's not clear from the markdown instructions :-? HTH > Changing jspwiki.syntax=markdown breaks all the predefined/default wiki > content > --- > > Key: JSPWIKI-1190 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-32-13-401.png > > > here's what i'm seeing on the left menu > !image-2024-03-31-12-32-13-401.png! > > i'm not sure how to tackle this, but maybe the fix for this is to have each > page have a syntax setting. that would enable the existing content to not > break but still offer additional options for editors > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1193) Wysiwyg editor, make it easier to add image to the page from an attachment
Alex O'Ree created JSPWIKI-1193: --- Summary: Wysiwyg editor, make it easier to add image to the page from an attachment Key: JSPWIKI-1193 URL: https://issues.apache.org/jira/browse/JSPWIKI-1193 Project: JSPWiki Issue Type: Improvement Reporter: Alex O'Ree Attachments: image-2024-03-31-12-49-27-786.png currently, the only option is to hand type in a URL. This is not really that easy to use. The plain text editor's ![ macro/auto complete this is pretty handy, maybe that can be used here? !image-2024-03-31-12-49-27-786.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1191) Wysiwyg editor, pasting in an image produces a data url, but renders an error
[ https://issues.apache.org/jira/browse/JSPWIKI-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JSPWIKI-1191: Description: I'm in search of an easy way for users to put images into wiki content besides the attachments upload option, then manually linking them. So i tried to just paste in some content to the wysiwyg editor. which worked in the editor, however after viewing the page, i got this. note: this happens with markdown syntax or with the default syntax No InterWiki reference defined in properties for Wiki called "data"! !image-2024-03-31-12-37-49-281.png! was: I'm in search of an easy way for users to put images into wiki content besides the attachments upload option, then manually linking them. So i tried to just paste in some content to the wysiwyg editor. which worked in the editor, however after viewing the page, i got this. note: i'm still in markdown syntax for this, so maybe that's the issue No InterWiki reference defined in properties for Wiki called "data"! !image-2024-03-31-12-37-49-281.png! > Wysiwyg editor, pasting in an image produces a data url, but renders an error > - > > Key: JSPWIKI-1191 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1191 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-37-49-281.png > > > I'm in search of an easy way for users to put images into wiki content > besides the attachments upload option, then manually linking them. So i tried > to just paste in some content to the wysiwyg editor. which worked in the > editor, however after viewing the page, i got this. note: this happens with > markdown syntax or with the default syntax > > No InterWiki reference defined in properties for Wiki called "data"! > !image-2024-03-31-12-37-49-281.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1192) Image attachments for plain text editing in markdown mode produces incorrect syntax
Alex O'Ree created JSPWIKI-1192: --- Summary: Image attachments for plain text editing in markdown mode produces incorrect syntax Key: JSPWIKI-1192 URL: https://issues.apache.org/jira/browse/JSPWIKI-1192 Project: JSPWiki Issue Type: Bug Reporter: Alex O'Ree The current workflow for plain text editing is * Info > attachments, upload the images * Edit the page * ![ then select the image * save the changes and hopefully the image renders However it doesn't work as the auto complete suggestion, macro or whatever it is used to render the html of the page does not accept it in markdown Using markdown specific syntax also doesn't appear to work either. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1191) Wysiwyg editor, pasting in an image produces a data url, but renders an error
Alex O'Ree created JSPWIKI-1191: --- Summary: Wysiwyg editor, pasting in an image produces a data url, but renders an error Key: JSPWIKI-1191 URL: https://issues.apache.org/jira/browse/JSPWIKI-1191 Project: JSPWiki Issue Type: Bug Reporter: Alex O'Ree Attachments: image-2024-03-31-12-37-49-281.png I'm in search of an easy way for users to put images into wiki content besides the attachments upload option, then manually linking them. So i tried to just paste in some content to the wysiwyg editor. which worked in the editor, however after viewing the page, i got this. note: i'm still in markdown syntax for this, so maybe that's the issue No InterWiki reference defined in properties for Wiki called "data"! !image-2024-03-31-12-37-49-281.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1189) Switching from wysiwyg editing to plain text leaves behind an overlay
[ https://issues.apache.org/jira/browse/JSPWIKI-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832600#comment-17832600 ] Alex O'Ree commented on JSPWIKI-1189: - !image-2024-03-31-12-36-04-161.png! > Switching from wysiwyg editing to plain text leaves behind an overlay > - > > Key: JSPWIKI-1189 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1189 > Project: JSPWiki > Issue Type: Bug > Components: Editors >Affects Versions: 2.12.1 >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-36-04-161.png > > > not too sure what's going on, but i login, set user preference to dark mode, > save > edit a page, switch to wysiwyg mode, then switch back to plain text and i get > what appears to be a amber tint overlay over the whole screen. Clicking > cancel editing removes it but this is pretty unexpected behavior -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1189) Switching from wysiwyg editing to plain text leaves behind an overlay
[ https://issues.apache.org/jira/browse/JSPWIKI-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex O'Ree updated JSPWIKI-1189: Attachment: image-2024-03-31-12-36-04-161.png > Switching from wysiwyg editing to plain text leaves behind an overlay > - > > Key: JSPWIKI-1189 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1189 > Project: JSPWiki > Issue Type: Bug > Components: Editors >Affects Versions: 2.12.1 >Reporter: Alex O'Ree >Priority: Major > Attachments: image-2024-03-31-12-36-04-161.png > > > not too sure what's going on, but i login, set user preference to dark mode, > save > edit a page, switch to wysiwyg mode, then switch back to plain text and i get > what appears to be a amber tint overlay over the whole screen. Clicking > cancel editing removes it but this is pretty unexpected behavior -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1190) Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content
Alex O'Ree created JSPWIKI-1190: --- Summary: Changing jspwiki.syntax=markdown breaks all the predefined/default wiki content Key: JSPWIKI-1190 URL: https://issues.apache.org/jira/browse/JSPWIKI-1190 Project: JSPWiki Issue Type: Bug Reporter: Alex O'Ree Attachments: image-2024-03-31-12-32-13-401.png here's what i'm seeing on the left menu !image-2024-03-31-12-32-13-401.png! i'm not sure how to tackle this, but maybe the fix for this is to have each page have a syntax setting. that would enable the existing content to not break but still offer additional options for editors -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1189) Switching from wysiwyg editing to plain text leaves behind an overlay
[ https://issues.apache.org/jira/browse/JSPWIKI-1189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832598#comment-17832598 ] Alex O'Ree commented on JSPWIKI-1189: - also noticed this sometimes from just hitting the edit button of pages. although i can't reproduce it consistently > Switching from wysiwyg editing to plain text leaves behind an overlay > - > > Key: JSPWIKI-1189 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1189 > Project: JSPWiki > Issue Type: Bug > Components: Editors >Affects Versions: 2.12.1 >Reporter: Alex O'Ree >Priority: Major > > not too sure what's going on, but i login, set user preference to dark mode, > save > edit a page, switch to wysiwyg mode, then switch back to plain text and i get > what appears to be a amber tint overlay over the whole screen. Clicking > cancel editing removes it but this is pretty unexpected behavior -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1189) Switching from wysiwyg editing to plain text leaves behind an overlay
Alex O'Ree created JSPWIKI-1189: --- Summary: Switching from wysiwyg editing to plain text leaves behind an overlay Key: JSPWIKI-1189 URL: https://issues.apache.org/jira/browse/JSPWIKI-1189 Project: JSPWiki Issue Type: Bug Components: Editors Affects Versions: 2.12.1 Reporter: Alex O'Ree not too sure what's going on, but i login, set user preference to dark mode, save edit a page, switch to wysiwyg mode, then switch back to plain text and i get what appears to be a amber tint overlay over the whole screen. Clicking cancel editing removes it but this is pretty unexpected behavior -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1188) Support system property replacement for jsp wiki configuration properties
[
https://issues.apache.org/jira/browse/JSPWIKI-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated JSPWIKI-1188:
Labels: pull-request-available (was: )
> Support system property replacement for jsp wiki configuration properties
> -
>
> Key: JSPWIKI-1188
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1188
> Project: JSPWiki
> Issue Type: Improvement
> Components: Core storage
>Reporter: Alex O'Ree
>Priority: Major
> Labels: pull-request-available
>
> As a sysadmin/integrator/user of jspwiki, i would really like to automate as
> much as integration work as possible for my use case. This includes
> * generating markdown and attachments to "seed" or initialize the content
> for jsp wiki
> * task automating the deployment of jspwiki's war into tomcat
> * configuring jsp wiki via the properties file
> i also need to be able to run on multiple systems, platforms and containers.
> So that said, jspwiki's properties file has a few settings that require paths
> for storing content, such as
> * jspwiki.fileSystemProvider.pageDir
> * jspwiki.workDir
> * jspwiki.basicAttachmentProvider.storageDir
> When running in tomcat from the command line, the bin path is typically the
> current working directory, meaning relative paths are based on that path.
> However when ran as a windows or systemd service, sometimes the current
> working directory is not bin, it's up folder up. Anyhow, relative paths are a
> poor solution in this case.
> In my experience, since i know i'm running on tomcat, i almost always use the
> system property `catalina.base` for locating paths relative to tomcat for
> extra storage locations for stuff.
> Long story short, most systems support property substitution (maven uses
> velocity for example) and i'd like jspwiki to do the same.
> Example file (as stored)
> * jspwiki.fileSystemProvider.pageDir=${catalina.base}/wiki
> * jspwiki.workDir=${catalina.base}/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=${catalina.base}/wiki
> which would be resolved to something like
> * jspwiki.fileSystemProvider.pageDir=c:/tomcat/wiki
> * jspwiki.workDir=c:/tomcat/work/wiki
> * jspwiki.basicAttachmentProvider.storageDir=c:/tomcat/wiki
> where catalina.base = c:/tomcat. This would effectively enable relative paths
> with some safe guards.
>
> Now as far as implementation, i can think of a few options
> * a DIY, 0 dependency approach to location a ${ and a } in a property value
> to do the substitution
> * maybe use velocity to resolve it, assuming you want to add velocity to the
> dependency list for this project
> * maybe apache commons config might be a better option as they already merge
> system environment variables and system properties. but i'm not clear if it
> does property substitution out of the box
> i'm will to support either way
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JSPWIKI-1188) Support system property replacement for jsp wiki configuration properties
Alex O'Ree created JSPWIKI-1188:
---
Summary: Support system property replacement for jsp wiki
configuration properties
Key: JSPWIKI-1188
URL: https://issues.apache.org/jira/browse/JSPWIKI-1188
Project: JSPWiki
Issue Type: Improvement
Components: Core storage
Reporter: Alex O'Ree
As a sysadmin/integrator/user of jspwiki, i would really like to automate as
much as integration work as possible for my use case. This includes
* generating markdown and attachments to "seed" or initialize the content for
jsp wiki
* task automating the deployment of jspwiki's war into tomcat
* configuring jsp wiki via the properties file
i also need to be able to run on multiple systems, platforms and containers.
So that said, jspwiki's properties file has a few settings that require paths
for storing content, such as
* jspwiki.fileSystemProvider.pageDir
* jspwiki.workDir
* jspwiki.basicAttachmentProvider.storageDir
When running in tomcat from the command line, the bin path is typically the
current working directory, meaning relative paths are based on that path.
However when ran as a windows or systemd service, sometimes the current working
directory is not bin, it's up folder up. Anyhow, relative paths are a poor
solution in this case.
In my experience, since i know i'm running on tomcat, i almost always use the
system property `catalina.base` for locating paths relative to tomcat for extra
storage locations for stuff.
Long story short, most systems support property substitution (maven uses
velocity for example) and i'd like jspwiki to do the same.
Example file (as stored)
* jspwiki.fileSystemProvider.pageDir=${catalina.base}/wiki
* jspwiki.workDir=${catalina.base}/work/wiki
* jspwiki.basicAttachmentProvider.storageDir=${catalina.base}/wiki
which would be resolved to something like
* jspwiki.fileSystemProvider.pageDir=c:/tomcat/wiki
* jspwiki.workDir=c:/tomcat/work/wiki
* jspwiki.basicAttachmentProvider.storageDir=c:/tomcat/wiki
where catalina.base = c:/tomcat. This would effectively enable relative paths
with some safe guards.
Now as far as implementation, i can think of a few options
* a DIY, 0 dependency approach to location a ${ and a } in a property value to
do the substitution
* maybe use velocity to resolve it, assuming you want to add velocity to the
dependency list for this project
* maybe apache commons config might be a better option as they already merge
system environment variables and system properties. but i'm not clear if it
does property substitution out of the box
i'm will to support either way
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1185) Getting started documentation appears to be wrong on min JDK version
[
https://issues.apache.org/jira/browse/JSPWIKI-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Pablo Santos Rodríguez resolved JSPWIKI-1185.
--
Resolution: Fixed
fixed, since 2.12.0 we require Java 11; I thought we changed this throughout
all documentation, but clearly missed this.
best regards, and thanks for reporting this!
> Getting started documentation appears to be wrong on min JDK version
>
>
> Key: JSPWIKI-1185
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1185
> Project: JSPWiki
> Issue Type: Bug
>Reporter: Alex O'Ree
>Priority: Major
>
> looking at [https://jspwiki-wiki.apache.org/Wiki.jsp?page=Getting%20Started]
> It clearly states JDK8 is the minimum, however attempting to start 2.12.1 in
> tomcat 9.latest, it's pretty clear from the error message that it was
> compiled with java 11
>
> {noformat}
> 0-Mar-2024 15:06:03.520 SEVERE [main]
> org.apache.catalina.core.StandardContext.listenerStart Error configuring
> application listener of class [org.apache.wiki.auth.SessionMonitor]
> java.lang.UnsupportedClassVersionError:
> org/apache/wiki/auth/SessionMonitor has been compiled by a more recent
> version of the Java Runtime (class file version 55.0), this version of the
> Java Runtime only recognizes class file versions up to 52.0 (unable to load
> class [org.apache.wiki.auth.SessionMonitor]){noformat}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1187) Broken documentation link
[ https://issues.apache.org/jira/browse/JSPWIKI-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Pablo Santos Rodríguez resolved JSPWIKI-1187. -- Resolution: Fixed Hi! I've dropped that section from the Documentation page, as it seems is not available anymore. If you've signed up at jspwiki-wiki.a.o, please drop a line to either users / dev ML with your wiki name so we can add you to the Gardener wiki group. We had a lot of spamming so we had to up some ACLs in place to protect most of the pages. The Gardener group can edit more than default users, so hopefully you'd be able to edit/correct/etc most pages cheers, jp > Broken documentation link > - > > Key: JSPWIKI-1187 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1187 > Project: JSPWiki > Issue Type: Bug >Reporter: Alex O'Ree >Priority: Major > > [https://jspwiki-wiki.apache.org/Wiki.jsp?page=Documentation] > bottom of this page has the following > h3. Legacy JSPWiki > The old (pre-ASF) JSPWiki documentation is still available on [Janne's > site|http://www.ecyrd.com/JSPWiki/wiki/JSPWikiDocumentation] > > however that doesn't exist anymore. I'd edit it myself but i don't seem to > have permissions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1187) Broken documentation link
Alex O'Ree created JSPWIKI-1187: --- Summary: Broken documentation link Key: JSPWIKI-1187 URL: https://issues.apache.org/jira/browse/JSPWIKI-1187 Project: JSPWiki Issue Type: Bug Reporter: Alex O'Ree [https://jspwiki-wiki.apache.org/Wiki.jsp?page=Documentation] bottom of this page has the following h3. Legacy JSPWiki The old (pre-ASF) JSPWiki documentation is still available on [Janne's site|http://www.ecyrd.com/JSPWiki/wiki/JSPWikiDocumentation] however that doesn't exist anymore. I'd edit it myself but i don't seem to have permissions -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1186) Windows, install.jsp double escapes the jspwiki.workDir and nothing else
Alex O'Ree created JSPWIKI-1186: --- Summary: Windows, install.jsp double escapes the jspwiki.workDir and nothing else Key: JSPWIKI-1186 URL: https://issues.apache.org/jira/browse/JSPWIKI-1186 Project: JSPWiki Issue Type: Bug Reporter: Alex O'Ree minor issue, but after running through install.jsp (running on latest on master from github mirror), it produces a properties like this jspwiki.applicationName = Test wiki jspwiki.fileSystemProvider.pageDir = G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage jspwiki.workDir = G:jspwiki-testapache-tomcat-9.0.86workCatalinalocalhostJSPWiki jspwiki.basicAttachmentProvider.storageDir = G:\\jspwiki-test\\apache-tomcat-9.0.86\\wikistorage jspwiki.pageProvider = VersioningFileProvider i think it's because install.jsp double escapes the work dir when it's rendered in browser, then it gets escaped again when rendering again for the properties file -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1185) Getting started documentation appears to be wrong on min JDK version
Alex O'Ree created JSPWIKI-1185:
---
Summary: Getting started documentation appears to be wrong on min
JDK version
Key: JSPWIKI-1185
URL: https://issues.apache.org/jira/browse/JSPWIKI-1185
Project: JSPWiki
Issue Type: Bug
Reporter: Alex O'Ree
looking at [https://jspwiki-wiki.apache.org/Wiki.jsp?page=Getting%20Started]
It clearly states JDK8 is the minimum, however attempting to start 2.12.1 in
tomcat 9.latest, it's pretty clear from the error message that it was compiled
with java 11
{noformat}
0-Mar-2024 15:06:03.520 SEVERE [main]
org.apache.catalina.core.StandardContext.listenerStart Error configuring
application listener of class [org.apache.wiki.auth.SessionMonitor]
java.lang.UnsupportedClassVersionError: org/apache/wiki/auth/SessionMonitor
has been compiled by a more recent version of the Java Runtime (class file
version 55.0), this version of the Java Runtime only recognizes class file
versions up to 52.0 (unable to load class
[org.apache.wiki.auth.SessionMonitor]){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1138) Install.jsp UI overhaul
[
https://issues.apache.org/jira/browse/JSPWIKI-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated JSPWIKI-1138:
Labels: pull-request-available (was: )
> Install.jsp UI overhaul
> ---
>
> Key: JSPWIKI-1138
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1138
> Project: JSPWiki
> Issue Type: Task
> Components: Core storage
>Affects Versions: 2.11.0-M8
> Environment: Windows new version
> Firefox version 84.0.1
>
>Reporter: Nguyen Dang Khai
>Priority: Major
> Labels: pull-request-available
> Attachments: xsswiki.PNG
>
>
> In function *install.jsp* exist multi xss in parameter
> *jspwiki.applicationName, jspwiki.fileSystemProvider.pageDir ,
> jspwiki.workDir*. parameter not sanitize via method *getContentEncoding*().
> * Request :
> {code:java}
> // POST /wiki_jsp_war/Install.jsp HTTP/1.1
> Host: localhost:8080
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:84.0) Gecko/20100101
> Firefox/84.0
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 248
> Origin: http://localhost:8080
> Connection: close
> Referer: http://localhost:8080/wiki_jsp_war/Install.jsp
> Cookie: JSESSIONID=079AB09DC4350BB216A468B15DC9F8BA;
> XDEBUG_SESSION=XDEBUG_ECLIPSE
> Upgrade-Insecure-Requests:
> 1jspwiki.applicationName=%27%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E=%27%22%3E%3Cscript%3Ealert%281%29%3C%2Fscript%3E=F%3A%5C%5CExtension%5C%5Capache-tomcat-8.5.60%5C%5Ctemp=Configure%21
> {code}
> * Response:
> {code:java}
> // HTTP/1.1 200
> Pragma: no-cache
> Expires: -1
> Cache-Control: no-cache
> Content-Type: text/html;charset=UTF-8
> Content-Language: en-US
> Date: Wed, 23 Dec 2020 10:33:46 GMT
> Connection: close
> Content-Length: 4403
> ...
>
>
> BasicsApplication Name class="form-control" type="text" name="jspwiki.applicationName" size="20"
> value="'">alert(1)"/>
>
>
> What should your wiki be called? Try to use a relative short
> name.Page storage class="form-control" type="text" name="jspwiki.fileSystemProvider.pageDir"
> size="40" value="'">alert(1)"/>
>
>
> By default, JSPWiki will use the VersioningFileProvider that stores
> files in a directory. If you specify a directory that does not exist, JSPWiki
> will try to create it for you. All attachments will also be put in the same
> directory.
> SecurityAdministrator
> account
> Enabled
>
> This wiki has an administrator account named admin
> that is part of the wiki group Admin. By default, JSPWiki's
> security policy grants all members of the Admin group the all-powerful
> AllPermission.
> Advanced SettingsWork
> directory size="40" value="F:Extensionapache-tomcat-8.5.60temp"/>
>
>
> This is the place where all caches and other runtime stuff is
> stored.
>
> After you click Configure!, the installer will write your
> settings to
> F:\Extension\apache-tomcat-8.5.60\temp\jspwiki-custom.properties.
> It will also create an Administrator account with a random password and a
> corresponding Admin group.
> value="Configure!" />
> Here is your new jspwiki-custom.properties
>jspwiki.applicationName = '">alert(1)
> jspwiki.fileSystemProvider.pageDir = '">alert(1)
> jspwiki.workDir = F:Extensionapache-tomcat-8.5.60temp
> jspwiki.basicAttachmentProvider.storageDir = '">alert(1)
> jspwiki.pageProvider = VersioningFileProvider
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1164) if a page is viewed as a result of a search, then < is displayed as
[ https://issues.apache.org/jira/browse/JSPWIKI-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788327#comment-17788327 ] Ulf Dittmer commented on JSPWIKI-1164: -- The highlighting of the search term also causes another issue: it adds a space after each highlighted term. If you search for "event" on https://jspwiki-wiki.apache.org/ and then bring up the result for WikiEventManager (for example), this is very noticeable, because the word appears so many times on that page. > if a page is viewed as a result of a search, then < is displayed as > > > Key: JSPWIKI-1164 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1164 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 > Environment: Tested under Windows with tomcat 9.0.55 and Fedora Linux > with Wildfly 21. >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > > On a normal wiki page, the text ist displayed as . > If this page is found as a search result and then clicked on, then ist > displayed as ;ABC> . > Expectation: ist always displayed as . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1164) if a page is viewed as a result of a search, then < is displayed as
[ https://issues.apache.org/jira/browse/JSPWIKI-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787928#comment-17787928 ] Ulf Dittmer commented on JSPWIKI-1164: -- It seems to have to do something with the highlighting of search results in jspwiki-war/src/main/scripts/moo-extend/HighlightQuery.js. Leaving that function empty turns highlighting off, and this problem no longer occurs. > if a page is viewed as a result of a search, then < is displayed as > > > Key: JSPWIKI-1164 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1164 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 > Environment: Tested under Windows with tomcat 9.0.55 and Fedora Linux > with Wildfly 21. >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > > On a normal wiki page, the text ist displayed as . > If this page is found as a search result and then clicked on, then ist > displayed as ;ABC> . > Expectation: ist always displayed as . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1164) if a page is viewed as a result of a search, then < is displayed as
[ https://issues.apache.org/jira/browse/JSPWIKI-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787887#comment-17787887 ] Ulf Dittmer commented on JSPWIKI-1164: -- I can reproduce this with 2.12.1 > if a page is viewed as a result of a search, then < is displayed as > > > Key: JSPWIKI-1164 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1164 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 > Environment: Tested under Windows with tomcat 9.0.55 and Fedora Linux > with Wildfly 21. >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > > On a normal wiki page, the text ist displayed as . > If this page is found as a search result and then clicked on, then ist > displayed as ;ABC> . > Expectation: ist always displayed as . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1184) Image missing and German text typo
[ https://issues.apache.org/jira/browse/JSPWIKI-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Pablo Santos Rodríguez resolved JSPWIKI-1184. -- Fix Version/s: 2.12.2 Resolution: Fixed went ahead and fixed it in 2.12.2-git-08. [~udittmer], thanks for spotting it! > Image missing and German text typo > -- > > Key: JSPWIKI-1184 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1184 > Project: JSPWiki > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Ulf Dittmer >Priority: Minor > Fix For: 2.12.2 > > > I noticed two small bugs, both visible on > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin > The Note plugin is currently broken because the image file > jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in > jspwiki-war/src/main/webapp/templates/default/images > The German translation of the _javascript.broken.image_ property has a typo > "nichr" - which should read "nicht" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1184) Image missing and German text typo
[ https://issues.apache.org/jira/browse/JSPWIKI-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787668#comment-17787668 ] ASF subversion and git services commented on JSPWIKI-1184: -- Commit aaf37c166b4677b08e2974c3f9f9dac3da3005a8 in jspwiki's branch refs/heads/master from Juan Pablo Santos Rodríguez [ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=aaf37c166 ] JSPWIKI-1184: Image missing and German text typo > Image missing and German text typo > -- > > Key: JSPWIKI-1184 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1184 > Project: JSPWiki > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Ulf Dittmer >Priority: Minor > > I noticed two small bugs, both visible on > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin > The Note plugin is currently broken because the image file > jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in > jspwiki-war/src/main/webapp/templates/default/images > The German translation of the _javascript.broken.image_ property has a typo > "nichr" - which should read "nicht" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1184) Image missing and German text typo
[ https://issues.apache.org/jira/browse/JSPWIKI-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787229#comment-17787229 ] Ulf Dittmer commented on JSPWIKI-1184: -- Do you mean add the image manually to the running installation? Yes, that would fix the issue right away. > Image missing and German text typo > -- > > Key: JSPWIKI-1184 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1184 > Project: JSPWiki > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Ulf Dittmer >Priority: Minor > > I noticed two small bugs, both visible on > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin > The Note plugin is currently broken because the image file > jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in > jspwiki-war/src/main/webapp/templates/default/images > The German translation of the _javascript.broken.image_ property has a typo > "nichr" - which should read "nicht" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1184) Image missing and German text typo
[ https://issues.apache.org/jira/browse/JSPWIKI-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786194#comment-17786194 ] Arturo Bernal commented on JSPWIKI-1184: HI [~udittmer] Should i added manually? TY > Image missing and German text typo > -- > > Key: JSPWIKI-1184 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1184 > Project: JSPWiki > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Ulf Dittmer >Priority: Minor > > I noticed two small bugs, both visible on > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin > The Note plugin is currently broken because the image file > jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in > jspwiki-war/src/main/webapp/templates/default/images > The German translation of the _javascript.broken.image_ property has a typo > "nichr" - which should read "nicht" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1184) Image missing and German text typo
[ https://issues.apache.org/jira/browse/JSPWIKI-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785208#comment-17785208 ] Ulf Dittmer commented on JSPWIKI-1184: -- Well, that URL doesn't exist, so a 404 is to be expected. But as soon as that image is put into that directory, the correct URL is generated, and the 404 goes away. The plugin is not very smart about the missing image :) > Image missing and German text typo > -- > > Key: JSPWIKI-1184 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1184 > Project: JSPWiki > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Ulf Dittmer >Priority: Minor > > I noticed two small bugs, both visible on > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin > The Note plugin is currently broken because the image file > jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in > jspwiki-war/src/main/webapp/templates/default/images > The German translation of the _javascript.broken.image_ property has a typo > "nichr" - which should read "nicht" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1184) Image missing and German text typo
[
https://issues.apache.org/jira/browse/JSPWIKI-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785191#comment-17785191
]
Arturo Bernal commented on JSPWIKI-1184:
What's bothering me is a 404 error. GET request to
{{https://jspwiki-wiki.apache.org/Main}} results in a 404 (Not Found) response.
> Image missing and German text typo
> --
>
> Key: JSPWIKI-1184
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1184
> Project: JSPWiki
> Issue Type: Bug
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
>
> I noticed two small bugs, both visible on
> https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin
> The Note plugin is currently broken because the image file
> jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in
> jspwiki-war/src/main/webapp/templates/default/images
> The German translation of the _javascript.broken.image_ property has a typo
> "nichr" - which should read "nicht"
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1184) Image missing and German text typo
[ https://issues.apache.org/jira/browse/JSPWIKI-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulf Dittmer updated JSPWIKI-1184: - Description: I noticed two small bugs, both visible on https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin The Note plugin is currently broken because the image file jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in jspwiki-war/src/main/webapp/templates/default/images The German translation of the _javascript.broken.image_ property has a typo "nichr" - which should read "nicht" was: I noticed two small bugs, both visible on [https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin|NotePlugin] The Note plugin is currently broken because the image file jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in jspwiki-war/src/main/webapp/templates/default/images The German translation of the _javascript.broken.image_ property has a typo "nichr" - which should read "nicht" > Image missing and German text typo > -- > > Key: JSPWIKI-1184 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1184 > Project: JSPWiki > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Ulf Dittmer >Priority: Minor > > I noticed two small bugs, both visible on > https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin > The Note plugin is currently broken because the image file > jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in > jspwiki-war/src/main/webapp/templates/default/images > The German translation of the _javascript.broken.image_ property has a typo > "nichr" - which should read "nicht" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1184) Image missing and German text typo
Ulf Dittmer created JSPWIKI-1184: Summary: Image missing and German text typo Key: JSPWIKI-1184 URL: https://issues.apache.org/jira/browse/JSPWIKI-1184 Project: JSPWiki Issue Type: Bug Affects Versions: 2.12.1 Reporter: Ulf Dittmer I noticed two small bugs, both visible on [https://jspwiki-wiki.apache.org/Wiki.jsp?page=NotePlugin|NotePlugin] The Note plugin is currently broken because the image file jspwiki-war/src/main/webapp/templates/210/images/note.png is missing in jspwiki-war/src/main/webapp/templates/default/images The German translation of the _javascript.broken.image_ property has a typo "nichr" - which should read "nicht" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1183) Support IP ranges in IfPlugin
[
https://issues.apache.org/jira/browse/JSPWIKI-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Dittmer updated JSPWIKI-1183:
-
Description:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
(I have removed the rest of text to an attachment, as it was an endless battle
with getting the formatting to display the mix of text and code correctly.)
was:
{quote}The IfPlugin.checkIP method has a comment "TODO: Add subnetwork
matching, e.g. 10.0.0.0/8". This is a patch to address this. Sorry that this
does not come as a PR, but the changes are limited in scope.
Additions to pom.xml
5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
Additions to jspwiki-util/pom.xml
com.github.seancfoley
ipaddress
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy.
That's not directly related to this patch, but useful nonetheless.
/**
* returns the remote address by looking into \{@code x-forwarded-for}
header or, if unavailable,
* into \{@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}
This method is new
/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {
String requestIP = getRemoteAddress(req);
if (ipOrRange.contains("/")) {
IPAddressString testRange = new IPAddressString(ipOrRange);
return testRange.contains(new IPAddressString(requestIP));
} else {
return requestIP.equals(ipOrRange);
}
}
Changes in jspwiki-main/src/main/java/org/apache/wiki/plugin/IfPlugin.java
Instead of
include |= ipaddrToCheck.equals( HttpUtil.getRemoteAddress(
context.getHttpRequest() ) ) ^ invert;
now it should read
include |= HttpUtil.ipIsInRange( context.getHttpRequest(),
ipaddrToCheck ) ^ invert;
That's all. Now the IfPlugin accepts something like
[{If ip='192.168.0.0/16|10.0.0.0/8|127.0.0.1'
Secret stuff for localhost}]
{quote}
> Support IP ranges in IfPlugin
> -
>
> Key: JSPWIKI-1183
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1183
> Project: JSPWiki
> Issue Type: Improvement
> Components: Plugins
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
> Attachments: JSPWIKI-1183-patch.txt
>
>
> The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching,
> e.g. 10.0.0.0/8". This is a patch to address this. Sorry that this does not
> come as a PR, but the changes are limited in scope.
> (I have removed the rest of text to an attachment, as it was an endless
> battle with getting the formatting to display the mix of text and code
> correctly.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1183) Support IP ranges in IfPlugin
[
https://issues.apache.org/jira/browse/JSPWIKI-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Dittmer updated JSPWIKI-1183:
-
Attachment: JSPWIKI-1183-patch.txt
> Support IP ranges in IfPlugin
> -
>
> Key: JSPWIKI-1183
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1183
> Project: JSPWiki
> Issue Type: Improvement
> Components: Plugins
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
> Attachments: JSPWIKI-1183-patch.txt
>
>
> {quote}The IfPlugin.checkIP method has a comment "TODO: Add subnetwork
> matching, e.g. 10.0.0.0/8". This is a patch to address this. Sorry that this
> does not come as a PR, but the changes are limited in scope.
> Additions to pom.xml
> 5.4.0
>
> com.github.seancfoley
> ipaddress
> ${ipaddress.version}
>
> Additions to jspwiki-util/pom.xml
>
> com.github.seancfoley
> ipaddress
>
> Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
> This method now checks whether the IP contains a comma, which can happen if
> the request goes through more than one proxy.
> That's not directly related to this patch, but useful nonetheless.
> /**
> * returns the remote address by looking into \{@code x-forwarded-for}
> header or, if unavailable,
> * into \{@link HttpServletRequest#getRemoteAddr()}.
> *
> * @param req http request
> * @return remote address associated to the request.
> */
> public static String getRemoteAddress( final HttpServletRequest req ) {
> String realIP = StringUtils.isNotEmpty ( req.getHeader(
> "X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
>
> req.getRemoteAddr();
> // can be a comma-separated list of IPs
> if (realIP.contains(","))
> realIP = realIP.substring(realIP.indexOf(","));
> return realIP;
> }
> This method is new
> /**
> * Returns whether or not the IP address of the request equals a given
> IP, or is in a given IP range
> *
> * @param req http request
> * @param ipOrRange IP address or IP range to test against
> * @return
> */
> public static boolean ipIsInRange ( final HttpServletRequest req, final
> String ipOrRange ) {
> String requestIP = getRemoteAddress(req);
> if (ipOrRange.contains("/")) {
> IPAddressString testRange = new IPAddressString(ipOrRange);
> return testRange.contains(new IPAddressString(requestIP));
> } else {
> return requestIP.equals(ipOrRange);
> }
> }
> Changes in jspwiki-main/src/main/java/org/apache/wiki/plugin/IfPlugin.java
> Instead of
> include |= ipaddrToCheck.equals( HttpUtil.getRemoteAddress(
> context.getHttpRequest() ) ) ^ invert;
> now it should read
> include |= HttpUtil.ipIsInRange( context.getHttpRequest(),
> ipaddrToCheck ) ^ invert;
> That's all. Now the IfPlugin accepts something like
> [{If ip='192.168.0.0/16|10.0.0.0/8|127.0.0.1'
> Secret stuff for localhost}]
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1183) Support IP ranges in IfPlugin
[
https://issues.apache.org/jira/browse/JSPWIKI-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Dittmer updated JSPWIKI-1183:
-
Description:
{quote}The IfPlugin.checkIP method has a comment "TODO: Add subnetwork
matching, e.g. 10.0.0.0/8". This is a patch to address this. Sorry that this
does not come as a PR, but the changes are limited in scope.
Additions to pom.xml
5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
Additions to jspwiki-util/pom.xml
com.github.seancfoley
ipaddress
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy.
That's not directly related to this patch, but useful nonetheless.
/**
* returns the remote address by looking into \{@code x-forwarded-for}
header or, if unavailable,
* into \{@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}
This method is new
/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {
String requestIP = getRemoteAddress(req);
if (ipOrRange.contains("/")) {
IPAddressString testRange = new IPAddressString(ipOrRange);
return testRange.contains(new IPAddressString(requestIP));
} else {
return requestIP.equals(ipOrRange);
}
}
Changes in jspwiki-main/src/main/java/org/apache/wiki/plugin/IfPlugin.java
Instead of
include |= ipaddrToCheck.equals( HttpUtil.getRemoteAddress(
context.getHttpRequest() ) ) ^ invert;
now it should read
include |= HttpUtil.ipIsInRange( context.getHttpRequest(),
ipaddrToCheck ) ^ invert;
That's all. Now the IfPlugin accepts something like
[{If ip='192.168.0.0/16|10.0.0.0/8|127.0.0.1'
Secret stuff for localhost}]
{quote}
was:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
Additions to jspwiki-util/pom.xml
com.github.seancfoley
ipaddress
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy.
That's not directly related to this patch, but useful nonetheless.
/**
* returns the remote address by looking into \{@code x-forwarded-for}
header or, if unavailable,
* into \{@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}
This method is new
/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {
String requestIP = getRemoteAddress(req);
if (ipOrRange.contains("/")) {
IPAddressString testRange = new IPAddressString(ipOrRange);
return testRange.contains(new IPAddressString(requestIP));
} else {
return r
[jira] [Updated] (JSPWIKI-1183) Support IP ranges in IfPlugin
[
https://issues.apache.org/jira/browse/JSPWIKI-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Dittmer updated JSPWIKI-1183:
-
Description:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
{{{}5.4.0{}}}{{{}{}}}
{{com.github.seancfoley}}
{{ipaddress}}
{{${ipaddress.version}}}
{{}}
{{Additions to jspwiki-util/pom.xml}}
{{}}
{{com.github.seancfoley}}
{{ipaddress}}
{{}}
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy. That's not directly related to this
patch, but useful nonetheless.
{{ /**}}
{{ * returns the remote address by looking into \{@code x-forwarded-for}
header or, if unavailable,}}
{{ * into \{@link HttpServletRequest#getRemoteAddr()}.}}
{{ *}}
{{ * @param req http request}}
{{ * @return remote address associated to the request.}}
{{ */}}
{{ public static String getRemoteAddress( final HttpServletRequest req ) {}}
{{ String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :}}
{{
req.getRemoteAddr();}}
{{ // can be a comma-separated list of IPs}}
{{ if (realIP.contains(","))}}
{{ realIP = realIP.substring(realIP.indexOf(","));}}{{ return
realIP;}}
{{ }}}
This method is new
{{ /**}}
{{ * Returns whether or not the IP address of the request equals a given
IP, or is in a given IP range}}
{{ *}}
{{ * @param req http request}}
{{ * @param ipOrRange IP address or IP range to test against}}
{{ * @return }}
{{ */}}
{{ public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {}}
{{ String requestIP = getRemoteAddress(req);}}
{{ if (ipOrRange.contains("/")) {}}
{{ IPAddressString testRange = new IPAddressString(ipOrRange);}}
{{ return testRange.contains(new IPAddressString(requestIP));}}
{{ } else {}}
{{ return requestIP.equals(ipOrRange);}}
{{ }}}
{{ }}}
Changes in jspwiki-main/src/main/java/org/apache/wiki/plugin/IfPlugin.java
{{Instead of}}
{{include |= ipaddrToCheck.equals( HttpUtil.getRemoteAddress(
context.getHttpRequest() ) ) ^ invert;}}
now it should read
{{include |= HttpUtil.ipIsInRange( context.getHttpRequest(), ipaddrToCheck ) ^
invert;}}
That's all. Now the IfPlugin accepts something like
{{{}[{If ip='192.168.0.0/16|10.0.0.0/8|127.0.0.1'{}}}{{{}Secret stuff for
localhost and local networks}]{}}}
was:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
{{5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
}}
Additions to jspwiki-util/pom.xml
{{
com.github.seancfoley
ipaddress
}}
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy. That's not directly related to this
patch, but useful nonetheless.
{{/**
* returns the remote address by looking into {@code x-forwarded-for}
header or, if unavailable,
* into {@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}}}
This method is new
{{/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {
String requestIP = getRemoteAddres
[jira] [Updated] (JSPWIKI-1183) Support IP ranges in IfPlugin
[
https://issues.apache.org/jira/browse/JSPWIKI-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Dittmer updated JSPWIKI-1183:
-
Description:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
Additions to jspwiki-util/pom.xml
com.github.seancfoley
ipaddress
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy.
That's not directly related to this patch, but useful nonetheless.
/**
* returns the remote address by looking into \{@code x-forwarded-for}
header or, if unavailable,
* into \{@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}
This method is new
/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {
String requestIP = getRemoteAddress(req);
if (ipOrRange.contains("/")) {
IPAddressString testRange = new IPAddressString(ipOrRange);
return testRange.contains(new IPAddressString(requestIP));
} else {
return requestIP.equals(ipOrRange);
}
}
Changes in jspwiki-main/src/main/java/org/apache/wiki/plugin/IfPlugin.java
Instead of
include |= ipaddrToCheck.equals( HttpUtil.getRemoteAddress(
context.getHttpRequest() ) ) ^ invert;
now it should read
include |= HttpUtil.ipIsInRange( context.getHttpRequest(),
ipaddrToCheck ) ^ invert;
That's all. Now the IfPlugin accepts something like
[{If ip='192.168.0.0/16|10.0.0.0/8|127.0.0.1'
Secret stuff for localhost}]
was:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
{{{}5.4.0{}}}{{{}{}}}
{{com.github.seancfoley}}
{{ipaddress}}
{{${ipaddress.version}}}
{{}}
{{Additions to jspwiki-util/pom.xml}}
{{}}
{{com.github.seancfoley}}
{{ipaddress}}
{{}}
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy. That's not directly related to this
patch, but useful nonetheless.
{{ /**}}
{{ * returns the remote address by looking into \{@code x-forwarded-for}
header or, if unavailable,}}
{{ * into \{@link HttpServletRequest#getRemoteAddr()}.}}
{{ *}}
{{ * @param req http request}}
{{ * @return remote address associated to the request.}}
{{ */}}
{{ public static String getRemoteAddress( final HttpServletRequest req ) {}}
{{ String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :}}
{{
req.getRemoteAddr();}}
{{ // can be a comma-separated list of IPs}}
{{ if (realIP.contains(","))}}
{{ realIP = realIP.substring(realIP.indexOf(","));}}{{ return
realIP;}}
{{ }}}
This method is new
{{ /**}}
{{ * Returns whether or not the IP address of the request equals a given
IP, or is in a given IP range}}
{{ *}}
{{ * @param req http request}}
{{ * @param ipOrRange IP address or IP range to test against}}
{{ * @return }}
{{ */}}
{{ public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {}}
{{ String requestIP = getRemoteAddress(req);}}
{{ if (ipOrRange.contains("/")) {}}
{{ IPAddressString testRange = new IPAddressString(ipOrRange);}}
{{ return te
[jira] [Updated] (JSPWIKI-1183) Support IP ranges in IfPlugin
[
https://issues.apache.org/jira/browse/JSPWIKI-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ulf Dittmer updated JSPWIKI-1183:
-
Description:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
{{5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
}}
Additions to jspwiki-util/pom.xml
{{
com.github.seancfoley
ipaddress
}}
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy. That's not directly related to this
patch, but useful nonetheless.
{{/**
* returns the remote address by looking into {@code x-forwarded-for}
header or, if unavailable,
* into {@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}}}
This method is new
{{/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {
String requestIP = getRemoteAddress(req);
if (ipOrRange.contains("/")) {
IPAddressString testRange = new
IPAddressString(ipOrRange);
return testRange.contains(new
IPAddressString(requestIP));
} else {
return requestIP.equals(ipOrRange);
}
}
}}
Changes in jspwiki-main/src/main/java/org/apache/wiki/plugin/IfPlugin.java
Instead of
{{include |= ipaddrToCheck.equals( HttpUtil.getRemoteAddress(
context.getHttpRequest() ) ) ^ invert;}}
now it should read
{{include |= HttpUtil.ipIsInRange( context.getHttpRequest(),
ipaddrToCheck ) ^ invert;}}
That's all. Now the IfPlugin accepts something like
[{If ip='192.168.0.0/16|10.0.0.0/8|127.0.0.1'
Secret stuff for localhost and local networks}]
was:
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
Additions to jspwiki-util/pom.xml
com.github.seancfoley
ipaddress
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy. That's not directly related to this
patch, but useful nonetheless.
/**
* returns the remote address by looking into {@code x-forwarded-for}
header or, if unavailable,
* into {@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}
This method is new
/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String
[jira] [Created] (JSPWIKI-1183) Support IP ranges in IfPlugin
Ulf Dittmer created JSPWIKI-1183:
Summary: Support IP ranges in IfPlugin
Key: JSPWIKI-1183
URL: https://issues.apache.org/jira/browse/JSPWIKI-1183
Project: JSPWiki
Issue Type: Improvement
Components: Plugins
Affects Versions: 2.12.1
Reporter: Ulf Dittmer
The IfPlugin.checkIP method has a comment "TODO: Add subnetwork matching, e.g.
10.0.0.0/8". This is a patch to address this. Sorry that this does not come as
a PR, but the changes are limited in scope.
Additions to pom.xml
5.4.0
com.github.seancfoley
ipaddress
${ipaddress.version}
Additions to jspwiki-util/pom.xml
com.github.seancfoley
ipaddress
Changes in jspwiki-util/src/main/java/org/apache/wiki/util/HttpUtil.java
This method now checks whether the IP contains a comma, which can happen if the
request goes through more than one proxy. That's not directly related to this
patch, but useful nonetheless.
/**
* returns the remote address by looking into {@code x-forwarded-for}
header or, if unavailable,
* into {@link HttpServletRequest#getRemoteAddr()}.
*
* @param req http request
* @return remote address associated to the request.
*/
public static String getRemoteAddress( final HttpServletRequest req ) {
String realIP = StringUtils.isNotEmpty ( req.getHeader(
"X-Forwarded-For" ) ) ? req.getHeader( "X-Forwarded-For" ) :
req.getRemoteAddr();
// can be a comma-separated list of IPs
if (realIP.contains(","))
realIP = realIP.substring(realIP.indexOf(","));
return realIP;
}
This method is new
/**
* Returns whether or not the IP address of the request equals a given IP,
or is in a given IP range
*
* @param req http request
* @param ipOrRange IP address or IP range to test against
* @return
*/
public static boolean ipIsInRange ( final HttpServletRequest req, final
String ipOrRange ) {
String requestIP = getRemoteAddress(req);
if (ipOrRange.contains("/")) {
IPAddressString testRange = new
IPAddressString(ipOrRange);
return testRange.contains(new
IPAddressString(requestIP));
} else {
return requestIP.equals(ipOrRange);
}
}
Changes in jspwiki-main/src/main/java/org/apache/wiki/plugin/IfPlugin.java
Instead of
include |= ipaddrToCheck.equals( HttpUtil.getRemoteAddress(
context.getHttpRequest() ) ) ^ invert;
now it should read
include |= HttpUtil.ipIsInRange( context.getHttpRequest(),
ipaddrToCheck ) ^ invert;
That's all. Now the IfPlugin accepts something like
[{If ip='192.168.0.0/16|10.0.0.0/8|127.0.0.1'
Secret stuff for localhost and local networks}]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-925) Missing i18n resources
[ https://issues.apache.org/jira/browse/JSPWIKI-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774176#comment-17774176 ] ASF subversion and git services commented on JSPWIKI-925: - Commit 0e703223906e31b1b3c77d7e68d2563b598335ac in jspwiki's branch refs/heads/master from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=0e7032239 ] JSPWIKI-925: Add missing i18n literals for multiple languages This commit addresses the missing i18n literals between version 2.10.1 and the current trunk. Specifically, missing entries have been added for the following languages and their respective properties files: - German (de) - Finnish (fi) - French (fr) - Italian (it) - Dutch (nl) - Brazilian Portuguese (pt_BR) - Russian (ru) - Simplified Chinese (zh_CN) > Missing i18n resources > -- > > Key: JSPWIKI-925 > URL: https://issues.apache.org/jira/browse/JSPWIKI-925 > Project: JSPWiki > Issue Type: Task > Components: Localization >Reporter: Juan Pablo Santos Rodríguez >Assignee: Arturo Bernal >Priority: Major > Labels: pull-request-available > Fix For: 2.12.2 > > > Between 2.10.1 and current trunk, a number of i18n literals have been > introduced; it would be nice to have them translated for 2.10.2 > Specifically: > * de > ** /CoreResources_de.properties: 1 entry missing > ** /templates/default_de.properties: 32 entries missing, 1 outdated > * fi > ** /CoreResources_fi.properties: 4 entries missing > ** /templates/default_fi.properties: 35 entries missing, 1 outdated > * fr > ** /CoreResources_fr.properties: 1 entry missing > ** /templates/default_fr.properties: 32 entries missing, 1 outdated > * it > ** /CoreResources_it.properties: 1 entry missing > ** /templates/default_it.properties: 32 entries missing, 1 outdated > * nl > ** /templates/default_nl.properties: 2 entries missing > * pt_BR > ** /CoreResources_pt_BR.properties: 1 entry missing > ** /templates/default_pt_BR.properties: 192 entries missing > * ru > ** /CoreResources_ru.properties: 1 entry missing > ** /templates/default_ru.properties: 32 entries missing, 1 outdated > * zh_CN > ** /CoreResources_zh_CN.properties: 1 entry missing > ** /templates/default_zh_CN.properties: 32 entries missing, 1 outdated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-925) Missing i18n resources
[ https://issues.apache.org/jira/browse/JSPWIKI-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774177#comment-17774177 ] ASF subversion and git services commented on JSPWIKI-925: - Commit 59f1678bf4aedbea2f7d94ee8397478ed2a016d7 in jspwiki's branch refs/heads/master from Arturo Bernal [ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=59f1678bf ] Merge pull request #312 from arturobernalg/JSPWIKI-925 JSPWIKI-925 - Add Missing i18n Literals for Multiple Languages > Missing i18n resources > -- > > Key: JSPWIKI-925 > URL: https://issues.apache.org/jira/browse/JSPWIKI-925 > Project: JSPWiki > Issue Type: Task > Components: Localization >Reporter: Juan Pablo Santos Rodríguez >Assignee: Arturo Bernal >Priority: Major > Labels: pull-request-available > Fix For: 2.12.2 > > > Between 2.10.1 and current trunk, a number of i18n literals have been > introduced; it would be nice to have them translated for 2.10.2 > Specifically: > * de > ** /CoreResources_de.properties: 1 entry missing > ** /templates/default_de.properties: 32 entries missing, 1 outdated > * fi > ** /CoreResources_fi.properties: 4 entries missing > ** /templates/default_fi.properties: 35 entries missing, 1 outdated > * fr > ** /CoreResources_fr.properties: 1 entry missing > ** /templates/default_fr.properties: 32 entries missing, 1 outdated > * it > ** /CoreResources_it.properties: 1 entry missing > ** /templates/default_it.properties: 32 entries missing, 1 outdated > * nl > ** /templates/default_nl.properties: 2 entries missing > * pt_BR > ** /CoreResources_pt_BR.properties: 1 entry missing > ** /templates/default_pt_BR.properties: 192 entries missing > * ru > ** /CoreResources_ru.properties: 1 entry missing > ** /templates/default_ru.properties: 32 entries missing, 1 outdated > * zh_CN > ** /CoreResources_zh_CN.properties: 1 entry missing > ** /templates/default_zh_CN.properties: 32 entries missing, 1 outdated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-925) Missing i18n resources
[ https://issues.apache.org/jira/browse/JSPWIKI-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal resolved JSPWIKI-925. --- Resolution: Fixed Merge in master > Missing i18n resources > -- > > Key: JSPWIKI-925 > URL: https://issues.apache.org/jira/browse/JSPWIKI-925 > Project: JSPWiki > Issue Type: Task > Components: Localization >Reporter: Juan Pablo Santos Rodríguez >Assignee: Arturo Bernal >Priority: Major > Labels: pull-request-available > Fix For: 2.12.2 > > > Between 2.10.1 and current trunk, a number of i18n literals have been > introduced; it would be nice to have them translated for 2.10.2 > Specifically: > * de > ** /CoreResources_de.properties: 1 entry missing > ** /templates/default_de.properties: 32 entries missing, 1 outdated > * fi > ** /CoreResources_fi.properties: 4 entries missing > ** /templates/default_fi.properties: 35 entries missing, 1 outdated > * fr > ** /CoreResources_fr.properties: 1 entry missing > ** /templates/default_fr.properties: 32 entries missing, 1 outdated > * it > ** /CoreResources_it.properties: 1 entry missing > ** /templates/default_it.properties: 32 entries missing, 1 outdated > * nl > ** /templates/default_nl.properties: 2 entries missing > * pt_BR > ** /CoreResources_pt_BR.properties: 1 entry missing > ** /templates/default_pt_BR.properties: 192 entries missing > * ru > ** /CoreResources_ru.properties: 1 entry missing > ** /templates/default_ru.properties: 32 entries missing, 1 outdated > * zh_CN > ** /CoreResources_zh_CN.properties: 1 entry missing > ** /templates/default_zh_CN.properties: 32 entries missing, 1 outdated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1182) Reorder and Rename i18n Literals According to Usage Context
[ https://issues.apache.org/jira/browse/JSPWIKI-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-1182: --- Assignee: Arturo Bernal > Reorder and Rename i18n Literals According to Usage Context > --- > > Key: JSPWIKI-1182 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1182 > Project: JSPWiki > Issue Type: Improvement >Affects Versions: 2.12.1 >Reporter: Arturo Bernal >Assignee: Arturo Bernal >Priority: Minor > Fix For: 2.12.2 > > > In the recent pull request addressing missing i18n literals (JSPWIKI-925), it > was noted that the literals are not in alphabetical order. Additionally, the > current ordering loosely follows the order of JSPs, which may not be the most > intuitive way to manage them. > This ticket aims to address the following: > # Reorder the i18n literals alphabetically or according to a more logical or > intuitive scheme. > # Consider renaming the literals to better reflect where they are being used > in the application. > By tackling these issues in a separate ticket, we can maintain a cleaner, > more organized codebase and make it easier for contributors to locate and > manage i18n literals in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1182) Reorder and Rename i18n Literals According to Usage Context
[ https://issues.apache.org/jira/browse/JSPWIKI-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-1182: --- Assignee: (was: Arturo Bernal) > Reorder and Rename i18n Literals According to Usage Context > --- > > Key: JSPWIKI-1182 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1182 > Project: JSPWiki > Issue Type: Improvement >Affects Versions: 2.12.1 >Reporter: Arturo Bernal >Priority: Minor > > In the recent pull request addressing missing i18n literals (JSPWIKI-925), it > was noted that the literals are not in alphabetical order. Additionally, the > current ordering loosely follows the order of JSPs, which may not be the most > intuitive way to manage them. > This ticket aims to address the following: > # Reorder the i18n literals alphabetically or according to a more logical or > intuitive scheme. > # Consider renaming the literals to better reflect where they are being used > in the application. > By tackling these issues in a separate ticket, we can maintain a cleaner, > more organized codebase and make it easier for contributors to locate and > manage i18n literals in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1182) Reorder and Rename i18n Literals According to Usage Context
[ https://issues.apache.org/jira/browse/JSPWIKI-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-1182: --- Fix Version/s: (was: 2.12.2) > Reorder and Rename i18n Literals According to Usage Context > --- > > Key: JSPWIKI-1182 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1182 > Project: JSPWiki > Issue Type: Improvement >Affects Versions: 2.12.1 >Reporter: Arturo Bernal >Assignee: Arturo Bernal >Priority: Minor > > In the recent pull request addressing missing i18n literals (JSPWIKI-925), it > was noted that the literals are not in alphabetical order. Additionally, the > current ordering loosely follows the order of JSPs, which may not be the most > intuitive way to manage them. > This ticket aims to address the following: > # Reorder the i18n literals alphabetically or according to a more logical or > intuitive scheme. > # Consider renaming the literals to better reflect where they are being used > in the application. > By tackling these issues in a separate ticket, we can maintain a cleaner, > more organized codebase and make it easier for contributors to locate and > manage i18n literals in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-925) Missing i18n resources
[ https://issues.apache.org/jira/browse/JSPWIKI-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-925: -- Fix Version/s: 2.12.2 > Missing i18n resources > -- > > Key: JSPWIKI-925 > URL: https://issues.apache.org/jira/browse/JSPWIKI-925 > Project: JSPWiki > Issue Type: Task > Components: Localization >Reporter: Juan Pablo Santos Rodríguez >Assignee: Arturo Bernal >Priority: Major > Labels: pull-request-available > Fix For: 2.12.2 > > > Between 2.10.1 and current trunk, a number of i18n literals have been > introduced; it would be nice to have them translated for 2.10.2 > Specifically: > * de > ** /CoreResources_de.properties: 1 entry missing > ** /templates/default_de.properties: 32 entries missing, 1 outdated > * fi > ** /CoreResources_fi.properties: 4 entries missing > ** /templates/default_fi.properties: 35 entries missing, 1 outdated > * fr > ** /CoreResources_fr.properties: 1 entry missing > ** /templates/default_fr.properties: 32 entries missing, 1 outdated > * it > ** /CoreResources_it.properties: 1 entry missing > ** /templates/default_it.properties: 32 entries missing, 1 outdated > * nl > ** /templates/default_nl.properties: 2 entries missing > * pt_BR > ** /CoreResources_pt_BR.properties: 1 entry missing > ** /templates/default_pt_BR.properties: 192 entries missing > * ru > ** /CoreResources_ru.properties: 1 entry missing > ** /templates/default_ru.properties: 32 entries missing, 1 outdated > * zh_CN > ** /CoreResources_zh_CN.properties: 1 entry missing > ** /templates/default_zh_CN.properties: 32 entries missing, 1 outdated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1056) URL in registration mail is relative while it should be absolute
[
https://issues.apache.org/jira/browse/JSPWIKI-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774170#comment-17774170
]
ASF subversion and git services commented on JSPWIKI-1056:
--
Commit 041cd532b56b78bcc080b2ef7404ef8eda246548 in jspwiki's branch
refs/heads/master from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=041cd532b ]
JSPWIKI-1056: Enhance Absolute URL Utility Methods in HttpUtil
- Implement getAbsoluteUrl methods in HttpUtil to construct absolute URLs,
considering various headers like X-Forwarded-Host, X-Forwarded-Proto, and
X-Forwarded-Server.
- This enhancement allows emails to now include absolute URLs for the login
page, replacing the previous relative URLs.
> URL in registration mail is relative while it should be absolute
> -
>
> Key: JSPWIKI-1056
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1056
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication Authorization
>Affects Versions: 2.10.3
> Environment: Java 8
> Tomcat 8
> JSPWiki 2.10.3-git-27
>Reporter: Harry Metske
>Assignee: Harry Metske
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> After registering a new user with an email address, you get an email.
> This email used to contain a link to the login URL of your wiki, but after
> JSPWIKI-1035 this URL is relative.
> The relevant piece of code is :
> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/java/org/apache/wiki/auth/UserManager.java#L799
> What would be the most elegant way to get the absolute URL here ?
> Here's a stacktrace to that point:
> {noformat}
> at javax.mail.Transport.send(Transport.java:124)
> at org.apache.wiki.util.MailUtil.sendMessage(MailUtil.java:287)
> at
> org.apache.wiki.auth.UserManager$SaveUserProfileTask.execute(UserManager.java:801)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:763)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:678)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:86)
> at org.apache.wiki.auth.UserManager.setUserProfile(UserManager.java:366)
> at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:135)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:160)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:113)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.pro
[jira] [Commented] (JSPWIKI-1056) URL in registration mail is relative while it should be absolute
[
https://issues.apache.org/jira/browse/JSPWIKI-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17774171#comment-17774171
]
ASF subversion and git services commented on JSPWIKI-1056:
--
Commit 0cf7a04295746059f108d91d8edfc957eec7bea3 in jspwiki's branch
refs/heads/master from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=0cf7a0429 ]
Merge pull request #311 from arturobernalg/JSPWIKI-1056
JSPWIKI-1056: Add Absolute URL Utility Methods
> URL in registration mail is relative while it should be absolute
> -
>
> Key: JSPWIKI-1056
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1056
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication Authorization
>Affects Versions: 2.10.3
> Environment: Java 8
> Tomcat 8
> JSPWiki 2.10.3-git-27
>Reporter: Harry Metske
>Assignee: Harry Metske
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> After registering a new user with an email address, you get an email.
> This email used to contain a link to the login URL of your wiki, but after
> JSPWIKI-1035 this URL is relative.
> The relevant piece of code is :
> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/java/org/apache/wiki/auth/UserManager.java#L799
> What would be the most elegant way to get the absolute URL here ?
> Here's a stacktrace to that point:
> {noformat}
> at javax.mail.Transport.send(Transport.java:124)
> at org.apache.wiki.util.MailUtil.sendMessage(MailUtil.java:287)
> at
> org.apache.wiki.auth.UserManager$SaveUserProfileTask.execute(UserManager.java:801)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:763)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:678)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:86)
> at org.apache.wiki.auth.UserManager.setUserProfile(UserManager.java:366)
> at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:135)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:160)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:113)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at
> ja
[jira] [Resolved] (JSPWIKI-1056) URL in registration mail is relative while it should be absolute
[
https://issues.apache.org/jira/browse/JSPWIKI-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal resolved JSPWIKI-1056.
Resolution: Fixed
merge in master
> URL in registration mail is relative while it should be absolute
> -
>
> Key: JSPWIKI-1056
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1056
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication Authorization
>Affects Versions: 2.10.3
> Environment: Java 8
> Tomcat 8
> JSPWiki 2.10.3-git-27
>Reporter: Harry Metske
>Assignee: Harry Metske
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> After registering a new user with an email address, you get an email.
> This email used to contain a link to the login URL of your wiki, but after
> JSPWIKI-1035 this URL is relative.
> The relevant piece of code is :
> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/java/org/apache/wiki/auth/UserManager.java#L799
> What would be the most elegant way to get the absolute URL here ?
> Here's a stacktrace to that point:
> {noformat}
> at javax.mail.Transport.send(Transport.java:124)
> at org.apache.wiki.util.MailUtil.sendMessage(MailUtil.java:287)
> at
> org.apache.wiki.auth.UserManager$SaveUserProfileTask.execute(UserManager.java:801)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:763)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:678)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:86)
> at org.apache.wiki.auth.UserManager.setUserProfile(UserManager.java:366)
> at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:135)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:160)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:113)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1056) URL in registration mail is relative while it should be absolute
[
https://issues.apache.org/jira/browse/JSPWIKI-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal updated JSPWIKI-1056:
---
Fix Version/s: 2.12.2
> URL in registration mail is relative while it should be absolute
> -
>
> Key: JSPWIKI-1056
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1056
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication Authorization
>Affects Versions: 2.10.3
> Environment: Java 8
> Tomcat 8
> JSPWiki 2.10.3-git-27
>Reporter: Harry Metske
>Assignee: Harry Metske
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> After registering a new user with an email address, you get an email.
> This email used to contain a link to the login URL of your wiki, but after
> JSPWIKI-1035 this URL is relative.
> The relevant piece of code is :
> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/java/org/apache/wiki/auth/UserManager.java#L799
> What would be the most elegant way to get the absolute URL here ?
> Here's a stacktrace to that point:
> {noformat}
> at javax.mail.Transport.send(Transport.java:124)
> at org.apache.wiki.util.MailUtil.sendMessage(MailUtil.java:287)
> at
> org.apache.wiki.auth.UserManager$SaveUserProfileTask.execute(UserManager.java:801)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:763)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:678)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:86)
> at org.apache.wiki.auth.UserManager.setUserProfile(UserManager.java:366)
> at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:135)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:160)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:113)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1182) Reorder and Rename i18n Literals According to Usage Context
[ https://issues.apache.org/jira/browse/JSPWIKI-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-1182: --- Fix Version/s: 2.12.2 > Reorder and Rename i18n Literals According to Usage Context > --- > > Key: JSPWIKI-1182 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1182 > Project: JSPWiki > Issue Type: Improvement >Affects Versions: 2.12.1 >Reporter: Arturo Bernal >Priority: Minor > Fix For: 2.12.2 > > > In the recent pull request addressing missing i18n literals (JSPWIKI-925), it > was noted that the literals are not in alphabetical order. Additionally, the > current ordering loosely follows the order of JSPs, which may not be the most > intuitive way to manage them. > This ticket aims to address the following: > # Reorder the i18n literals alphabetically or according to a more logical or > intuitive scheme. > # Consider renaming the literals to better reflect where they are being used > in the application. > By tackling these issues in a separate ticket, we can maintain a cleaner, > more organized codebase and make it easier for contributors to locate and > manage i18n literals in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JSPWIKI-1182) Reorder and Rename i18n Literals According to Usage Context
Arturo Bernal created JSPWIKI-1182: -- Summary: Reorder and Rename i18n Literals According to Usage Context Key: JSPWIKI-1182 URL: https://issues.apache.org/jira/browse/JSPWIKI-1182 Project: JSPWiki Issue Type: Improvement Reporter: Arturo Bernal In the recent pull request addressing missing i18n literals (JSPWIKI-925), it was noted that the literals are not in alphabetical order. Additionally, the current ordering loosely follows the order of JSPs, which may not be the most intuitive way to manage them. This ticket aims to address the following: # Reorder the i18n literals alphabetically or according to a more logical or intuitive scheme. # Consider renaming the literals to better reflect where they are being used in the application. By tackling these issues in a separate ticket, we can maintain a cleaner, more organized codebase and make it easier for contributors to locate and manage i18n literals in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1182) Reorder and Rename i18n Literals According to Usage Context
[ https://issues.apache.org/jira/browse/JSPWIKI-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-1182: --- Affects Version/s: 2.12.1 > Reorder and Rename i18n Literals According to Usage Context > --- > > Key: JSPWIKI-1182 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1182 > Project: JSPWiki > Issue Type: Improvement >Affects Versions: 2.12.1 >Reporter: Arturo Bernal >Priority: Minor > > In the recent pull request addressing missing i18n literals (JSPWIKI-925), it > was noted that the literals are not in alphabetical order. Additionally, the > current ordering loosely follows the order of JSPs, which may not be the most > intuitive way to manage them. > This ticket aims to address the following: > # Reorder the i18n literals alphabetically or according to a more logical or > intuitive scheme. > # Consider renaming the literals to better reflect where they are being used > in the application. > By tackling these issues in a separate ticket, we can maintain a cleaner, > more organized codebase and make it easier for contributors to locate and > manage i18n literals in the future. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-925) Missing i18n resources
[ https://issues.apache.org/jira/browse/JSPWIKI-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated JSPWIKI-925: --- Labels: pull-request-available (was: ) > Missing i18n resources > -- > > Key: JSPWIKI-925 > URL: https://issues.apache.org/jira/browse/JSPWIKI-925 > Project: JSPWiki > Issue Type: Task > Components: Localization >Reporter: Juan Pablo Santos Rodríguez >Assignee: Arturo Bernal >Priority: Major > Labels: pull-request-available > > Between 2.10.1 and current trunk, a number of i18n literals have been > introduced; it would be nice to have them translated for 2.10.2 > Specifically: > * de > ** /CoreResources_de.properties: 1 entry missing > ** /templates/default_de.properties: 32 entries missing, 1 outdated > * fi > ** /CoreResources_fi.properties: 4 entries missing > ** /templates/default_fi.properties: 35 entries missing, 1 outdated > * fr > ** /CoreResources_fr.properties: 1 entry missing > ** /templates/default_fr.properties: 32 entries missing, 1 outdated > * it > ** /CoreResources_it.properties: 1 entry missing > ** /templates/default_it.properties: 32 entries missing, 1 outdated > * nl > ** /templates/default_nl.properties: 2 entries missing > * pt_BR > ** /CoreResources_pt_BR.properties: 1 entry missing > ** /templates/default_pt_BR.properties: 192 entries missing > * ru > ** /CoreResources_ru.properties: 1 entry missing > ** /templates/default_ru.properties: 32 entries missing, 1 outdated > * zh_CN > ** /CoreResources_zh_CN.properties: 1 entry missing > ** /templates/default_zh_CN.properties: 32 entries missing, 1 outdated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-925) Missing i18n resources
[ https://issues.apache.org/jira/browse/JSPWIKI-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-925: -- Assignee: Arturo Bernal > Missing i18n resources > -- > > Key: JSPWIKI-925 > URL: https://issues.apache.org/jira/browse/JSPWIKI-925 > Project: JSPWiki > Issue Type: Task > Components: Localization >Reporter: Juan Pablo Santos Rodríguez >Assignee: Arturo Bernal >Priority: Major > > Between 2.10.1 and current trunk, a number of i18n literals have been > introduced; it would be nice to have them translated for 2.10.2 > Specifically: > * de > ** /CoreResources_de.properties: 1 entry missing > ** /templates/default_de.properties: 32 entries missing, 1 outdated > * fi > ** /CoreResources_fi.properties: 4 entries missing > ** /templates/default_fi.properties: 35 entries missing, 1 outdated > * fr > ** /CoreResources_fr.properties: 1 entry missing > ** /templates/default_fr.properties: 32 entries missing, 1 outdated > * it > ** /CoreResources_it.properties: 1 entry missing > ** /templates/default_it.properties: 32 entries missing, 1 outdated > * nl > ** /templates/default_nl.properties: 2 entries missing > * pt_BR > ** /CoreResources_pt_BR.properties: 1 entry missing > ** /templates/default_pt_BR.properties: 192 entries missing > * ru > ** /CoreResources_ru.properties: 1 entry missing > ** /templates/default_ru.properties: 32 entries missing, 1 outdated > * zh_CN > ** /CoreResources_zh_CN.properties: 1 entry missing > ** /templates/default_zh_CN.properties: 32 entries missing, 1 outdated -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1056) URL in registration mail is relative while it should be absolute
[
https://issues.apache.org/jira/browse/JSPWIKI-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771253#comment-17771253
]
Arturo Bernal commented on JSPWIKI-1056:
Hi [~metskem]
I've submitted a pull request that aims to resolve this issue. The PR
introduces utility methods in `HttpUtil` for generating absolute URLs. These
methods are particularly useful for sending absolute URLs in email
notifications, as opposed to the relative URLs that are currently being sent.
I would appreciate your feedback on this proposed fix.
Best regards,
Arturo
[https://github.com/apache/jspwiki/pull/311]
> URL in registration mail is relative while it should be absolute
> -
>
> Key: JSPWIKI-1056
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1056
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication Authorization
>Affects Versions: 2.10.3
> Environment: Java 8
> Tomcat 8
> JSPWiki 2.10.3-git-27
>Reporter: Harry Metske
>Assignee: Harry Metske
>Priority: Major
> Labels: pull-request-available
>
> After registering a new user with an email address, you get an email.
> This email used to contain a link to the login URL of your wiki, but after
> JSPWIKI-1035 this URL is relative.
> The relevant piece of code is :
> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/java/org/apache/wiki/auth/UserManager.java#L799
> What would be the most elegant way to get the absolute URL here ?
> Here's a stacktrace to that point:
> {noformat}
> at javax.mail.Transport.send(Transport.java:124)
> at org.apache.wiki.util.MailUtil.sendMessage(MailUtil.java:287)
> at
> org.apache.wiki.auth.UserManager$SaveUserProfileTask.execute(UserManager.java:801)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:763)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:678)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:86)
> at org.apache.wiki.auth.UserManager.setUserProfile(UserManager.java:366)
> at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:135)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:160)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:113)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
> at
> org.apache.tomcat.
[jira] [Updated] (JSPWIKI-1056) URL in registration mail is relative while it should be absolute
[
https://issues.apache.org/jira/browse/JSPWIKI-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated JSPWIKI-1056:
Labels: pull-request-available (was: )
> URL in registration mail is relative while it should be absolute
> -
>
> Key: JSPWIKI-1056
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1056
> Project: JSPWiki
> Issue Type: Bug
> Components: Authentication Authorization
>Affects Versions: 2.10.3
> Environment: Java 8
> Tomcat 8
> JSPWiki 2.10.3-git-27
>Reporter: Harry Metske
>Assignee: Harry Metske
>Priority: Major
> Labels: pull-request-available
>
> After registering a new user with an email address, you get an email.
> This email used to contain a link to the login URL of your wiki, but after
> JSPWIKI-1035 this URL is relative.
> The relevant piece of code is :
> https://github.com/apache/jspwiki/blob/master/jspwiki-war/src/main/java/org/apache/wiki/auth/UserManager.java#L799
> What would be the most elegant way to get the absolute URL here ?
> Here's a stacktrace to that point:
> {noformat}
> at javax.mail.Transport.send(Transport.java:124)
> at org.apache.wiki.util.MailUtil.sendMessage(MailUtil.java:287)
> at
> org.apache.wiki.auth.UserManager$SaveUserProfileTask.execute(UserManager.java:801)
> at
> org.apache.wiki.workflow.Workflow.processCurrentStep(Workflow.java:763)
> at org.apache.wiki.workflow.Workflow.start(Workflow.java:678)
> at
> org.apache.wiki.workflow.WorkflowManager.start(WorkflowManager.java:86)
> at org.apache.wiki.auth.UserManager.setUserProfile(UserManager.java:366)
> at org.apache.jsp.Login_jsp._jspService(Login_jsp.java:135)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.wiki.ui.WikiServletFilter.doFilter(WikiServletFilter.java:160)
> at org.apache.wiki.ui.WikiJSPFilter.doFilter(WikiJSPFilter.java:113)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)
> at
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal resolved JSPWIKI-1181.
Resolution: Fixed
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771048#comment-17771048
]
ASF subversion and git services commented on JSPWIKI-1181:
--
Commit 41f558601531150ca885692047623822a3a0bbdc in jspwiki's branch
refs/heads/master from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=41f558601 ]
Merge pull request #310 from arturobernalg/JSPWIKI-1181
JSPWIKI-1181 - Fix: Correct URL Generation for Pages with Special Characters
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771047#comment-17771047
]
ASF subversion and git services commented on JSPWIKI-1181:
--
Commit 96d54b732487d71611ce9622d22e015fa6a24558 in jspwiki's branch
refs/heads/master from Arturo Bernal
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=96d54b732 ]
JSPWIKI-1181 - Fix: Correct URL generation for pages with special characters
The cleanPageName function has been updated to correctly handle the '/'
character, resolving the issue where URLs for search results in quick
navigation were incorrectly generated.
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771028#comment-17771028
]
Ulf Dittmer commented on JSPWIKI-1181:
--
Yes, that fix works just as well.
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal updated JSPWIKI-1167: --- Fix Version/s: 2.12.2 > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > Fix For: 2.12.2 > > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arturo Bernal resolved JSPWIKI-1167. Resolution: Fixed > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > Fix For: 2.12.2 > > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal updated JSPWIKI-1181:
---
Fix Version/s: 2.12.2
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
> Fix For: 2.12.2
>
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arturo Bernal updated JSPWIKI-1181:
---
Assignee: Arturo Bernal
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770888#comment-17770888
]
Arturo Bernal commented on JSPWIKI-1181:
[~brushed]
done
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
> Labels: pull-request-available
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770879#comment-17770879
]
Ulf Dittmer commented on JSPWIKI-1181:
--
The fix works for my case, thank you!
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
> Labels: pull-request-available
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770865#comment-17770865
]
Dirk Frederickx commented on JSPWIKI-1181:
--
@Arthur,
Actually, it would be better to fix the cleanPageName() function. It
incorrectly removes the "/" character.
dirk
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
> Labels: pull-request-available
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17770858#comment-17770858
]
Arturo Bernal commented on JSPWIKI-1181:
[~udittmer] pelase take a look
[https://github.com/apache/jspwiki/pull/310]
I've identified the issue with the URL generation for pages with special
characters. The problem was in the `toUrl` function, which didn't account for
special characters like '/'. I've updated this function to handle such cases
correctly, ensuring that the generated URLs are both accurate and functional.
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
> Labels: pull-request-available
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1181) Search popup does not handle attachments correctly
[
https://issues.apache.org/jira/browse/JSPWIKI-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated JSPWIKI-1181:
Labels: pull-request-available (was: )
> Search popup does not handle attachments correctly
> --
>
> Key: JSPWIKI-1181
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1181
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.12.1
>Reporter: Ulf Dittmer
>Priority: Minor
> Labels: pull-request-available
>
> If a search finds an attachment, that is not rendered correctly in the search
> popup. A JavaScript error happens (see below), and the link to the attachment
> is broken. This can be seen on [https://jspwiki-wiki.apache.org/] when
> searching for 'pdf' for the result "Pic/pdf.png".
> {quote}XML Parsing Error: syntax error Location:
> [https://jspwiki-wiki.apache.org/ajax/search/pages] Line Number 1, Column 1
> {quote}
> When bringing up the full search page, this is handled correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763935#comment-17763935 ] Arturo Bernal commented on JSPWIKI-1167: Hi [~brushed] Can we conclude this issue, don't you think? Thanks you. > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1178) Deadlock with Java Virtual Threads
[
https://issues.apache.org/jira/browse/JSPWIKI-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated JSPWIKI-1178:
Labels: pull-request-available (was: )
> Deadlock with Java Virtual Threads
> --
>
> Key: JSPWIKI-1178
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1178
> Project: JSPWiki
> Issue Type: Improvement
>Reporter: Arturo Bernal
>Assignee: Arturo Bernal
>Priority: Minor
> Labels: pull-request-available
>
> With the upcoming release of JDK 21, it's anticipated that a new feature
> called "Virtual Threads" will be included. This feature may introduce a
> potential deadlock issue in JSPWiki application, particularly when blocking
> operations occur within {{synchronized}} blocks/methods. In such cases, the
> platform thread associated with a virtual thread may become "pinned" and
> unavailable to execute other virtual threads.
> This ticket aims to:
> # Investigate if and how the JSPWiki application might be affected by this
> change in JDK 21's Virtual Threads.
> # If found to be at risk of the aforementioned deadlock situation, propose
> and implement changes to address this issue, ensuring the application's
> stability and performance aren't compromised.
> *Steps to Reproduce:*
> While this issue isn't currently reproducible as JDK 21 hasn't been released
> yet, potential risk areas in the application code can be identified by
> looking for {{synchronized}} blocks/methods that contain blocking operations.
> *Suggested Actions:*
> # Conduct an audit of the ScanPro application's source code to identify any
> {{synchronized}} blocks/methods that may contain blocking operations.
> # Analyze the potential impact of the "Virtual Threads" feature on these
> code segments.
> # If a risk of deadlock is identified, explore alternative solutions or
> workarounds. This could involve refactoring the code, using different
> concurrency controls, or adjusting the usage of resources.
> # Test these changes thoroughly in a controlled environment before deploying
> them to production.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763368#comment-17763368 ] ASF subversion and git services commented on JSPWIKI-1167: -- Commit 86da49709738694a54a98bfdab0ce07ecd822166 in jspwiki's branch refs/heads/master from brushed [ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=86da49709 ] [JSPWIKI-1167] prettify line numbering is wrong with longer lines Prettified code lines should not wrap around, to avoid mismatch with line numbering. > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[
https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763367#comment-17763367
]
Dirk Frederickx commented on JSPWIKI-1167:
--
Dietrich,
Thx for highlighting the issue.
Prettified code lines should not wrap around, to avoid mismatch with the line
numbering.
A fix will be pushed.
You can correct this on your current jspwiki site by adding the following to
the LeftMenu page :
{code:language=css}
%%add-css
.prettyprint code { white-space: inherit; }
/%
{code}
> prettify: line numbering is wrong with longer lines
> ---
>
> Key: JSPWIKI-1167
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1167
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.11.0
>Reporter: Dietrich Schmidt
>Assignee: Dirk Frederickx
>Priority: Major
> Attachments: jspwiki-Zeilennummern-im-Editor.png,
> jspwiki-Zeilennummern.png
>
>
> with %%prettify, line numbering is shown. With a line longer than textsize,
> the line is split in two lines and the line numbering becomes wrong.
> See Attachment. !langezeile.png!
> It looks like attaching an image does not work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dirk Frederickx updated JSPWIKI-1167: - Assignee: Dirk Frederickx > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Assignee: Dirk Frederickx >Priority: Major > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1165) long text in monospace font inside {{}} is shown without scroll bar
[
https://issues.apache.org/jira/browse/JSPWIKI-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763349#comment-17763349
]
ASF subversion and git services commented on JSPWIKI-1165:
--
Commit 3a732365a034e6b01374ab6fe499c532e5a0df7e in jspwiki's branch
refs/heads/master from brushed
[ https://gitbox.apache.org/repos/asf?p=jspwiki.git;h=3a732365a ]
[JSPWIKI-1165] wrap long inline preformatted text
Fix text wrapping for long inline preformatted texts
> long text in monospace font inside {{}} is shown without scroll bar
> ---
>
> Key: JSPWIKI-1165
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1165
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.11.0
> Environment: {color:#172b4d}Tested under Windows with tomcat 9.0.55
> and Fedora Linux with Wildfly 21.{color}
>Reporter: Dietrich Schmidt
>Assignee: Dirk Frederickx
>Priority: Major
> Attachments: Screenshot 2023-08-28 at 21.16.53.png,
> jspwiki-Anzeige.png, jspwiki-bearbeiten.png
>
>
> A long text inside \{ { ... } } is neither broken in several lines nor a
> horizontal scroll bar is displayed.
> Thus parts of the text are not visible.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1165) long text in monospace font inside {{}} is shown without scroll bar
[
https://issues.apache.org/jira/browse/JSPWIKI-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763345#comment-17763345
]
Dirk Frederickx commented on JSPWIKI-1165:
--
Dietrich,
Indeed, you are correct.
The issue actual only occurs when adding preformatted INLINE text. (with 2 "{"
curly braces )
(I was only looking at the reformatted BLOCK text with 3 "{" curly braced ,
which does show a scrollbar)
An update to the css is needed for this.
It will make sure that inline preformatted text will wrap as necessary, and
stay within the width of the line boxes.
Temporary you can fix the issue on your existing jspwiki site by adding the
following snippet to your LeftMenu wikipage :
{code:css}
%%add-css
tt { white-space:pre-wrap;}
/%
{code}
KR
dirk
> long text in monospace font inside {{}} is shown without scroll bar
> ---
>
> Key: JSPWIKI-1165
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1165
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.11.0
> Environment: {color:#172b4d}Tested under Windows with tomcat 9.0.55
> and Fedora Linux with Wildfly 21.{color}
>Reporter: Dietrich Schmidt
>Assignee: Dirk Frederickx
>Priority: Major
> Attachments: Screenshot 2023-08-28 at 21.16.53.png,
> jspwiki-Anzeige.png, jspwiki-bearbeiten.png
>
>
> A long text inside \{ { ... } } is neither broken in several lines nor a
> horizontal scroll bar is displayed.
> Thus parts of the text are not visible.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762762#comment-17762762 ] Dietrich Schmidt commented on JSPWIKI-1167: --- Example of wrong line numbers added a attachment: jspwiki-Zeilennummern.png shows the wiki page jspwiki-Zeilennummern-im-Editor.png shows the Editor with preview. > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Priority: Major > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dietrich Schmidt updated JSPWIKI-1167: -- Attachment: jspwiki-Zeilennummern.png > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Priority: Major > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1165) long text in monospace font inside {{}} is shown without scroll bar
[
https://issues.apache.org/jira/browse/JSPWIKI-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dietrich Schmidt updated JSPWIKI-1165:
--
Attachment: jspwiki-Zeilennummern.png
> long text in monospace font inside {{}} is shown without scroll bar
> ---
>
> Key: JSPWIKI-1165
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1165
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.11.0
> Environment: {color:#172b4d}Tested under Windows with tomcat 9.0.55
> and Fedora Linux with Wildfly 21.{color}
>Reporter: Dietrich Schmidt
>Assignee: Dirk Frederickx
>Priority: Major
> Attachments: Screenshot 2023-08-28 at 21.16.53.png,
> jspwiki-Anzeige.png, jspwiki-bearbeiten.png
>
>
> A long text inside \{ { ... } } is neither broken in several lines nor a
> horizontal scroll bar is displayed.
> Thus parts of the text are not visible.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1165) long text in monospace font inside {{}} is shown without scroll bar
[
https://issues.apache.org/jira/browse/JSPWIKI-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dietrich Schmidt updated JSPWIKI-1165:
--
Attachment: (was: jspwiki-Zeilennummern.png)
> long text in monospace font inside {{}} is shown without scroll bar
> ---
>
> Key: JSPWIKI-1165
> URL: https://issues.apache.org/jira/browse/JSPWIKI-1165
> Project: JSPWiki
> Issue Type: Bug
> Components: Templates and UI
>Affects Versions: 2.11.0
> Environment: {color:#172b4d}Tested under Windows with tomcat 9.0.55
> and Fedora Linux with Wildfly 21.{color}
>Reporter: Dietrich Schmidt
>Assignee: Dirk Frederickx
>Priority: Major
> Attachments: Screenshot 2023-08-28 at 21.16.53.png,
> jspwiki-Anzeige.png, jspwiki-bearbeiten.png
>
>
> A long text inside \{ { ... } } is neither broken in several lines nor a
> horizontal scroll bar is displayed.
> Thus parts of the text are not visible.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JSPWIKI-1167) prettify: line numbering is wrong with longer lines
[ https://issues.apache.org/jira/browse/JSPWIKI-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dietrich Schmidt updated JSPWIKI-1167: -- Attachment: jspwiki-Zeilennummern-im-Editor.png > prettify: line numbering is wrong with longer lines > --- > > Key: JSPWIKI-1167 > URL: https://issues.apache.org/jira/browse/JSPWIKI-1167 > Project: JSPWiki > Issue Type: Bug > Components: Templates and UI >Affects Versions: 2.11.0 >Reporter: Dietrich Schmidt >Priority: Major > Attachments: jspwiki-Zeilennummern-im-Editor.png, > jspwiki-Zeilennummern.png > > > with %%prettify, line numbering is shown. With a line longer than textsize, > the line is split in two lines and the line numbering becomes wrong. > See Attachment. !langezeile.png! > It looks like attaching an image does not work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
