Dropbox makes it really easy to share folders and their contents with others and to control their access rights. However, from what I can tell this capability is reduced to a "share link" (which turns out to be a read-only link) if the folder happens to be an "App" folder. However, there appears to be a simple way around this - instead of restricting the API token permission to a single folder you simply set permission type to "Full Dropbox" and bingo - you can share folders.
Whilst the Dropbox API console and web consoles do not appear to complain when I do this I have not then gone one step further and tested that
The users with whom I share folders in this way do indeed have read write access
I can track changes to shared folders via the Dropbox API using web hooks
I'd be most obliged to anyone who has been here already who might be able to clarify.
That's correct. Currently, Dropbox app folders are incompatible with (read/write) shared folders, meaning you can't share an app folder, put a shared folder inside an app folder or put an app folder in a shared folder.
Instead, if you need to use the API with shared folders, you'll need to use "full Dropbox" permission, as opposed to the app folder permission. You can find more information about app permissions here:
https://www.dropbox.com/developers/reference/devguide
If you've already registered an app using the app folder permission, you can register another with the desired permission at:
https://www.dropbox.com/developers/apps/create
Using a full Dropbox app, your app can interact with shared folders just like any other folders.
Related
I am developing a mobile app (in Flutter) that can read and write files in a specific folder in the user's Google Drive.
Users can also manually upload files to this folder and the app must have access to these files.
So far, I am using drive.file scope and did not manage to have access to the files that the user has uploaded manually.
Do I need to use drive scope?
Is there any way to use the driver picker in my app and grant full access to a folder?
I would prefer to use drive.file scope. (The difference is that 'drive.file' only gives you permission to files that your app has created or the user has explicitly shared with your app). But I don't know how to explicitly share a folder with my app.
The https://www.googleapis.com/auth/drive.file scope allows you to give a per-file access to files which have been created or opened by your app. Therefore, if the files have been upload manually and not from your app, this scope won't give you the access you require.
As for sharing the files with your application, you might find useful the example listed here in order to prompt a user to share the files wanted.
Reference
Drive API v3 Authenticate Your Users;
Google Picker API.
I have a React app running on google cloud run, with user authentications and permissions.
Now I would like to write documents for the app. The documents will be a static site holding at google cloud storage.
In the app, users with different permissions can access different routes of the app, and it would be great if the permissions work for documents too.
My untested solution is to control user access to the app routes, and certain route renders a page, that containing an <Iframe> which retrieves the documents and then display it.
My question is: is it possible to restrict access to the static site, to allow only access from the react app holding at cloud run?
Or is there any suggestion about access control of app documents?
"documents" were supposed to be html files converted from markdown files. They're documentations about what the app is and how to use the app.
And I don't want the part of the documentation about "admin configuration of the app" to be seen by users with regular authorization.
Holding the documentation as a static site is simpler. I can use gitbook (or other tools) to render the markdown file. Managing & rendering the styles of the markdown files in React would be a little painful.
I'm still working on my English. Sry about the confusions.
You can restrict the access to a static website in Cloud Storage by creating a redirect.html like it is posted in the second answer of this question. The complete medium post is located here.
This will work considering that the authentication from the static website will be separated from the Cloud Run authentication. As it can be seen here the permissions a user has will need to be defined for every object. There you can control if a certain document can be viewed by a specific user email.
If the serving of the Cloud Storage documents needs to be dependent on the Cloud Run authentication, then creating short-lifetime signed urls is an option. This is a python sample program to create signed urls and here is the description of what a signed url does.
I'd like to create a GitHub app to display the current issues in a repository, organized by labels. The repositories under the organization are private, but my account has admin access. I've installed the app under my name. The API list-issues-for-a-repository is returning:
{
"message": "Not Found",
"documentation_url": "https://developer.github.com/v3/issues/#list-issues-for-a-repository"
}
I've set the app permissions as follows:
Repository permissions
Issues - Read-only
Metadata - Read-only
No access for everything else
Organization permissions
No access for all
User permissions
No access for all
Subscribe to events
Unchecked for all
Getting all the repos using /orgs/«org»/repos returns an empty array, meaning the private repositories aren't showing up, so there's likely a permission issue going on here, too.
Questions:
Do I need to install the app under the organization? The organization is not showing any installed apps, even though we're running Codacy and GitHub Desktop.
The app is not under the organization's Third-party access policy. Do I need to add it? I don't see any way to request permissions, and I don't know if GitHub apps work this way.
Do I need to include more permissions for the app? I just need read-only for the issues and don't want to expose more than I need.
First of all, confirmed it has to be a "GitHub App" and not an "OAuth App", because the API to list the issues in a repository is, according to the documentation, available only to GitHub Apps. I took an initial wrong turn, documented in the edit history of a previous related issue, of selecting an OAuth App, and getting nowhere.
As far as my specific questions:
Do I need to install the app under the organization? The organization is not showing any installed apps, even though we're running Codacy and GitHub Desktop.
Yes, it needs to be installed or added under the organization. It was easier for me to delete the existing app under my account, and re-add (vs re-install) under the organization.
The app is not under the organization's third-party access policy. Do I need to add it? I don't see any way to request permissions, and I don't know if GitHub apps work this way.
Once the app is added under the organization, it is automatically given access. You can fine tune which repositories it can access or let it access them all. Installing, as opposed to adding, might need a few more steps, and the app needs to be published first. My app is intended for the organization only, so I opted for the simpler solution. Also, even if you give the app access to all repositories, the access rights of whoever logs in take precedence. For example, someone outside of the organization won't see any private repositories.
Do I need to include more permissions for the app? I just need read-only for the issues and don't want to expose more than I need.
No, just read-only for issues, meta-data is included automatically.
With these revisions I was able to access the repositories, and also get results for list-issues-for-a-repository.
This is what I want to do, in AEM, there are some sensitive PDFs links on the page. So when people click these pdf links, I want to let the user to login first. After that, they can view these PDFs assets. Right now, all the PDFs are in the DAM. I may need to override some OTB pages that load the assets, but I just can't figure out which page I should override...
Can someone shed some light on this?
Thank you
You need to configure privileges of users on assets folder, or specific asset folder. Read more about users preveleges here
The AEM term is CUG or "Closed User Group" for resources that require authentication to access. Anonymous users requesting a resource in a CUG will be redirected to the login form (which you can also modify).
https://docs.adobe.com/docs/en/cq/5-6-1/howto/create_apply_cug.html
https://docs.adobe.com/docs/en/aem/6-1/administer/security/cug.html
(depending on which version you are working on).
I am running into a difficulty with the picker api for users who have installed our Chrome Web Store app, but who have not yet enabled drive. For users in this state, it is possible to save new files using the files/insert api, which returns a successful response, but these files do not show up in picker. Once the user enables drive, all the files they have previously saved begin showing up in picker.
Is this behavior intended? If so, what is the best way to determine if a user has drive enabled, so that we can prompt users to enable drive instead of making it look like we're not saving their documents?
Currently, the picker and the API will only work if the user has installed your Drive application ont he Chrome webs Store.
We understand the pain involved for developers and we are looking to relax this restriction.
In the mean time there is a way to check if the user has installed the Drive app, for that you need an OAuth 2.0 access token (so your user will need to have gone through the OAuth flow and authorized you to access his Drive data). Then you can simply try to read a file with a bogus ID (lets say ID "000" or "abcdefghijklmnopqrstuvw"). If the API returns the error "403: The authenticated user has not installed the app with client id {clientId}", that means that he has not installed the app yet and that you should hide Drive functionnalities and probably show him something that say "To take advantage of our latest Google Drive integration/features, we recommend that you install our Drive App link to Chrome Web Store listing".
If the user has your Drive app installed you will get a "404: File not found: {fileId}" error on this request.
First it is odd that the picker is not showing files for your non-drive enabled user.
So I just tested the picker with a non-drive account and everything worked as expected... For instance you can try with the Balsamiq Drive app https://chrome.google.com/webstore/detail/pplbmgaodhjmbklkgkgmlghaekcfhhkk They are using the picker in Mockup > Open...
After installing you have to go to https://balsamiqgdrive.appspot.com
I created a mockup first and saved it. It appeard in Docs. Then I tried the picker in Balsamiq and I could see it.