Disable RestXqTrigger in collection configuration

[dizzzz]

Comment out RestXqTrigger configuration in collection.xconf.init

[joewiz]

LGTM, and documentation-wise, we could perhaps add a sentence to https://exist-db.org/exist/apps/doc/xquery#restxq (source at https://github.com/eXist-db/documentation/blob/master/src/main/xar-resources/data/xquery/xquery.xml#L1069-L1083) to say:

To enable RESTXQ support for a collection and its descendant collections, ensure your collection configuration file (e.g., collection.xconf) has a <trigger> element matching the structure of the following template:

<collection xmlns="http://exist-db.org/collection-config/1.0">
    <triggers>
        <trigger class="org.exist.extensions.exquery.restxq.impl.RestXqTrigger"/>
    </triggers>
</collection>

[duncdrum]

We need to adjust the restxq test for the containers.

[adamretter]

Guys, just to check that - you realise of course that that will break soooo many people's apps when they upgrade to eXist-db 7?

[line-o]

We are aware that this is a breaking change. There is however a clear and easy to document way to either

• re-enable it instance-wide by uncommenting the trigger in collection.xconf in /db/system/config/db or
• adding the trigger to any application package that uses restxq annotations

[adamretter]

We are aware that this is a breaking change.

Okay, good.

Out of interest - what is the perceived advantage(s) of disabling it by default?

[dizzzz]

I expect apps mostly to have their own collection.xconf anyway, effectively voiding the definition on toplevel.

So I think the impact is little.

[adamretter]

@dizzzz That's not what I have often seen in the wild.

Do you know what is the perceived advantage(s) of disabling it by default?

[chakl]

@adamretter perceived advantage(s)

(more) secure by default.

If an apps wants to expose the REST API, it must explicitly state that. No good reason to expose it for all apps on the host.

[adamretter]

(more) secure by default.

@chakl Do you mean - Disabling this API helps reduce the external attack service?

If so, I think you can find many bigger fish to fry, e.g.: the RESTServer which exposes the entire database by default to the guest user.

[dizzzz]

The one does not exclude the other....

[chakl]

@chakl Do you mean - Disabling this API helps reduce the external attack service?

Exactly. Disabling unused APIs reduces attack surface.

If so, I think you can find many bigger fish to fry, e.g.: the RESTServer which exposes the entire database by default to the guest user.

Agree. We (with my existsolutions.com hat on) have gone to the habit of recommending to deploy reverse proxies in front of Internet facing eXist-db systems, in order to address this and other issues. But perfectly reasonable to disable that by default in eXist-db as well.