Product permission description
Whether a member can access a product depends on two levels of conditions:
- Whether the current organization has activated this product.
- Whether the current member has obtained the product permissions.
Only when both conditions are met, members can enter the corresponding product.
Read-write, read-only, and no access
| Access level | Product access | View data | Create/edit configuration | Delete/deactivate | Key operations |
|---|---|---|---|---|---|
| No access | Not allowed | Not allowed | Not allowed | Not allowed | Not allowed |
| Read-only | Allowed | Allowed | Not allowed | Not allowed | Subject to current product capabilities and page-level controls |
| Read-write | Allowed | Allowed | Allowed | Allowed, subject to confirmation and organization-management rules | Subject to current product capabilities and high-risk permission controls |
No access
When a member opens a product they are not authorized to use, the dashboard displays an access-denied page and directs them to contact the organization owner.
Lack of permissions does not equate to the organization not purchasing the product:
- Product not enabled for the organization: the organization owner or your GEELAB representative must update the subscription.
- Member not granted product access: the organization owner must update the member's access.
Read-only
Members with read-only access can open Device Fingerprint and view data within their authorized scope, but cannot create, update, deactivate, or delete configurations.
Read-only pages should keep data browsable, while writing operations should use one of the following methods:
- Hide write operation button.
- Disable the button and use a tooltip to explain that read-write access is 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, integrations, 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 read-write access:
- Create, edit, deactivate or delete apps.
- Create, edit, deactivate or delete integrations.
- Modify source verification, application signature and rate limiting.
- Create, edit, deactivate or delete Webhooks.
- Other operations that change product configuration.
Deep links and permission changes
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
Product access works together with organization roles. Sensitive operations such as key rotation and member management can still be restricted by organization roles and confirmation requirements:
| Recommended permissions | Typical actions | Recommended default owner |
|---|---|---|
| Data viewing | Overview, events, devices, risk signals | Read-only and read-write members |
| Sensitive data copy/export | Copy complete identification, export events | Authorized analytics or security personnel |
| Application configuration management | Applications, integrations, security rules, rate limiting | Product administrator or R&D leader |
| Webhook management | Callback address, Token, testing and deletion | Backend R&D or platform administrator |
| Key View | View or copy server keys | Few key administrators |
| Key rotation | Rotate Region server keys | Organization owner or key administrator |
| Member management | Invite, modify permissions, deactivate and delete members | Master account or organization administrator |
| Organization owner operations | Ownership, organization-level high-risk settings | Master 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