-
Type:
Suggestion
-
Resolution: Unresolved
-
Component/s: Search - Search Results
-
None
-
1
User Problem
Many admins have super admin accounts with access to all 3p connector data and non-super admin accounts with restrictions.
When clicking "Connect" in Rovo Search to a 3p connector, the third party controls the OAuth token generation process. Many third parties will not make it obvious which account is being used to generate the OAuth token, and admins may accidentally create an OAuth token using the super admin privileges instead of their regular account privileges.
Later, when admins go to search for content with Rovo, they will see highly sensitive documents returned from that 3p connector, and believe that Rovo is leaking data when actually the OAuth token being used by Rovo Search is from an account different than the one that admin intended to use.
Suggested Solutions
In the Rovo Search results, make it very clear which OAuth token was used to produce the 3p result and, if possible, the email used to generate that OAuth token.
Current Workarounds
If admins suspect this problem, then can:
- Disconnect the OAuth token from their Atlassian account by navigating to https://id.atlassian.com/manage-profile/apps and find the 3p connector token under "Atlassian third party account access"
- Navigate back to Rovo Search (e.g. at your Confluence instance > perform any search > on the right) and click "Connect" to the 3p connector. Ensure that the session to the 3p connector during the OAuth generation process is for the correct account. Consider using a fresh cacheless browsing session (Incognito, InPrivate, etc) during the OAuth generation process to ensure that the correct account is used.