I plan to create a package which contains a Google Drive integration. Our customers can install this package on whose IIS (asp.net) to use it in the web-application. Client-ID und secret should be allways the same(our data). We have also running multiple web sites with this packes. The redirect-url is allways differen(subdomain/domain/directory of customers/our sites.
Which API-Type do I need?
With Client ID for web applications, I have to note every URL of customers and our sites.
Is there an example with asp.net (without VMC but propably vb.net) and the Google Drive API (DLL)?
I've seen a lot of notes but in the most cases, the URL etc. are created manualy.
Best regards
Christoph
Make sure that client ID, client secret secret and redirect URI are configurable with a config file and for each deployment provide a different file.
Related
I'm following the Design Automation API v3 tutorial for Revit.
When doing a workitem post I'm a little unclear about the "rvtFile" and "result" arguments. Can the rvtFile url be in an aws bucket? Also what are the restrictions for the result website? It states that it needs to be a signed url, but can this just be another aws bucket? Or do I need to create a website? (Note: I've never done any web development. Everything I know i learned from this tutorial)
Since Design Automation for Revit runs on cloud (and not your local machine), it needs a way to download your input files. You may put your files on any of the storage service providers (say Amazon S3) and provide direct download links to it. For Design Automation to have access to it, you will either need to make those files be public urls or keep them private and generate a signed url for it. When DA4R runs your workitem, the direct download urls provided in the workitem payload will be called to download your files to the worker machine.
Design Automation also does not store any of your result files. So, you will have to generate a signed url for uploading them to appropriate cloud location(s) (say a location in Amazon S3 bucket).
While Amazon S3 is just an example, there are several other storage providers. I also recommend reading Autodesk Forge's Data management APIs:
https://forge.autodesk.com/api/data-management-cover-page/
EDIT:
Useful links
Tutorials: https://learnforge.autodesk.io/
AU Class: https://www.autodesk.com/autodesk-university/class/Revit-Data-Forge-How-Can-Design-Automation-Revit-API-Help-Me-2018
I wonder if my Google maps API key is safe the way I use it now. Because I have a Cordova application with Google maps, I have generated an API key. I cannot white-list the key to my domain, because it runs client side on the phone.
Also my API key is visible for anyone who unpacks my app and read the index.html, or listen to the web requests that the app makes.
Is there any way to protect my API key? And if there isn't, it is safe to use Google maps, or any other third party API that uses a API key for authentication?
I see two possible solutions to your problem. Both of them I have already personally implemented (not with GMaps though) but still have some downsides.
(1) You can use a backend technology to add in API keys to your requests. For this it is advisable to use a combination of something like Apache2 mod_proxy and mod_rewrite. In your application you then use URLs that point to your proxy server i.e. https://yourserver.com/js/googleapis/maps/api/js and make mod_rewrite this URLs to something like https://maps.googleapis.com/maps/api/js?key=API_KEY
A rule for mod_rewrite (not tested) could look like this:
RewriteCond %{QUERY_STRING} ^$
RewirteRule ^/googleapis/maps/api/js (.*)$ https://https://maps.googleapis.com/maps/api/js?key=API_KEY
I think you get the idea. The big advantage of this approach is that you can completely hide your private information on a server you control. The downsides are: If your app causes high traffic you will most likely experience high traffic on the proxy machine. Further if attackers figure out the URL to your Google Maps API proxy endpoint it will be easy for them to retrieve the GMaps API through your service.
(2) The second option would be to create a service to retrieve your API keys. Assuming your application already needs some form of authentication anyways you cold go a road where the API key service hands out the API key only to registered and authenticated users.
Both approaches will have their downsides regarding better tooling for debugging mobile-web applications. I.e. an attacker using MacOS, XCode and Safari on a desktop could establish a debugging session to your Cordova application and step debug the JS code that runs inside your App. Which means whatever stretch you make in the Cordova arena it is quite easy to attach to your App and read variables.
No credit to comment on accepted answer but personally, I'd go for the 2nd option suggested by Matthias Steinbauer. However, his concern about an attacker debugging your Production app doesn't apply to apps built with a Distribution Provisioning profile (such as required when submitting to the App Store) - only apps signed with a Developer Provisioning profile. The same goes for Google Apps too. IF it were possible to just debug a prod app, then say goodbye to security.
Having said that, an App's static content can be viewed by others (since app is just a zip file) - so don't hard-code any keys or security info.
Personally, I'd also obfuscate the source when building prod version.
Hope it helps
I reviewed the Box authentication documentation as well as the other StackOverflow questions but I'm still unable to find definite answer.
My client is an enterprise Box client and would like to build a company's internal web application that would login into Box.com using service/admin account and create folder and upload a file. The uploaded folder will be available to specific customer that will login into Box and upload additional files.
I created a sequence diagram to depict the same.
Would you let me know if this is a supported Box authentication model? Can the Box 2.0 Beta API Token be used to login as service account and create file/folder/share?
Thanks for your help!
There are several options that could work for you. Let me suggest the simplest one first, and if that is not sufficient, then I can suggest other ways to accomplish your goal.
You can use the regular Box authentication for your solution. To do so, simply get an API key and an auth-token for your application. Then, after you have uploaded your file, use the V2 API to create a shared link for your file. You can email that shared link to the client, and they can use the link to access the file.
there has been new developments since this question was posted, and now it's possible to use JWT (JSON Web Token) and Box Developers Edition to access Box.
If you create a developer account you will be able to create App users and login using an enterprise id and a private key file. Check out the docs for more information: Box Developer Edition
Additonally, boxsdk comes with support for Box Developer Edition
I would like to build an external asp.net mvc application that has the following features:
The application is accessible via its own domain such as www.itsowndomain.com
The application has access to one Google account (such as itsownaccount#gmail.com) where all the files are stored in the Drive folder. So the users of the application should not have to log into their own Google accounts in order to access the files from this application. The application needs to have automatic access to this (itsownaccount#gmail.com)'s google Drive, that process should be transparent to the user, they should never have to authenticate themselves, its should all happen in the code in the background when the application loads.
The application will use Google Picker to list the files that are in (itsownaccount#gmail.com)'s google Drive folder.
My questions are as follows:
Is what I am trying to do possible, basically using Google Drive as a storage of files and downloading them, uploading new ones and possible editing some from an external application?
Can I use one account because all the files should be publicly available so I do not want users to have to be thinking about authentication in a site just so they can view publicly accessible files?
How do I go about implementing this, is there a tutorial because the ones I have looked at all differ as they mostly try authenticate each user with their own Google account?
you can use Google Drive as the storage solution for your application, check the Google Drive SDK: https://developers.google.com/drive/
Google Drive application usually rely on the users' accounts to store their files, but nothing prevents you from using your account to store all files and make them publicly accessible
there's an ASP.NET MVC tutorial and sample app at https://developers.google.com/drive/examples/dotnet, however, it authenticates each user with his own account. You can start from it and replace the standard OAuth flow with one that always uses your credentials, for instance, by always using a Refresh token that you generated in advance and provided to the app.
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.