XWiki rights, the prevent checkbox, and login extensions

Development
,
#1

Hello fellow XWikiers,

In the Google Apps world, we would like to make it possible to allow Wikis whose admin has checked the “prevent checkbox” (Prevent unregistered users from viewing pages, regardless of the page rights) to use Google-based login.

This fails currently, because a call to /jsx/GoogleApps/JSExtension is also prevented.
It would also fail for any bounce URLs (e.g. a request to login which needs to redirect to an external site, and a redirection back from the external site that would log-in the user).

I believe that the inclusion JS-extensions (and style extensions) and the existence of bounce URLs are actually common to many other login extensions: OpenID would certainly be one.
Do you, developers of a login-extension, share this view?

By this thread, I would like to get a common-vision on how to adapt our login-application to this checkbox and make sure that the developers of other such extensions can take advantage of it. I would summarise the result of this discussion in a design page.

paul

PS: A workaround is to use prevent-rights (or, similarly, some view rights for groups where xwikiguest is not) but the sense of the checkbox is then not there anymore: It is more trustable than rights that can be done.

#2

I’m not a login extension developer but I agree. For me the solution could be to use some extension points in the login action / template to allow us to:

  • include some JavaScript / CSS when the login page is displayed
  • handle the redirect from an external authentication provider (note that this means we should tell the external provider to redirect back to the standard login page, using the login action)

I would start by investigating if this is not already possible using the https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/AfterHeaderUIX and / or https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/ExtensionPoint/HTMLHead .

Thanks,
Marius

#3

Actually the OpenID Connect authenticator totally bypass the standard login action (each authenticator can decide what to do when the login is requested in XWikiAuthService#showLogin) and expose its own endpoints using resource handlers so it does not have this kind of issue (each resource handled is taking care of its own access control by default).

#4

Hold on. I could not entirely grab the details in the source of what you mean by “resource handlers”. Do you have half-an-inch more of a concrete hint? Are you wiring a new servlet?
thanks
Paul

#5

Kind of. What I mean by “resource handlers” is documented on https://extensions.xwiki.org/xwiki/bin/view/Extension/Resource%20API. XWiki has it’s own “servlet” system which allow extensions to easily expose (supposedly generic but usually HTTP) endpoints. There is not a single wiki page in the OpenID Connect tools, full Java (and templates located in JARs).

Resource handler system is even more important for the OpenID Connect provider side of this project which have to expose various endpoints which can’t be disturbed by XWiki actions checks.

#6

Thanks Resource API looks like an interesting thing indeed. Can I be sure that this is also compatible to installs such as short-URLs?

Also, your answer seems to confirm that there’s no way you can work around the checkbox Prevent unregistered users from viewing pages, regardless of the page rights (probably, as intended).

#7

I did not try actually (I started to work on the provider and then I naturally kept using resource handlers for the authenticator) but yes I don’t see much way around this option.

#8

Resource handlers starts after http://host/xwiki/ so for short URL you will have to add the resource handler to the list of known entry points like it’s done for “webjars” and “asyncrenderer” (which are resource handler based).

#9

I’ve now started a design page in the direction.

I will then try to evaluate the advantages and disadvantages of running things with a resource-API-endpoint or with javascript-embedded in the login’s extension-points.
In all cases, a form of extension-point for the login page is necessary.

thanks.

paul

#10

Not sure what you mean. As I said each authenticator can decide what to do exactly for login in XWikiAuthServiceImpl#showLogin(). Showing the login form is just the default behavior.