Skip to main content

Can I call .content() on file with ReadOnly permission?

Can I call .content() on file with ReadOnly permission?
yrraadi

Hi

I’m currently developing an application for my research group that pulls our images from box and applies certain operations on those images to generate training data for our CV models.


We want to make this application public through a repository, and we want users to be able to access our image data using JWT authentication (config file for authentication will be provided in the repository). However, we don’t want users to be able to write to the folders and change their image content.

I thought of giving ReadOnly permissions, however, box developer console says write permissions are required to allow users to download the content.


Below is the code that pulls the content of the image by img_id (image id).


def download_image_from_box(self, img_id):

        """

        Downloads image from Box storage

        """

        # Get file and read image data into memory cache

        file = self.box_client.file(img_id)

        file_data = file.content()

        # Decode image

        src = cv2.imdecode(np.frombuffer(file_data, np.uint8), cv2.IMREAD_COLOR)



        return src

Will this still work if I enable ReadOnly permissions?

image


Thank you!

Did this topic help you find an answer to your question?

4 replies

rbarbosa Box
  • rbarbosa Box
  • Developer Advocate
  • 553 replies
  • August 9, 2023

Hi @yrraadi , welcome to the community!!!


Indeed you can’t download without the write file permission, if you do this you’ll get a 403.


However I’m assuming you have the content somewhere else under another user, and further restrictions apply.

If that is the case when you share the folder with the service account you can limit it to viewer, which allows download, preview and share.


Together with the write scope on the app/service account, download would be possible but no write permissions on that shared resource.


Sharing a JWT configuration on a repo is very unusual, and although I’m sure you have a reasoning to get here, there maybe an easier way to solve your use case.


That said can you elaborate a bit more on your end goal/project?


For example at face value, application users seem to be appropriate, but that repo config is throwing me off.


Let us know.


Cheers

yrraadi
  • yrraadi
  • Author
  • New Participant
  • 1 reply
  • August 9, 2023

Thanks for your reply.


Basically, we’re building a repository via which any user can pull images from the cloud (in this case box). Our code performs certain operations on the images and saves them to the user’s device, so they can start training their computer vision models on these images. At first we were using Azure, but it turned out to be very expensive for our use case and hence we switched to Box to store the images.


Right now, the program authenticates the users using the config file (downloaded from the configuration section of Box app). But we want users to only be able to pull image data using the snippet of code (shared earlier in this thread) which is part of our repository.


Do you recommend a better way to authenticate these users, such that they can only pull image data but cannot write to our folders on Box, which contain these images?

rbarbosa Box
  • rbarbosa Box
  • Developer Advocate
  • 553 replies
  • August 9, 2023

Let me ask around @yrraadi

yrraadi
1 person likes this
  • yrraadi
    yrraadi
rbarbosa Box
  • rbarbosa Box
  • Developer Advocate
  • 553 replies
  • August 9, 2023

Hi @yrraadi ,


In the mean time, let me share with you some of my thoughts.


The closest use case I can think of is an application, e.g. a Python FastAPI implementation running somewhere. This Python FastAPI would then connect to your Box app via JWT and hide all the security and permissions details.

That way you could use the application users inside your JWT and manage the access anyway you want.


But, if I understood correctly, you don’t have that abstraction layer and want to share a restricted access directly to your Box instance.


The most common way folks share their Box content publicly is via a public shared link, so in theory you could just share the folder you want publicly and distribute their web url.

However this shared link opens a Box app in the browser for user interaction, not practical to create scripts but, see if it works for you.


Now if folks want to access your shared link programmatically they can, provided they use a Box account (can be a free one), and create an Box app on their side. It’s perfectly doable, but does involve a few steps, and sometimes folks get lost in the process…


I have had examples of this in the past:




So if we go back to your original proposal…


A JWT Box app configured to read and write.

A folder shared with the service account associated with the JWT with only Viewer which will allow download.


This by it self would prevent the JWT app from writing to your shared folder.


However the JWT app would be able to create content on their own area, upload, folders, etc.


The content creation could be prevented by setting the space_amount of the service account to zero, but it would still be able to create folders on it’s own area.


Now, how acceptable is this for you?


It’s unlikely folks would decide to create folders, just because, without being able to do anything else with them.

A scheduled maintenance script could also delete every folder owned by the service account.


The cleanest of the options would be the shared link to the folder, even if that means you need to put some more instructions on how to create and use a box app in your repo.


The best solution would be to have a Python FastAPI running somewhere, which will probably have some costs.


Let me know your thoughts, and I can try and assist with some guidance for testing.


Best regards

Reply


Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings