We are building an app that allows users to connect their cloud storage (in this case gDrive) and upload files from our app, however they also have the ability to disconnect from it and perhaps connect to another.
A use-case might be:
A User connects to gDrive(App creates folder and uploads files) >
Later user disconnects from drive in-app >
Later user reconnects
Problem being we then want to grab this previously created folder and make changes and the issue is, in order for the user to reconnect they have to reauthorize, setting a new token and we therefore no longer have access to that folder and instead our app auto-creates a new folder with the same name - obviously this is not what we want.
The only solutions we can think of is not re-authorizing on disconnect/connect or increasing the scope of oauth and searching for the folder.
We will be using something like rClone in the future, but for now we are focusing on a couple of the main cloud services.
Are there any other solutions to this?
Your app is using drive.file scope, which allows it to access files created or opened by the app.
Users commonly disconnect from the app, effectively deauthorizing it. Because of this, the app does not have access to folders that were created last time user connected to the app.
The description of drive.file scope is quite clear:
Per-file access to files created or opened by the app. File authorization is granted on a per-user basis and is revoked when the user deauthorizes the app.
Because of this, unfortunately, the only two ways to allow the app to access previously created folders are the ones you already sketched:
Use a scope that provides a wider access: the scope in this case should probably be https://www.googleapis.com/auth/drive, since the app, from what I understand, needs write access.
Change the workflow of your app so that users don't deauthorize the app.
Regarding the use of a wider scope, the following feature request, which apparently was internalized recently, could provide an acceptable workaround in case it got implemented:
FR: Drive Restrict access to folder when authorizing applications
I'd suggest you to star the referenced issue, to keep track of its development and to help prioritizing it.
Related
My GoogleService-Info.plist file for iOS was stolen, is it possible to disable access to my Firebase Firestore to all current iOS devices, and reset this file ?
I tried to delete my iOS app in Firebase, but I can still make request from my iPhone...
And I need to disable access only for iOS devices not Android.
As Doug Stevenson pointed out the contents of the GoogleService-Info.plist are public and accessible to every iOS user of your application. Therefore it is inaccurate to say they could be stolen as they're already publicly available.
As explained in the Firebase documentation the file fields contain identifiers used by your application and Firebase servers to route the requests being made to Firestore, Real Time Database and the rest of products the app might be using. Reading the documentation or the post shared by Doug you would see the information exposed is not a security threat.
Moreover, I would like to point out that everybody could try to access your Firestore collections and try to add/drop data. This is indeed expected as Firestore is publicly accessible by mobile and web clients. However, this doesn't mean Firestore is exposed to users to do whatever they please, instead, the actual access is totally under your control by the means of security rules, which enforce what actions a given user could do. In that sense, the developers who left will only have the access level that your security rules grant them, which shouldn't be a threat when having good rules in place.
Lastly, you may revoke the credentials completely removing the application. I'd say it's not a great idea as you would cause a service disruption to app users. Also, this won't improve security or diminish risks.
You can remove the app directly from the Firebase console
Before proceeding make sure to check and understand the consequences.
Click on Settings > General;
Scroll down to Your Apps;
Identify the app and click on Remove this app.
I've frequently heard that the main issue we need Firebase security rules is because an application contains all the configurations needed to connect to the database and thus users could do something like db.delete('*'), read/write whatever they want, etc. etc.
I can see how this is possible on a web app, as you could check out the requests being sent over the network and thus get the endpoint needed to connect to the database, but, on an iOS app, how would this be possible?
For instance, say I created some chat app with Firebase and released it to the App Store. When a user downloads it, how would he/she gain access to my database through an API other than the buttons etc I provide with them with? Is there something equivalent to the "Network" section in google chrome that shows all outgoing requests, and, from, this they could send a malicious request to my database? Would this require installing 3rd party software onto their device to see all outgoing/incoming requests and they could get the required endpoint/database connection info from there?
Thanks.
When a user downloads it, how would he/she gain access to my database through an API other than the buttons etc I provide with them with?
It's not hard to reverse engineer the contents of the IPA file to get both the configuration you provided, and also see what the code is that queries the database. The IPA file can be obtained pretty easily - there is not much protecting that, given the user effectively has full control over the device (e.g. jailbreak). Given that information, it's possible to simply invoke the public Firestore REST API to not just duplicate all the operations in the app, and but invent operations of their own.
Scenario:
I "control" two different apps, App A and App B, both which the user has installed
App A is running
App A needs to obtain a string that was set by App B when App B last ran.
After obtaining the string, App A will still be running
User should not receive any feedback this communication is happening. E.g. no "switching animations" between A or B, no pop-ups, etc.
Constraints:
Apps are released under different vendors
Apps are already in the app store; updated versions will have this communication ability.
It is acceptable for the data stored in App B to be accessible to other apps on the device.
It is not acceptable for the data stored in App B to be visible to general third parties (e.g. if an external server is used, there needs to be some sort of secured scheme)
The data read should be able to occur immediately upon App A being opened after install. For instance, I cannot require the user of App A to enter log in credentials for an external communication service.
Must work on non-jailbroken devices.
This is seeming rather difficult to pull off in iOS7. Help is appreciated.
Tricky work around. Not recommended, but it will get the job done if you can't afford servers.
On the first app create a contact in the user's contacts book. Give it a generic name like "000 - NameOfAppB Data - Don't Delete" (I start with "000" so it goes to the bottom of the users contact book so they never see it, I also add "don't delete" so if the user does somehow find it they don't delete it hahaha) (who looks at contact books anyways). In the contact info under notes add your NSData in string format.
Then when app A is opened search for that contact, read the data, then delete the contact.
Apple does allow you to create and delete users contacts without their permission. (At least in 2011 they did, this may have changed).
This might serve your purpose
https://developer.apple.com/library/ios/documentation/Security/Reference/keychainservices/Reference/reference.html
I am not sure of its limitations though, i have seen implementations where credentials have been shared between apps.
Disclaimer: I am new to Windows Store App development.
My app is a Windows Store App (for desktop). The app has to create some content using user's input and the data can be considered as documents. Also, the document'd be in a proprietary format. The user should be able to see all those documents listed inside the app every time he launches it.
My question is where to save these document files. I have no issue it is directly accessible to users without using app (it is their data).
The document suggest roaming (limited storage) and local storage. But both are deleted once the app is deleted (bad for the user).
http://msdn.microsoft.com/en-us/library/windows/apps/hh464917.aspx
Document also states that accessing right for My Document folder is granted only if the developer is a company (bad for me).
http://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx
Any other popular pattern from developers (apart from Azure, SkyDrive and any online storage)?
On app's first launch, you can allow the user to choose his/her folder as per choice, and then add that folder in future access list. So you can access that folder anytime. Please check below given links.
How can I save a StorageFile to use later?
Exploring WinRT: Storage.AccessCache
Windows.Storage.AccessCache Classes
I am developing an app that sends data from the app to an sql server. I have read in the App Store guidelines (point 2.6) that "Apps that read or write data outside its designated container area will be rejected". Does that mean I will not be able to do this?
I'm pretty sure they're just referring to the designated "sandbox" each app is assigned to. Each app has their own documents directory to save local files, and I believe they're just warning you not to attempt to write outside of this (if you were even able to on non-jailbroken devs). They also don't want you attempting to access other apps that you don't have permission to access.
I've had several apps go to the store that write to and read from Google App Engine servers and they've been accepted with no problem. So I think you'll be good to go saving data to your own server.