Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GoogleApps Login should work even with "Prevent unregistered users from viewing pages, regardless of the page rights" #42

polx opened this issue Mar 20, 2020 · 5 comments


Copy link

polx commented Mar 20, 2020

As of today, checking the global-rights checkbox "Prevent unregistered users from viewing pages, regardless of the page rights" prevents GoogleApps Login to work: The JS-Extensions scripts and OAuth pages cannot be delivered so that a login process can work.

@polx polx self-assigned this Mar 20, 2020
Copy link

polx commented Mar 20, 2020

The following rights configuration worked for me as workaround instead of checking the box "Prevent unregistered users from viewing pages, regardless of the page rights":

Make XWikiAll group allowed to view any web-page (this is not checked by default).

Make XWikiGuest prohibited to do any action (you need to click several times on the checkbox to bring prohibition):


This made my anonymous access to any page that I could try be redirected to the login, the login buttons of XWiki and Google be displayed, and the login function with an identification on Google to work.

Copy link

mflorea commented Mar 24, 2020

@polx an explicit allow for some user or group is equivalent to a deny for the rest. It means: only this user or group has this right. So denying some right for guest users that was previously allowed explicitly to logged in users doesn't make sense to me.

Now, even if you remove the redundant deny, I don't see how this can workaround the issue: guest users will still not be able to access (view) the JavaScript code that is used to extend the login form. Am I missing something? I don't see why guest users would be able to view the page holding the JSX object, with the rights changes you propose.

I don't think you can work around this without giving explicit view right to guest users on the page holding the JSX. Basically this means setting up rights so that guest users can't see anything except for some pages that are needed for login. I think this is a common practice when someone needs to customize (from the wiki) the look & feel of the login page. The guest user needs to have access to the styles and images used on the login page. If those are put on a skin or color theme defined in a wiki page then that page needs to be accessible to guest users.

Copy link

polx commented Mar 25, 2020

Here's a workaround that is even simpler: Only preventing the guests to access is enough.
The following screenshots display what "Global Administration: Rights" indicate for both types: Users (this is where one needs to change from the default). Note that the checkbox "Prevent unregistered users from viewing pages, regardless of the page rights" is not checked.

Screenshot 2020-03-25 at 18 06 57

and Groups (nothing changed here, compared to the default 12.1):

Screenshot 2020-03-25 at 18 07 03

This works because GoogleApps.WebPreferences has a view rights for guest users. This right takes then precedence to the forbidden of the global rights.

@polx polx added this to the 3.0 milestone Aug 4, 2020
Copy link

Note that the two setups are not equivalent.

  • Deny the rights for guest:

  • and checking: "Prevent unregistered users from viewing pages, regardless of the page rights"

As explained here:

To be able to prevent the access of unregistered users, you must check the options Prevent unregistered users from viewing/editing pages, regardless of the page or space rights from Administration > Users > Rights

Copy link

polx commented Nov 4, 2020

Hello @CamiAndrei ,
I know that these are not equivalent and this checkbox was introduced late, I think, precisely, because some crazy guys like app developers have been overriding the possibility for a guest to see things even though the expectation was that everything is blocked.

Now... For something that is needed for a login functionality, you need to deliver content. If this is expected from an app developer it should be possible to include it. Unfortunately this checkbox allows very few exceptions. The migration to 3.0 is precisely in this objective: change the delivery channel (including the return-URL-after-OAuth-authorization) so that it fits the checkbox's requirement.

Hope it helps to understand.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

3 participants