We have an open risk item on the Box platform due to lack of controls on change management.
Specifically:
Box console settings must be manually performed across dev, test and production environments.
Lack of automated mechanisms to maintain consistency with the settings across the environments may allow weaknesses in lower environments (dev/test) to be exploited to exfiltrate data or modify data or inconsistencies between functionality tested in lower environments and what is configured in prod.
We would like the ability to be able to configure the settings via API so we can build environment management into out CICD pipeline. We believe many other customers with tight security and compliance controls would be keen for the same.

Before deleting a user from box system we can transfer the root folder from one user account to
another.
Once the root folder is transferred only then delete API must be triggered.
So in all, the delete operation will have to call two API one to transfer and another to delete.

But as the transfer API call will return synchronously.
For users with a large number of files and folders, this means the call could take minutes or hours to return.

So the delete operation will be in pending state until we receive the transfer API response.

Does box now have single API call to delete box user and also transfer the folder?

Lets consider the use-case below;
1. We are deleting box user - User1.
2. We have to trigger API call to transfer files for User1.
3. If the size of the files is too big we have to wait until the files are transferred or root folder gets empty for that user.
4. We have to wait till the time all files gets transferred or root folder gets empty.
5. Trigger API call to delete user once root folder is empty.

Here we have to wait till the root folder gets empty which might hamper the performance if the file size is large.

With webhook V1, we have the upper bound of 100 users in "touserids" field for each notification, so when a webhook has too many recipients (that is, more than 100 users are to be set in "touserids" field), we send multiple webhook notification for a single event so "touserids" is kept within 100 users for each notification.

For e.g. if an upload event was to trigger notification to 1000 recipients, we send 10 webhook notifications to the notification url with 100 users embedded in "touserids" field of each notification.

This causes duplicate notifications be sent to notification url although we only want to receive a single notification for a single event. We want this 100 users limit expanded so we can avoid this.

When working with a Box Enterprise that has tens of thousands of users, scripts designed to do things like user information syncing, group syncing, or user provisioning/deprovisioning often run into real issues with the Box API rate limits.

Some calls (e.g. downloading or uploading a file) are clearly significantly more resource-intensive than others (e.g. getting a user’s aliases). The method Google has implemented for the Gmail API (see https://developers.google.com/gmail/api/v1/reference/quota) seems like a really great way to balance the need to protect the back-end systems against the need for increased performance for less-intensive calls. It would be nice if Box implemented a similar model.

It is currently disallowed to use redirect_urls of the form http://127.0.0.1 in published apps.

These give the error "insecureredirecturi".

These are allowed in unpublished apps.

Having a redirect to 127.0.0.1 is very useful for native apps which run on the users computer (eg rclone https://rclone.org ).

It is pretty much impossible to do https to 127.0.0.1 - you can't get a valid certificate for it. See this link for details: https://letsencrypt.org/docs/certificates-for-localhost/ - and also for reasons why using http://127.0.0.1 is treated as secure by browsers.

I'll describe how rclone, a native CLI app works. Rclone runs on the users computer - it runs a local webserver to get the auth details so the communications done over http are from the users browser to the users computer and never reach the LAN or Internet. Modern browsers treat http://127.0.0.1 as secure as the traffic never runs over the Internet or even the local network.

This is more secure than having to use an external https server which then redirects to http://127.0.0.1 as the credentials go straight to the CLI application and don't have to go over the Internet at all or travel through another server.

Note that almost all the other oauth providers that rclone supports allow http://127.0.0.1 redirect_urls, this includes Google Drive, Amazon Cloud Drive, Dropbox, Google Cloud Storage, Google Photos, Hubic, MailRu, pcloud, sharefile, Yandex (and more!)

So box is looking like the odd one out here!

Please implement this feature - thank you :-)