xwikisas / application-googleapps

Google Apps Integration
0 stars 4 forks source link

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

Open polx opened 4 years ago

polx commented 4 years ago

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 commented 4 years ago

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).

xwiki-all-group-views-all

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

xwikiguest-prohibited-all

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.

mflorea commented 4 years ago

@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.

polx commented 4 years ago

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.

CamiAndrei commented 3 years ago

Note that the two setups are not equivalent.

As explained here: https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki

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

polx commented 3 years ago

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.

Paul