Ver 17.0 changes in https negotiation

[whyme]

I have a set of files that are validated by means of calls to raw XML files on a github server, in the form, e.g., of document($filename) and document-available($filename) where $filename = 'https://raw.githubusercontent.com/[USER ... [FILE].xml'

In oXygen 16.1 I had no problems in validation. (And I just retested on 16.1 to confirm.) But in 17.1 I'm getting false() for document-available($filename), and therefore document($filename) doesn't work either.

What do I do to restore the behavior I had in ver. 16.1? Or am I missing something obvious?

[adrian]

Hi,

You're referring to doc-available(), right?
If the document is not XML well formed, doc-available() will return false. If the file is indeed there and it looks XML-well formed, the problem may be a DTD referred by the XML that's unavailable in that context.
So, check your XML file in Oxygen 17.1 first. Use File > Open URL and paste there your URI (the one from $filename). This test should also indicate if there are other things that cause the problem (e.g. a missing XML catalog).

e.g. For testing

Code: Select all

doc-available('https://raw.githubusercontent.com/oxygenxml/userguide/master/DITA/UserManual.ditamap')

=> true (well formed XML file)

Code: Select all

doc-available('https://raw.githubusercontent.com/oxygenxml/userguide/master/DITA/README.txt')

=> false (it's there, just not an XML file)

Regards,
Adrian

[whyme]

OK, I've isolated the problem to schematron. An XML file whose prolog invokes a simple schematron file with the following...

Code: Select all

   <sch:pattern>

        <sch:rule context="/*">

            <sch:assert test="doc-available('https://raw.githubusercontent.com/oxygenxml/userguide/master/DITA/UserManual.ditamap')">File must be available</sch:assert>

        </sch:rule>

    </sch:pattern>

...returns invalid. (But doing the doc-available() command outside the Schematron context works fine, as you've noted.)

[adrian]

Hi,

There are some security measures introduced in v17.1 that prevent remote resources from being accessed from any random Schematron.
What's New in oXygen XML Editor 17.1 - Improved Security

We took proactive steps to improve the overall oXygen security. We limited the execution of all the oXygen customizations that are not deployed in a framework or plugin directory.

A simple solution is to place that Schematron file within the Oxygen 'frameworks' folder. If you already have a custom framework, you can use that instead.

The alternative is to disable the security measures in Oxygen with a startup flag (JVM option).

Code: Select all

-Dcom.oxygenxml.disable.security=true

This can be added on a new line to the corresponding .vmoptions file (oxygen17.1.vmoptions for Editor, oxygenAuthor17.1.vmoptions for Author) from the Oxygen installation folder.

Regards,
Adrian

[whyme]

Thanks, Adrian. Those pointers are very helpful.

I anticipate the schemas may be used by people outside the context of a framework. So here's one more workaround for those who might stumble on this thread. Use the fn:doc-available() function in the Schematron file to generate a warning and prevent any further use of the URL (especially those using fn:doc(), which will prove fatal). The following example presumes some $resolved-URL that is a string containing a resolved URL via fn:resolve-uri():

Code: Select all

<report role="warning" test="doc-available($resolved-URL) = false()">URL refers to a file that is either

         (1) not available, (2) not valid XML, or (3) at a server not trusted by the validation engine.

</report>

[alex_jitianu]

Hi everyone,

I just wanted to let you know that the latest Oxygen 17.1 build (2016032212) contains the fix to the issue reported on this thread. When you have a Schematron file located outside a framework context and that Schemtron makes connection to remote resources, the user will now be presented with a dialog that requests his approval for making that connection. One can avoid the user interaction if the host to which the Schematron connects to is added in the Trusted Hosts preferences page.

Best regards,
Alex