do you ensure data integrity, compliance, and retention? 2. How do you manage token calls and security properly? 3. How do you control program access and permissioning? 4. How can you build program flow around common error responses? What problems are we looking at today?
User Account Maintain all user an application data within the service account. Users will be collaborated in on content. User specific data is maintained in the individual user account. All data access requests are made on behalf of the user. Where to Store User and Application Data
in the Service Account (Overview) • Improved data security due to tight controls over data location and sharing • Data retention and migration improves following customer deletion, as the user collaboration is simply removed. Benefits • Architecture complexity increases as a separate user folder structure needs to be maintained in the service account. • Single point of failure. Concerns
in the User Account (Overview) • Data is retained and owned by each user. • Simple repeatable architecture on each user account. Benefits • Data retention after customer deletion requires data migration or loss. • App has no control over data integrity. Concerns
should you authenticate / authorize your users and when should you reuse tokens? / How do you use access tokens in front- end code securely? / How do you handle tokens within the different SDKs? The Issues
Best Practices / Access tokens are valid for 1 hour and should be stored / reused. / Tier 1 SDKs (Node, Java, .Net) automatically refresh tokens. / Token expiration (for refresh) should be tracked via expires_in value (from token request) and 401 unauthorized errors.
Access Token Client-Side Code Downscoped token is deployed to client-side code, mobile environment, or UI tool. New access token that is tightly restricted in access rights (read / write) for a file or folder. Standard OAuth2 access token that is fully scoped for an enterprise or user. Token Downscoping Process
No User Access All Users Service account can access its own content, app user content, as well as content of any users in the enterprise Service account can access its own content and content for any app users it creates Service account can only access its own content User Access Levels for a Service Account
• Perform actions as users: Use an As-User header with each request to act on behalf of a user. Access token passed is for service account. • Generate user access tokens: Create an access token scoped to a user account and use that token for each request.
Application Access Advanced Features No User Access Application None set App Users Only Application One or both set App and Managed Users Enterprise One or both set Setting User Access for the Service Account Settings to use to get the desired level of user access for a service account
Unauthorized Errors Access token maintenance / Access tokens expire after 1 hour. At that point they must be refreshed using the refresh token. / The .Net, Java, and Node SDKs handle this refresh action automatically. For any other SDK or direct API integration token expiration responses (401: unauthorized) will need to be handled through the app.
Insufficient Permissions Errors User and application scoping / There are typically two causes of a 403: access_denied_insufficient_permissions error, either the user an access token is scoped for doesn’t have permission to perform an action, or the application doesn’t. / For user permissions, try logging in as the user via the “Log in as this User” option in the admin console. Attempt to access the content manually. / For an application, ensure that the application has the correct scopes defined for the action that it is trying to perform.
Not Found Errors Access Token Scoping / This may be encountered when trying to work with files and folders within Box when using a JWT / OAuth 2 based application with a service account. If the ID of the file / folder that is being accessed has been verified as present, this error will typically be caused by the account that the client is pointing to. For instance, if a file exists on a user account but the access token client is scoped for the service account, then a 404 error may be produced. / In cases of an access token that is scoped to the wrong account, use the As-User header or user scoped access token for user access, or a service account scoped access token for service account files.
Name Conflicts Checking name uniqueness / File / folder names within a given folder must be uniquely named. When there is an attempt to create a new file / folder with a name that already exists, a 409: item_name_in_use, or a standard 409: conflict may be produced. / In case of a duplicate user login information being used when creating new managed users, a 409: user_login_already_used error would be produced. / These errors should be handled. Possible next steps in the program flow would be to attempt the same API request / login with revised information.
Metadata Conflicts Checking if metadata is already present on a file / If metadata for a template is already present within a file and a request to add metadata is made, the API will return a 409: tuple_already_exists error. / This error should be handled in a try / catch. When found, a request to update the existing metadata should then be made. / Update requests will need to use a JSON patch object.
Rate Limiting Check Retry-After header for amount of time until next call / Making requests to auth a user each time they visit. Access tokens should be stored for future use. / Polling the event stream too often. Cache results when possible. / Producing too many requests from a single user (e.g. a service account). Limit is 10 API calls per second per user. / Making too many simultaneous upload requests from a single user. Limit is 4 uploads per second per user. / Making too many search requests too quickly. Limit is 6 searches per user per second (up to 60 searches per minute) and 12 searches per second per enterprise.