Allow to access to XWikiPreferences properties in REST with guest

Right now the XWiki.XWikiPreferences page has view rights only for Admin users: this means we cannot access its property values using a REST call.

This is limiting in cases where we need to know some property values in our Javascript: right now we rely on script services with velocity to access such values, but it leads to various bugs because of the browser cache. For example we have Loading... related to this kind of bug.

In order to solve this bug, and to allow new Javascript features (e.g. to activate some features based on preferences) I suggest that we allow to access some XWikiPreferences properties with REST by guest user. We could for example create a whitelist of properties that are allowed to be accessed through REST calls.

JIRA issue available there: Loading...


<brainstorming mode - haven’t thought enough about this>
At the very generic level, the best IMO is to have a proper API to access configuration properties, i.e separate access (API) from implementation (stored in a xobject). That’s one reason why we introduced ConfigurationSource in Java. We could want something similar for REST APIs but also for scripts. For scripts, we almost have it, by exposing new script API for returning the values of ConfigurationSource.

Now at the level of xproperties, the generic idea would be to allow setting permissions on xobjects or xproperties. Right now we can only set permissions for DOCUMENT entities. We could imagine allowing to set permissions for other entity types (OBJECT, PROPERTY, or even ATTACHMENTs). That would make the model more complex but would also solve existing bugs/limitations generically (like the one where we use should require some permissions to be add an XObject of type XWikiRights - We fixed it in a specific way AFAIK but not generically and the generic issue is still open).

It’s possible it’s too complex. In this case, using a configuration API would allow to set permissions just for configuration items. But it seems not generic enough to me.
<brainstorming mode - haven’t thought enough about this>

Note: I understand that any of the things I discussed above are complex and not in your timeframe. But as always, I’d like that we agree first about the direction we’d like to take and then we can introduce some temporary shortcuts/hacks and document them before we’re ready to implement it properly.

Well, I thought about that one: it would be indeed the right thing to do for this particular case. Now it would need rights at a very fine grained level (xproperties), and I really wonder if there would be other usecases?
And I’m really afraid that it would make the right system really complex to configure properly.

the best IMO is to have a proper API to access configuration properties, i.e separate access (API) from implementation (stored in a xobject)

one simple way to push towards this direction is to create a dedicated REST endpoint for the configuration properties: internally we can use whatever we want and tweaks the rights as we need, and externally it would expose it as a dedicated API as you suggest. WDYT?

I commented on both issues. XWIKI-16946 doesn’t feel right to me, and I don’t think it blocks XWIKI-16809 for which there are easier / cleaner fixes IMO.

Thanks for your feedback on XWIKI-16809 @mflorea and the guideline to fix it, it really helps :slight_smile:

Now, even if it’s indeed possible to fix this issue as you proposed, I personally don’t feel it’s natural or cleaner approach: looks a bit overly complicated to need each time to call a specific URL to get a .vm that checks some conditions to get the right html. Compared to call a single REST URL with the property name you want to check.

But really it’s a feeling, I don’t have proof or other real usecases that shows it, so I will fix XWIKI-16809 as you suggested, but the proposal here remains.