In which wiki should the authentication be executed in the standard REST endpoint?

Hi devs,

Right now, the REST endpoint authenticate the user before handling the REST resource and each resource is a black box from generic REST system point of view.

Among other things, it means that the authentication can only take into account the domain to know on which wiki to execute the authentication. This also means that it’s always the main wiki when you don’t have any domain → subwiki mapping setup (like a pure path based multi wiki setup), which leaded to the creation of Loading....

So what should we do ?

Here are a few possibilities I can think of for what we could do:

  1. Do nothing: the logic makes sense and XWIKI-17936 is an acceptable limitation (I guess a resource could decide to re-authenticate if the URL wiki does not match the context wiki, but it’s definitely not pretty…)
  2. Make the resource URL path a little less of a black box and standardize the /wikis/{wikiName} prefix as being something which describes the target wiki to set the context to (and authenticate on). This might break use cases which do need and expect the context wiki to always match the domain, whatever the path.
  3. Try to hack Jersey to, between the resolution of the URL → component the actual execution of the component, ask the component where to authenticate (and fallback on 1. if the component does not indicate anything special). It’s less potentially breaking as 2. since the resource decides what to do.

I’m fine with 1. and 2..

I assume most people will prefer 2.. I doubt it will really break anything in practice and I guess it’s not such a bad thing to standardize this very important piece of information in the REST URLs (in practice it’s already a de facto standard used the same way by most REST endpoints which require a wiki information).

I’m really not a fan of 3.. It’s not that it does not make much sense, but it means relying even more on Jersey’s internal, and it’s already a challenge to upgrade it…

WDYT ?

I think I’d go to 2 maybe with a config to disable it if needed, but not sure it’s really needed.

Thanks

I’m afraid this too dangerous, as, if we implement that, the REST resources will start to be implemented with the expectation that they don’t really need to take care of the wiki (and will be broken if this is disabled).

+1 for option 2.

+1 for option 2.

Thanks,
Marius

4 +1 for option 2.

I pushed it in master (so XWiki 17.10.0), but not in LTS branches (I really don’t think it’s a good idea to change the way a REST request is authenticated in a LTS…)