All that I have researched integrating Dropbox iOS SDK requires logging in to authenticate/authenticate a user.
But this is what I want to accomplish
Use only one user account. (Without authorization)
Create a random public folder(in same account) and upload files to that folder.
Get the folder link.
It's basically sending generated files from the app to an account.
How can I possibly do this?
The API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files. However, it is technically possible to connect to just one account. The SDKs don't offer explicit support for it and we don't recommend doing so, for various technical and security reasons.
For example, any user who extracts the access token from your app will be able to read every file in the Dropbox account, delete everything, replace it, etc.
However if you did want to go this route, instead of kicking off the authorization flow, you would manually use an existing access token for your app. (Just be careful not to revoke it, e.g. via https://www.dropbox.com/account/applications.)
Related
When I sign in an app via Dropbox, it says:
ABC would like access to its own folder, Apps › ABC (emphasis mine)
This is to sign, that the app, ABC, can access only its folder.
However, this folder is normally visible in the Dropbox directory and synced.
Is there a way to achieve this with Google Drive? It seems like using the app-specific data feature prevents users from using the directory in any way except the app. Granting a permission to use the whole Google Drive gives the app way too much permissions. Dropbox has this feature done well. IS there a way to do a sing-up process this way with Google Drive?
When your ABC app calls Google Drive APIs on behalf of a user, you're going to be using oAuth to authorize ABC. From Drive API v3 docs:
The details of the authorization process, or flow for OAuth 2.0 vary somewhat
depending on what kind of application you're writing. The following general process
applies to all application types:
When your application needs access to user data, it asks Google for a
particular scope of access.
Google displays a consent screen to the
user, asking them to authorize your application to request some of
their data.
Google Drive's resource authorization scheme includes a number of "permissive" scopes where your app can (for example) request access to the user's entire Drive and "narrow" scopes. In the latter case your app is restricted to certain Drive files and/or folders. In late 2018 Google announced Project Strobe that promised to tighten restrictions around "permissive" scopes for many Google services, including Drive. In May 2019, they rolled an updated policy for Drive APIs:
With this updated policy, we’ll limit the types of apps that have
broad access to content or data via Drive APIs. Apps should move to a
per-file user consent model, allowing users to more precisely
determine what files an app is allowed to access. This means that only
certain types of apps can request restricted scopes from consumer
Google accounts. As always, G Suite administrators are in control of
their users’ apps.
The more user-friendly, narrower scopes are tagged and referred to as Recommended throughout Google API docs. For Drive you have 3 recommended scopes :
https://www.googleapis.com/auth/drive.appfolder Allows access to the
Application Data folder
https://www.googleapis.com/auth/drive.file 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.
https://www.googleapis.com/auth/drive.install Special
scope used to let users approve installation of an app, and scope
needs to be requested
Your use case could fall into either drive.appfolder or drive.file scope. drive.appfolder works well if you're looking to store app-specific data that the user won't and shouldn't touch:
The application data folder is a special hidden folder that your app
can use to store application-specific data, such as configuration
files. The application data folder is automatically created when you
attempt to create a file in it. Use this folder to store any files
that the user shouldn't directly interact with. This folder is only
accessible by your application and its contents are hidden from the
user and from other Drive apps.
The application data folder is deleted when a user uninstalls your app from their
MyDrive. Users can also delete your app's data folder manually.
drive.file is applicable if your use case has to do with some data being created by your app on behalf of the user and the user or other users should be able to see/edit/share these documents. The issue with drive.file is that it only applies to "objects" your app creates. If your ABC app creates folder Foo and then creates some files within that folder, your app will be able to access the folder and these and only these files.
With drive.file there's no parent/child ownership semantics and no propagation of permissions from parent to child. The user (in their own browser without your app) could create more files in the Foo folder but your app won't be able to read them.
It's worth noting that drive.file is not granting access to a particular folder...but it sort of amounts to an equivalent end result for a to-be-created (by your app) folder or folders.
If you're looking for a way to get access to an existing folder, you may want to look into one of the Sensitive or Restricted scopes. Using one of these scopes requires your app to go through a security review.
Most apps only have permission to store data in the Application Data folder
There is more information about API permissions at About Authorization
The drive.file scope might work for some since it appears to give access to individual files that the user OK'd. How does the user OK a file? According to the post below, they would send a file from the Drive app to my app.
So, unlike Dropbox or OneDrive, Google Drive has only 2 types of permissions: Drive or Drive.File. Simple!
I am trying to create an IOS application. Part of it will allow upload of data to a Dropbox account that is hardcoded. I don't know how to do this part of my app without having a webpage show up that asks for authorization. Are there other ways to authorize an account without asking the user?
Don't do this. You're asking for a disaster.
Violates the Dropbox Terms of Service.
What happens when Dropbox suspends your account, your app breaks.
An API key you hide in the app could be compromised and exploited.
Look into another service intended for what you actually want to accomplish, Amazon's S3 is likely a good choice.
I am working on integrating dropbox with iOS application. I want to implement below functionality.
User can share his existing dropbox file with app.
If user modifies any of the files, i should able to fetch the updated file and notify app server.
Also these files are not app related ones. User can share any docs in his dropbox account with app
After going through API, i found that i can use dropbox chooser UI to share files. chooser is generating temporary URL which i can share with my server to extract the file from dropbox.
But to get the modified files, i have to integrate with OAuth permission to run delta query on dropbox account. Here i am struck with two parallel functionalities chooser and OAuth which seems not related to each other. Even while asking OAuth permission also, dropbox taking to web url to grant permission instead of showing already logged in user on iOS.
How do i verify both chooser account and OAuth granted account are same? How will i show dropbox chooser(of OAuth connected) when user wants to add any file to app?
Correct me if i am wrong in understanding dropbox API. Also let me know if i have to provide more details.
I have about a site with about 50 customers. They each have a user profile. They want to be able to automatically include their images which they store on DropBox in their profiles.
My idea is to make a Dropbox api that scans their folders (with their permission) and just include the images in their profile. I already know how to link directly to their images as long as I have the url.
I set up the Ruby API. Only question is : Do they have to authorize my app every time I try to access their images?
I want to somehow store authorization information for each client, then just reuse that info and access their images through the Ruby API. Is this possible? How is it done?
I think if I can just get past this authorization hurdle I can take care of the rest.
You can definitely do this. Just store the access token at the end of the OAuth flow and reuse it. From https://www.dropbox.com/developers/core/start/ruby:
The access token is all you'll need to make API requests on behalf of
this user, so you should store it away for safe-keeping (even though
we don't for this tutorial). By storing the access token, you won't
need to go through these steps again unless the user reinstalls your
app or revokes access via the Dropbox website.
I'm trying hard to get my mind wrapped around how you would be able to store files in the cloud from an enterprise app without requesting the user to log in.
The background:
I'm developing an iOS app that will be distributed to certain employees in our company. As of today we already have an app that uses an FTP server to upload user created files. In this new app, I would like to skip the FTP server and instead use some sort of cloud storage (DropBox, Google Drive etc.)
The users will upload some files (around 1-2 uploads per day) to the cloud service, and people at our HQ will be able to look at these files.
I don't want to have each employee create a personal cloud drive account that would be linked with a "master" account. Rather, I want this specific application to always upload it's files to the cloud storage "master" account. Is this even possible?
Since only our employees have access to the app, I don't see the security factor as limiting. The information sent is not of use to anyone else than our company (no high-security stuff).
Is it possible to "hard-code" an OAuth token that corresponds with a certain account that the app always uses? Are there other possibilities that I'm not aware of (other than FTP or cloud storage)?
Any help will be appreciated.
Regards,
Jens Nilsson
how about use one dropbox account and hard code it in your app? then your enterprise user can upload their files respectively. surely you need do some trick to make no any file with duplicate name.
i am developing one iOs application that uses a parse cloud service to upload user generated files.
in that parse service, user dont need to create a account separately.each and every user can be able to uploads files to cloud where user can be able to visit all the files which is in the cloud which is created by some other user.
suppose if we want limit some user files accessibility or upload files privilege also we can achieve that through using the parse.
i just remember parse is not open source.