In the large screen/report page after public sharing, since the user login account is not required, the row-level permissions of the data model in the page , the user mailbox embedded in the SQL modeling , and the API backend to obtain the currently logged-in user need the user login account to proceed. None of the permission restriction functions are available. However, in some scenarios, it is expected that these permission functions will also take effect on publicly shared pages. Therefore, we have designed the function of "identifying users on shared pages through URL parameters". This function is applicable to scenarios such as:
- Embed the large screen/report sharing page of Sugar BI in the third-party system, and allow the permission restriction functions such as row-level permissions to take effect even if the user does not need to log in to the Sugar BI account
- Embed the large screen/report page of Sugar BI in the third-party system to solve the problem that the browser cannot log in to the Sugar BI account under cross-domain conditions (cross-domain cookie restrictions in the Chrome browser kernel), but want to control users from accessing the large screen/report page permissions issue
Shared pages identify users through URL parameters
Taking the row-level permissions of the data model as an example, we specified that [email protected]user Zhang San ( ) has 华北the row-level data permissions of the region. On the publicly shared page, the chart in the page will report an error as follows:
In order for the row-level permissions to also take effect on the public sharing page, in the pop-up box of setting the public sharing page, it needs to be enabled as follows:
In addition, when accessing the public sharing page, sugar_sign_user_email parameters need to be added to the URL and assigned as the email address of the target user. As shown below, we can see that [email protected]user Zhang San ( ) has 华北the row-level data permission of the region:
If we set the Li Si ( [email protected]) user to have 华东the row-level data permission of the region, then as shown below:
In addition to the row-level permissions of the data model in the above example , the embedding of user mailboxes in the SQL modeling mentioned above and the acquisition of the currently logged-in user in the API backend can also be implemented in a similar way.
Placement tampering of URL parameters that identify users
For the above scenario, you may have realized that there is a security risk of data unauthorized access. Users with a certain technical foundation can sugar_sign_user_email simulate the data permissions of any other user by modifying the value of the parameter in the URL, which has hidden dangers in data security.
In response to this problem, in order to prevent users from modifying URL parameters at will, we recommend that you choose the "Pass Token Verification" method when sharing publicly, and refer to the Token parameter signature verification on the sharing page . In this case, sugar_sign_user_email the parameters will be It is encrypted and calculated into the signature parameter, so as to ensure that the user cannot modify the parameter at will.
Page access is also limited by the user ID parameter
On the basis of the document in the previous section, we can also control the user's access and browsing rights to the page. For example, we set Zhang San ( [email protected]) to have browsing rights, but Li Si ( [email protected]) has no browsing rights. For details on how to set the user's browsing permissions to the page, see Permission Management .
Enable "Page access is also restricted by userid parameter" as follows:
At this time, when the assignment of the URL parameter is Zhang San ([email protected]):
If, URL parameter assignment is Li Si ( [email protected]):
Sugar BI supports a free trial , and everyone is welcome to come and experience it!