react-native-documents / document-picker

Document Picker for React Native
https://react-native-documents.github.io/
MIT License
1.33k stars 434 forks source link

Is it normal behaviour picking the files without declaring Storage permission #680

Closed SpeakingWithMachines closed 3 months ago

SpeakingWithMachines commented 10 months ago

Bug report

Summary

I have got a requirement in my new app to upload docs. I found this app pretty cool to upload docs and i did a POC as well. But I am able to pick all type of files(including media files like, Audio, Images and Video) with out any Storage permission. I tired in real devices from Android 9 to Android 13. I have neither mentioned storage permissions in androidmanifest.xml nor requested permissions.

I am able to pic files from all the folders like Documents, Downloads, Music, DCIM, Ringtones, Recordings, Other app's folders like whatsapp, Twitter ect..

Reproducible sample code

I do not have much code except what mentioned in the docs

let result = await DocumentPicker.pick({
    type: [DocumentPicker.types.allFiles]
});

Steps to reproduce

Run the above mentioned code in android version from Android 9 to Android 13

Describe what you expected to happen:

Storage Permission to be taken from user since we are picking files(including media files) across the storage.

Environment info

System:
    OS: macOS 13.3.1
    CPU: (8) x64 Apple M1
    Memory: 37.92 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 14.0.0 - /usr/local/bin/node
    Yarn: Not Found
    npm: 6.14.4 - /usr/local/bin/npm
    Watchman: Not Found
  Managers:
    CocoaPods: 1.12.1 - /opt/homebrew/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK: Not Found
  IDEs:
    Android Studio: 2022.2 AI-222.4459.24.2221.10121639
    Xcode: 14.3/14E222b - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.19 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0 
    react-native: 0.71.3 => 0.71.3 
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

library version: 9.0.1

Android version: I tried in Android 9, 10, 11, 12, 13. Same behaviour in all devices.

I am under an assumption that this package is built in such a way that it can access all type of files without any permissions like default files app in Android devices.

Please correct me If I am wrong. If package creator confirms that this library doesn't require Storage permission across all the Android versions(At least as of Android 13) I can confidently proceed to Production.

Thank you for the cool package.

mersanjay24 commented 9 months ago

i have the same issue below android 13 working fine

SpeakingWithMachines commented 9 months ago

@mersanjay24 May i know which OS(Android) version you have tested in?

below android 13 working fine

Are you facing any issues in Android Version >= Android 13 ?

mersanjay24 commented 9 months ago

Yes i am using android 13

but i am not sure it is related to picker problem

below is snip code which is implemented const response = await DocumentPicker.pickSingle({ presentationStyle: "fullScreen", type: [types.images], allowMultiSelection: false, mode: "open", copyTo: "documentDirectory", });

the above code return the below response {"fileCopyUri": "file:///data/user/0/com.accordlivingapp/files/e2146bf3-5fb3-4140-a923-c209d81b2c90/1000113682.jpg", "name": "1000113682.jpg", "size": 3831629, "type": "image/jpeg", "uri": "content://media/picker/0/com.android.providers.media.photopicker/media/1000113682"}

@SpeakingWithMachines can you please check the and update me

SpeakingWithMachines commented 9 months ago

Yes i am using android 13

but i am not sure it is related to picker problem

below is snip code which is implemented const response = await DocumentPicker.pickSingle({ presentationStyle: "fullScreen", type: [types.images], allowMultiSelection: false, mode: "open", copyTo: "documentDirectory", });

the above code return the below response {"fileCopyUri": "file:///data/user/0/com.accordlivingapp/files/e2146bf3-5fb3-4140-a923-c209d81b2c90/1000113682.jpg", "name": "1000113682.jpg", "size": 3831629, "type": "image/jpeg", "uri": "content://media/picker/0/com.android.providers.media.photopicker/media/1000113682"}

@SpeakingWithMachines can you please check the and update me

I do not see any issue here. you are able to get the response properly.

JerakRus commented 9 months ago

We also encountered this problem. This is due to how this permission works, as well as how new ones work in API 33 and higher. https://developer.android.com/reference/android/Manifest.permission#READ_EXTERNAL_STORAGE

imanshul commented 7 months ago

Hey, i'm trying to do the same, using scoped storage instead of any permission (Read_External_Storage) to access files, but found that the files which were created by other apps can't be accessed/opened. When i try to open the URI provided by this library using react-native-pdf, it throws following error:

Permission Denial: reading com.android.extern alstorage.ExternalStorageProvider uri content: //com.android.externalstorage.documents /document/primary%3AAndroid%2Fmedia %2Fcom.whatsapp%2FWhatsapp%2FMedia %2FWhatsApp Documents%2FSent%2FMy test.pdf from pid=17343, uid=10148 requires that you obtain access using ACTION_OPEN_DOCUMENT or related APIs

So in order to avoid such issues, i'm using copyTo from react-native-document-picker and instead of using uri, i'm using fileCopyUri ![Uploading Screenshot_1700140206.png…]()

vonovak commented 3 months ago

Hello, To give an answer: if you use the import mode along with the copyTo option, you don't really access external storage. You let the user pick a file which is then copied to your app's storage (using storage access framework) so you are free to do anything with it.

If you don't use the copyTo option, that's when you could run into problems such as described above.

To access directly the file picked by the user, use open mode: https://react-native-documents.github.io/docs/sponsor-only/picker/open-mode

Open mode uses ACTION_OPEN_DOCUMENT.

Regardless of the mode you use, the OS won't let you do something if you don't have the permission. So if what you're doing works, then you're fine.