tag suggest feature does not work if Main.WebHome is not saved with programming rights.

This is due to a

.getPropertyClass()

in suggest.vm, which require programming access level, evaluated against the context document, which is always Main.WebHome for the tags suggest AJAX calls

I can reproduce it on trunk (XE 2.2RC1 in development). This looks like a serious bug especially since users are supposed to modify the home page...

This issue is not very easy to fix.

I think the best move is to rewrite suggest.vm so that suggestions are retrieved from a service API instead of velocity code, and the template then just outputs the retrieved suggestions in JSON or XML

I propose another approach for now : introducing a XWiki.Suggestions document (with a object of class XWiki.RequiredRightClass w/ level programming) and hit that document instead of Main.WebHome everywhere suggesting tags with xpage=suggest.vm

There is much easier solution IMO. Why is it needed to have programming right to find tags ? I don't see what is the security issue, simply add a public API which is taking care of the search and use it in the velocity.

Any dev who could work on this "critical" issue? It would be nice to have it fixed for 4.2M1...

Note that there is a REST resource which provide tags (org.xwiki.rest.resources.tags.TagsResource). We should probably make it accept a filter parameter and use it in the ajax call.

Actually, XWIKI-8686 seems to solve the problem for only one specific usecase, namely when the suggest.vm is the one in the /templates/ folder. However, suggest.vm can be overwritten in a couple of places, namely in a skin in a wiki page or in a skin on the filesystem. In those cases, the priviledged renderer will not be invoked and the PR will continue to be needed for Main.WebHome so that it works (note that I haven't tested, just looked at the solution).

I'm having doubts about re-opening this issue (since this kind of customization is part of XWiki's API) or opening a new issue saying that well, works by default but if you customize it it doesn't anymore.

This particular issue is about tag suggest being broken, and XWIKI-8686 does solve this. I intentionally only used the PrivilegedTemplateRenderer only for templates located in /templates/. It would definitely be possible to use it on all templates located on the file system, but I do not see the need at the moment. In the feature-authorization-context branch, template overrides in wiki pages can have programming rights delegated to them by saving the corresponding wiki page with programming rights. (This is not possible in the master branch.)

Strictly speaking, the file system templates are part of the core system and is therefore "trusted code" which may have access to the privileged api. So, enabling programming rights for all file system templates would be possible. But from a security point of view it is better to maintain a small list of privileged templates and review these with extra care.

This particular issue is about tag suggest being broken, and XWIKI-8686 does solve this.

It doesn't solve it for all cases. As soon as you put a customized suggest.vm in a skin on the file system or in a wiki page, it breaks again. As I said before, I consider this to be a bug and not a "you're doing unexpected things so it's normal to fail" because this customization is part of XWiki's features, so tags have to work even if there is a customization. Do you agree that this bug is incompletely fixed because of this failure on customization?

In the feature-authorization-context branch, template overrides in wiki pages can have programming rights delegated to them by saving the corresponding wiki page with programming rights. (This is not possible in the master branch.)

This is great indeed. But to me it still means that, until that branch is merged, this issue is not completely fixed.

Strictly speaking, the file system templates are part of the core system and is therefore "trusted code" which may have access to the privileged api. So, enabling programming rights for all file system templates would be possible. But from a security point of view it is better to maintain a small list of privileged templates and review these with extra care.

I got that from the code. It's not the priviledged renderer philosophy that's bothering me, nor that it is only used for /templates/ vms, it's just that this particular bug is fixed for only the standard untouched not customized wiki, and can easily break if you customize.