I'm working for an app that needs to transition to V2 support.
In V1 there was a sandbox option, where Dropbox would create a directory for the app under the apps/ folder.
I'm not seeing this option in V2, though I could just be mistaken. But while before, many of the requests supported a “root” parameter, that no longer seems to be an option.
So has this been disabled or is there simply a different way of going about it?
Yes, Dropbox API v2 still supports the sandbox, a.k.a. the "app folder" permission. The permissions are documented here in the developer guide.
Dropbox API v2 no longer uses the "root" parameter, where you would explicitly specify sandbox. API v2 automatically detects this from your app registration.
Related
I need to access the active version on SAP Cloud Platform of HTML5 apps through an api.
I know for the java apps you have the lifecycle api: doc
But you can't access HTML5 information with this API.
What I found is this service: https://account.hana.ondemand.com/ajax/getHtml5AppDetails/{subaccountName}/{appName}
This will return a JSON string with the required info, but I'm not authorized to access this page, although I have all the possible admin rights.
So I'm wondering If any of you has any idea to solve my issue, and other people's issues.
Well, we needed something similar and used this kinda hack to get the active versions via WebIde Api (need basic Auth to login) replace XXXX with your account
https://webide-XXXX.dispatcher.hana.ondemand.com/api/html5api/accounts/XXXXX/applications
You get back a json array with all your applications of that sub account, including active version and other interesting information
Hope it helps ;))
Regards Mathias
You could create a HTTP Proxy Servlet based on https://github.com/SAP/cloud-connectivityproxy that provides read only access to https://dispatcher.hanatrial.ondemand.com/hcproxy/b/api/accounts/<subaccount>/applications/<app> for your app.
Our windows desktop application (based on Java Swing) has a functionality to publish on the user's Facebook account (all properly implemented using RestFB library).
While this works perfectly in Facebook's sandbox / test mode, we would like to go to production and need thus to have our application approved by Facebook (as the application needs publish_actions permissions).
To apply, Facebook requires to indicate the platform and, for Windows, it also requires a "Windows Store ID" and a "Windows Phone Store ID" which we don't have as our application is not available on Windows store (and it is not meant to be).
What should we do to get our app approved? Are we missing something?
(I understand that this is not a pure coding question but it is probably relevant for many developers)
Thanks,
Thomas
I came across the same problem. In the past it was no problem to register an app on facebook, set the scope and get the permission by the user to upload images or videos.
But at the moment at seems they will only support Windows (Metro) Store-Apps.
See Bug: 'Submission of Desktop-Apps won't work' on facebook
The first response of the support seems to be final :(
I'm using Google Apps Provisioning API with gdata-java-client to manage Google Apps domain. https://developers.google.com/google-apps/provisioning/
Since Provisioning API is deprecated now, I'm considering to migrate to new Google Apps Directory API with google-api-java-client. Looks like the most of functionalities of my software can be migrated, but I couldn't find how to set "emailPermission" of the group settings. https://developers.google.com/google-apps/provisioning/#creating_a_group
It sounds like Google Apps Groups Settings API would be it, but it has far more high-functioning than Provisioning API do and I don't think these are equivalent.
Is there any equivalent API for Directory API/Admin SDK?
With the Admin SDK Directory API, service-specific settings/attributes were left to service-specific APIs, thus the Group Settings API is the correct method to set group settings.
To get an idea of how the Group Settings map to the old provisioning API group permissions, try creating a group with the provisioning API for each of the permissions, then use the Group Settings API to GET that group's settings and you'll have a map of the settings each of the old permissions defaulted to.
I'm working on a Google Drive interface for Emacs. The concept is that Emacs could provide a platform-agnostic way to load, modify and save text documents stored in Google Drive. I've registered my app and can authenticate with OAuth2 and get a file listing with the Docs List API, but when I try to execute an Insert with the Google Drive API, I see an error:
"The authenticated user has not installed the app with client id ..."
Reading further, it seems I need to publish my Emacs application in the Chrome Web Store to get access to the Drive API. That doesn't make sense to me...I noticed that there is a FUSE project in development for Google Drive, which suggests that native development is possible. When I skimmed the code, however, I didn't see a Chrome Web Store component to getting it working.
Am I trying to misuse the API, or is there an route to make this work that makes more sense?
EDIT:
According to Ali Afshar, of the Google Drive team, installation is no longer required to use this API. So what follows may no longer be relevant, but will be left for historical purposes.
So, first off the API does not support application development in the sense that we are both doing it, I wouldn't use the word native though. The good news is I have been doing some research and Google Drive is really just a rebranding of Google Docs. So the Google Docs API could be a good choice as well for the same purposes.
Anyway, here's the steps to solve the error: "The authenticated user has not installed the app with client id ..." Which is a 403 error, for the sake of this answer. These steps assume you have set up an app in the chrome web store as is required, and installed it. I am working on my local machine too, with my project: http://github.com/tom-dignan/gdrive-cli which I have gotten past this error, so I think you should keep plugging away at your emacs version, because I think we can make this work.
a. Open the Google APIs console.
b. Confirm you've already enabled the apis under "API Access" both the API and SDK for Google drive should be enabled. There you get your client secrets/api keys and such. I am almost positive you've done this already, so go ahead to C. (this is here for others who may have missed it)
c. In the left navigation bar, under "Drive SDK" you will need to do the following:
Add a "Support URL" (required)
Add at least a small 16x16 application icon (required)
Add "OAuth Client ID (Required)" under Drive Integration (I was just tinkering and this seems to be the key field.)
Add "Open URL (Required) URL to open for your app from the google drive UI."
Check off "Multiple File Support"
Add some MIME types and file extensions, "text/plain", and txt for example
Add the the auth scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
Don't bother trying to add the auth scopes for Google Docs here, because it won't work. Google does not want us to use it that way because files that drive apps create should be private to that app. Integration with Google Docs will have to be separate.
Now I know you must be thinking "why do I have to add some of these..." It's because the form makes them required fields. In mine, I put a couple URLs that point to static HTML pages.
Once you've done the above, clean up your state and reinstall your chrome app. Then try your code again, and it should stop giving you a 403.
I see everywhere that google plus api is readonly. But i saw this app screenshot.
How did they do then? Even the docs say its read only.
The API is indeed still read-only. We worked directly with SXSW on this year's mobile app to enable sharing... it's not a feature that is generally available at this time.
The note at the top of the REST API documentation page seems to answer both questions at once:
Note: The Google+ API currently provides read-only access to public
data. All API calls require either an OAuth 2.0 token or an API key.