Device Fingerprint
Using the dashboardOrganization, Members And Permissions

Product permission description

Organization, Members And Permissions: Product permission description

Whether a member can access a product depends on two levels of conditions:

  1. Whether the current organization has activated this product.
  2. Whether the current member has obtained the product permissions.

Only when both conditions are met, members can enter the corresponding product.

With and without permissions

PermissionsPage accessView dataAdd/edit configurationDelete/deactivateKey operations
No permissionNot allowed to enter the productNot allowedNot allowedNot allowedNot allowed
With permission (read and write)Can enterYesYesYes, but subject to page confirmation and organizational management rulesProvided according to current product capabilities

No permission

When a member accesses an unauthorized product, the console displays a no-permission interception page and prompts you to contact the organization's organization owner to activate permissions.

Lack of permissions does not equate to the organization not purchasing the product:

  • The organization has not subscribed to the product: a master account or business person is required to process the subscription.
  • Members have not obtained permission: the master account is required to modify member authorization.

Have permission (read and write)

Members who have obtained Device Fingerprint product access can enter the product and use the currently open viewing, creation, modification and management functions.

Read-only pages should keep data browsable, while writing operations should use one of the following methods:

  • Hide write operation button.
  • Gray out the button and indicate via Tooltip that read and write permissions are required.
  • When the user enters the edit page through a deep link, the read-only status or permission blocking page is displayed.

Don't allow read-only users to fill out a complete form and then be prompted for permission upon submission.

Read and write

Read and write members can create and modify configurations within authorized products, such as device fingerprint applications, endpoints, and Webhooks.

Read and write should not automatically equal all high-risk permissions. Key rotation, member management, and organization owner operations require tighter controls.

How menus and buttons are affected by permissions

Product Menu

  • Organization of unactivated products: you can hide the entrance or display the unactivated product page.
  • The organization has been activated and members have no permissions: the entrance can be hidden; data loading must be blocked when accessing through a link.
  • Members read-only or read-write: display the product entrance normally.

Page data

The backend must verify organization membership and product permissions on every request and cannot rely solely on the frontend to hide menus.

Write operation button

The following operations require at least read and write permissions:

  • Create, edit, deactivate or delete apps.
  • Create, edit, deactivate or delete endpoints.
  • Modify source verification, application signature and rate limiting.
  • Create, edit, deactivate or delete Webhooks.
  • Other operations that change product configuration.

The member may have opened the edit page before the permissions were modified. When submitting an operation, the server must re-verify the permissions; if the permissions have expired, the submission should be stopped and prompted to refresh the page or contact the administrator.

High-risk permission recommendations

The first phase adopts product-level read-write permissions. Sensitive operations such as key rotation and member management can still be controlled through organizational roles and secondary confirmation:

Recommended permissionsTypical actionsRecommended default owner
Data viewingOverview, events, visitors, risk signalsRead-only and read-write members
Sensitive data copy/exportCopy complete identification, export eventsAuthorized analytics or security personnel
Application configuration managementApplications, endpoints, security rules, rate limitingProduct administrator or R&D leader
Webhook managementCallback address, Token, testing and deletionBackend R&D or platform administrator
Key ViewView or copy server keysFew key administrators
Key rotationRotate Region server keysOrganization owner or key administrator
Member managementInvite, modify permissions, deactivate and delete membersMaster account or organization administrator
Organization owner operationsOwnership, organization-level high-risk settingsMaster account

High-risk operations should also be accompanied by:

  • Double confirmation.
  • Recent authentication.
  • Operation audit log.
  • Notification of operation results.
  • Minimum privileges and regular review.

Permission judgment sequence

The console can determine access in the following order:

Is the account signed in?
  └─ No → Sign-in page

Does the account belong to the current organization?
  └─ No → No-organization or removed-member state

Is the membership active?
  └─ No → Organization access disabled state

Has the organization enabled the target product?
  └─ No → Product not enabled state

Does the member have access to the target product?
  └─ No → No product access state

Does the operation require write access?
  ├─ Yes, but member is read-only → Deny the write operation
  └─ No, or member has read-write access → Continue

Does it require a separate high-risk permission?
  └─ Yes → Continue checking key/member/owner permissions