Groovy class syntax can cause compatibility issue with extension "Wiki Link URL Normalizer"

[oanat]

Noticed the following issue on a wiki using XS 10.11.8 (did not manage to reproduce locally):

• Install the Office365 application v1.5.
• Install the extension https://extensions.xwiki.org/xwiki/bin/view/Extension/WikiLinkURLNormalizer/
• create a wiki page and add the Office365 macro

Results:

• The wiki page displays an error
  {{Failed to execute the [groovy] macro. Cause: [startup failed: script15992051810231037558333.groovy: 169: expecting ')', found '~' @ line 169, column 12. ~|| request.getParameterMap().containsKey(AZURE_PARAM_ID_TOKEN) ^ 1 error ]. Click on this message for details.}}
• the Groovy class http://myserver/xwiki/bin/view/Office365/Groovy page contains an escaped line that cannot be removed upon save (editing the page and removing the line does not work, the "~" is kept after the save):
  def containsAuthenticationData(request) { def map = request.getParameterMap(); return request.getMethod().equalsIgnoreCase("POST") && (request.getParameterMap().containsKey(AZURE_PARAM_ERROR) ~|| request.getParameterMap().containsKey(AZURE_PARAM_ID_TOKEN) ~|| request.getParameterMap().containsKey(AZURE_PARAM_CODE)); }

Expected result: the Office365 macro is displayed without error

[oanat]

Workaround for this issue:

• manually sent the page syntax for the Groovy class to "plain 1.0":

[polx]

Considering that this workaround has nothing to do with the application (i.e. the application can't do anything about it probably), I suggest we ask the advice of some persons that has an access to where this happened. I think that looking at the DB is the necessary thing.
The syntax has nothing to do with the execution of the groovy page and I suppose something else is happening.
thanks

Paul

[oanat]

@polx AFAIU the "xwiki 2.1" syntax triggers an event listener from the "Wiki Link URL Normalizer" extension which adds the escaping, maybe @mflorea can offer more technical details since they encountered a similar issue for xwiki.org.

[mflorea]

@polx no, this is a bug in the Office365 application: it should not mark with the XWiki 2.1 syntax the wiki pages that are not expected to contain XWiki 2.1 syntax. In this case the Office365.Groovy page is clearly not supposed to contain wiki syntax but only Groovy code, for which the most appropriate syntax we have available is Plain 1.0 (NOTE: don't mistaken this with a wiki page that uses the Groovy rendering macro; there you have wiki syntax but in this case you don't have the Groovy macro, it's just the Groovy code). Otherwise you will get into trouble when code in platform (back-links, refactoring, link checker etc.) or contributed extensions (URL normalizer) are going to analyze and process those wiki pages using the wiki syntax they indicate: XWiki 2.1.

[polx]

is it ok even if the syntax is not supported in the wiki?

[mflorea]

Plain 1.0 syntax is supported (bundled in XWiki Standard as core extension). You don't see it in the drop down list because there's a blacklist in the Administration that excludes it, probably because we considered it too technical. Basically the administrator can choose which syntaxes to list to the end user, because many syntaxes are quite technical, not to be used by the end users when creating new wiki pages.

[polx]

Mmmmh, let me understand a bit deeper because this is new to me and definitely happens in other places too: The content may be changed if the syntax is recognized as something that can be manipulated and some automatic processing happens such as moving a page with an actualisation of all links to this page.
Right?

In this case, only plain/1.0 is likely to be safe since it cannot be supposed to contain links.
Right?

At least Google Apps and Office365 are then touched. Probably any that uses parseGroovyFromPage.

[mflorea]

3 x Yes :)

[polx]

Thanks. This should be spread somehow. I searched a bit for parseGroovyFromPage on GitHub and there's hundreds of them. All of them may be affected.

[polx]

Version 1.6 is released with this issue resolved.
I am closing this issue but I think we should remind this and maybe walk around the world to announce this fragility.