In my manifest i activated access to storage and access in my localstorage is always denied when 2 or more folders :
_packageName_\LocalState\<HERE> is ok
_packageName_\LocalState\folder1\<HERE> is ok
_packageName_\LocalState\folder1\folder2\<HERE> is denied
I don't know why i can access to my OWN localstorage when more than 2 folders... And it works when less !
NOTE : Access is denied only when i want to read files, i can create folders and file anywhere in my local storage
In Xamarin UWP apps, you could not directly use Windows.Storage APIs. The solution for your scenario is that you should create a DependencyService in your project. The DependencyService class is a service locator that enables Xamarin.Forms applications to invoke native platform functionality from shared code. So in this way, you could call the native UWP Windows.Storage APIs and get the file that you want for your app.
Related
I have an internal app (not a published one, only used within our Google Workspace domain) which is a command line tool to update the contents of some Google Sheets. It currently uses the https://www.googleapis.com/auth/drive scope and works fine.
I want to minimize the privileges of the authorization token that this app caches, and by reading the documentation it seems that I should be able to use the https://www.googleapis.com/auth/drive.readonly scope to find the file I want, and also https://www.googleapis.com/auth/drive.file to grant write access to only a specific file.
With the reduced scopes, I am not surprised to get an error like:
appNotAuthorizedToFile: The user has not granted the app 566375348811 write access to the file 1UsItGhBHwRaodHbv5g1LCrSESUZBkskDvKDkbGjREjI
The only relevant documentation talks about integrating apps with Google Drive and using the Drive Picker UI which I expect does this authorization behind the scenes. Since this is an internal command line tool, I really don't want to go that route.
Hence the question:
How do I open a file in a command line application using the https://www.googleapis.com/auth/drive.file scope?
I'm OK even if I need to set some magic metadata on the file to make it accessible.
Update
As I got a couple of responses saying that when using drive.file it is not possible to access files which are not created by the application, I am putting some supporting documentation here to show why I think it is possible:
The API-specific auth info is the first document on the Google Drive API page, and it specifically mentions:
So, when possible, use non-sensitive scopes as they narrow access to
specific functionality needed by an app. In most cases, providing
narrow access means using the
https://www.googleapis.com/auth/drive.file per-file access scope.
Further down the page it mentions:
This scope enables users to select the specific files from Google
Drive, and through the Google Picker, that they want to allow your app
to access.
I understand this to mean that it is possible to open files which were not created by the app, even when using drive.file.
My problem is that the document goes on to explain:
Many apps work with per-file access without any changes. If you are
currently using your own file picker, we recommend switching to the
Google Picker which fully supports the drive.file scope.
Well, since I am using a command line app, I cannot use the Google Picker, so I am asking how to implement my own. I do understand that the picker itself needs to have access to all the files (hence the need for a drive.readonly scope), but to actually be able to write the files, it needs the elevated permission of drive or the more restrictive per-file access of drive.file.
If I simulate an authorization request for drive.file I get a prompt which explains that authorizing the request will grant my app to:
See, edit, create, and delete only the specific Google Drive files you use with this app ℹ️
Clicking on the information icon I get a more verbose explanation which reads like it support opening any file I authorize:
This app wants permission to create new files or change existing files
that you open with this app. Once authorized, the app can:
See these files
Upload and download these files
Delete these files
See the names and emails of people you share these files with
Share and stop sharing these files with others
Organize these files
There may be private information in your Google Drive, like financial
records, medical reports, photos or tax info.
There are also other examples of applications like ZIP Extractor or diagrams.net or Photo Editor which use the drive.file scope (based on the authorization prompt), and which I can use to open and edit files that were not created by them.
I am posting this as an answer, to demonstrate an ugly "workaround" for the issue.
TL;DR: Use a web based frontend to authorize access to files. Once the app is authorized, the command line app inherits the permissions.
More step by step instructions, assuming we already have a working command line project:
Go to https://myaccount.google.com/permissions and revoke all access I have granted to my app.
Follow the instructions at the Drive Picker API to update my current GCP project.
Create an API key. OK to be unrestricted, but I restricted it to https://localhost:9843
Create a new OAuth 2.0 client ID of a "Web application" type (my current one is "Desktop" type and that would not work). Authorize https://localhost:9843 as a JavaScript origin.
Copy the helloworld.html example at the bottom of the Drive Picker API guide which is also on GitHub with the following modifications:
Set developerKey to the API key created above
Set clientId to the new OAuth 2.0 client ID created abovce
Set appId to the numeric project ID of my GCP project
Add 'include_granted_scopes': true to the call to window.gapi.auth.authorize
Update createPicker to make it easier to find the files I want. E.g., set the mime type filter to application/vnd.google-apps.spreadsheet.
Host the example in a browser with ruby -rwebrick/https -e 'WEBrick::HTTPServer.new(:Port => 9843, :DocumentRoot => ".", :SSLEnable => true, :SSLCertName => "CN=localhost", :SSLCertComment => "Autogenerated" ).start'
Now, if my command line app fails to edit a file, I can use https://localhost:9843/helloworld.html to grant access to the file, and my command line app can then edit that file.
If you check the docs for the scope you will find it says.
https://www.googleapis.com/auth/drive.file View and manage Google Drive files and folders that you have opened or created with this app
This gives your app access to files that the app itself created or has previously opened.
You should also know that there is no way to limit authorization to a single file. Authorization is all or not thing.
How do I open a file in a command line application using the https://www.googleapis.com/auth/drive.file scope?
You make sure that the file was created by the app itself. using files.create. If the file was created by any other app the you cant access it using the drive.file scope
There is one note though if you have https://www.googleapis.com/auth/drive.read-only scope and you open that file to read it. the line where it says opened or created with this app implies to me that once you have opended it for read in this app that you would then be able to use it with https://www.googleapis.com/auth/drive.file but its not something I have tried.
Another thing is im not sure what you mean by open the google drive api is a file storage api its not going to let you see the contents of the file your going to have to download it and open it locally. Have you considered going though the Google sheets api if you want to read and write to it programmatically?
Apps requesting access to the All files access permission without a permitted use will be removed from Google Play, and you won't be able to publish updates.
This is the bit that's unclear, at least to me. So if an app is currently in the Play Store but targets API 29 and has requestLegacyExternalStorage=true, will that app be removed from the Play Store in the future? If so, that's bad. I get that after November for any updates the target API must be 30.
We received this warning what does it means, we use requestLegacyExternalStorage flag and targetsdk 29, so my app will be removed from play? And what changes i need to do for this?
No, your app is not get removed from playstore...
but your app not might work if you targeted API 30 above. "requestLegacyExternalStorage=true" is a temporary solution provided by google to allow developer to smooth transition to new Secure Storage Model.
Many apps that had no legitimate need to read all the files stored on the device’s storage were requesting this permission, causing Google to narrow storage access permissions with Android 11’s “Scoped Storage” changes.
You have two option:
If your app require little to moderate use of storage > Use “Scoped Storage”
If your app is such as File Manager,Anti-virus,etc in which required all storage file access to work effectively and efficiently > Use "All files access"
Further query link_1 , link_2
I want to create an app that only my family members will be using. It needs to access Google Drive files using oauth access (to be precise it will be PHP client).
I've set permissions in Google API Console ./auth/drive.readonly.
I realize that I'll get an unverified app warning, but anyway, when I try to access the resources I get 403 error. Also when accessing for the first time and pasting the URL to get verification code it only says that app will have access to metadata, which is default permission.
Is it possible at all to create this kind of unverified app that will have those "unsafe" access to drive?
If anyone faces the same problem - when requesting access through an API, be it REST or PHP library one needs to specify the permissions app will be using. Those need to match the ones specified in Google Dev Console.
The application need to allow user to upload an passport photo so that admin can verify the user.
This tutorial http://weblogs.asp.net/imranbaloch/file-upload-in-aspnet5-mvc6 explains about file upload in ASP.NET 5 MVC 6.
However, the file is uploaded to a folder in project folder.
Is is the best practice? Is there any problem if there is thousands of users ?
Should I use Azure storage?
Will the code more complicated if I use Azure storage?
Do you have any
recommendation?
Normally when you upload to the file through your WebAPI, the web server that running under IIS had only access to folder underneath it's virtual root. If you want to store the file somewhere else, you could use \servername\urpath, provided that ur path is shared and grant write access to "IIS AppPool\DefaultAppPool" or other AppPool if you use a different one.
I have a query regarding accessing Skydrive folders programmatically through the Live SDK on Windows Phone.
So the scenario I have at hand is that a Windows phone app that I have built creates folders (and files) on your Skydrive. Now I want the following functionality which I haven’t been able to do so till now.
Is it possible that I can programmatically share my folder and files with View (and/or edit) permissions to my friends (as I know their user ID)?
If I am able to share such a folder can I access the content after logging in (with my live ID) from my phone. By accessing I mean download or stream content.
If in step 1, a person to whom the file is shared is provided edit permissions how can I programmatically edit such a file? The current problem I am facing in this step is that to update a shared folder the live sdk requests a wl.contacts_skydrive_update scope, but while logging in I am notified that no such scope exists.
This is the Error message I get when I try to get a shared_edit_link:
request_token_unauthorized: Microsoft.Live.LiveConnectException: The
provided access token does not have access to this resource. An access
token with one of the following scopes is required:
'wl.contacts_skydrive_update'.
Although the user does have edit permissions. Note: Such a scope doesn't exist.
There is a thread on this where it was listed as a bug in the beta. They said that now it should be fixed and you should only need this scope: 'wl.contacts_skydrive'.
here is the thread