The EVRYTHNG Platform includes several mechanism that allow configuration of granular access to resources within any given account. These make it possible to allow effective collaboration between team members with different needs and privileges, and also provides the security required where product and user data is concerned.
By default, these features provide an intuitive degree of access that is suitable for most accounts. However, for those that require more strict control of resources for access and security purposes, they are also highly customisable when combined and correctly configured. This page aims to help explain how these mechanisms work, and also how to achieve some of the most common requirements and scenarios.
The following gives a brief summary of each of the access control features available to developers to leverage in their integrations. More in-depth information can be found on the linked pages.
Operators and Access Tokens are the two different actors that our platform supports.
Both Operators and Access Tokens can have roles that define their access to the platform. What separates them apart is that an Operator is related to a user - a person that is signed into our platform, whereas an Access Token could represent, for instance, the authorised access for a software used by other systems, or a mobile application used by people that are not signed into the EVRYTHNG platform.
Both Operators and Access Tokens have an API key directly related to them. For example, each Operator collaborating as team members on a given EVRYTHNG account will have an Operator API Key that is unique per user, per account. Similarly, a given Access Token signed into our platform and part of a certain account will have an API Key that is unique per account.
See API Keys and Key Permissions for more information about API keys.
Any given API key has at least one role that defines what the actor is reasonably required to do. By making use of the platform roles and assigning them to a given Actor, one could, for example, be able to read products and thngs, but not update or delete them.
See Roles and Permissions for more information about roles.
Beyond roles - that define what resources actors can access and the operations they can make on those resources - it is also possible to restrict access based on attribute filtering.
For example, a sourcing manager that is responsible for 10 different factories may only need access to data that is relevant to those factories. Moreover, factory administrators may only need access to data that is produced in their factories.
Another example would be a regional brand manager that supervises a group of brands in the "North America" region - the general account administrator may require an ability to restrict this manager to only that group of brands within that one region so that he or she is not able to see other campaigns that are not within their scope of access.
Read the Restrictive Conditions page to learn more information on how to restrict access using attribute filtering.
To retrieve their own access details for a given account, operators can reach the
/me API using their access API key. This is available to any Operator with a valid API key that has permissions to reach this endpoint and will return the current Operator access details, including their restrictions and detailed roles.
Dashboards and Apps that need to make operations on behalf of Operators can adjust feature restrictions based on the caller's access retrieved through this endpoint.
Go to the Operator Access page to learn more information on how to obtain the current Operator access details at any point in time.
Updated almost 2 years ago