Bug #16726
closed
other cluster's special users (root and anonymous) can appear in user list
Added by Peter Amstutz over 4 years ago.
Updated about 4 years ago.
Release relationship:
Auto
Description
When using a federation, it's possible to use the anonymous user of one cluster to access another cluster (for example, it does a lookup by PDH across the federation on behalf of the anonymous user). This works but is confusing because it results in two or more "anonymous" users appearing in the user list, belonging to different clusters.
Possible fixes:
- Hide the foreign anonymous user from the user list
- Notice when the user uuid ends in "-tpzed-anonymouspublic" and associate it with the local anonymous user instead of creating a new account
- When making a federated request as the anonymous user, substitute the other cluster's published anonymous user token.
There's a similar issue with the system user (root). System users should probably not federate at all.
There's also more general UX problem of user accounts from different clusters having the same name and appearing in the user list, which is confusing.
- Category set to API
- Description updated (diff)
- Subject changed from hide other cluster's special users (root and anonymous) from user listings to other cluster's special users (root and anonymous) can appear in user list
- Description updated (diff)
- Related to Bug #16683: Trouble sharing with federated users added
- Assigned To set to Peter Amstutz
16726-anon-fed @ 87977ae72b8cfded3263b109caa5245fa1abd74f
- maps remote anonymous user to local anonymous user
- remote system user is always named "root from #{cluster}"
I decided not to flat out reject remote system users. When LoginCluster is in use, we want the system user to work everywhere. In other cases, it seems good enough to make sure the remote system user won't be confused with the local one.
- Related to Bug #16789: missing can_read link from anonymous_user to anonymous_group added
I think the code LGTM, but I just wanted to double-check by manually starting a federation and checking the UX aspect this branch fixes.
The result is that I couldn't even log into a federated cluster, because the token being returned wasn't v2. Not sure if I made a mistake in the process, I wanted to point it out just in case.
Lucas Di Pentima wrote:
I think the code LGTM, but I just wanted to double-check by manually starting a federation and checking the UX aspect this branch fixes.
The result is that I couldn't even log into a federated cluster, because the token being returned wasn't v2. Not sure if I made a mistake in the process, I wanted to point it out just in case.
It is a little more subtle than that.
What happens is you use the anonymous token for cluster1 to fetch a collection from cluster2 via the cluster1 controller. The controller makes sure the token is a v2 token.
I will see about creating an integration test for this.
- Status changed from New to In Progress
- Related to Feature #16794: API ensures configured Users.AnonymousUserToken is valid added
Reviewing 16726-anon-user-token - 09ff850
Just one suggestion:
- At file
services/api/script/get_anonymous_user_token.rb Lines 59-62: I believe you could simplify a little by using find_or_create_by()
The rest LGTM, thanks.
- Status changed from In Progress to Resolved
- Related to Feature #17298: remove the need to run get_anonymous_user_token.rb during installation added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by