Google App Engine : Read from Google Cloud Storage - java

I have a Flex/Java application on Google App Engine and all I want is to load large images from Google Cloud Storage using URLRequest in Flex. I'm sure this is simple but I can't get it to work. I will manually upload the images using the Google APIs Console so I don't need to write anything from the App. The images can not be public.
I'm not 100% sure how to access the file so this may be the problem. I tried these:
"/gs/mybucket/myimage.jpg" : not found
"/mybucket/myimage.jpg" : not found
"http://commondatastorage.googleapis.com/mybucket/myimage.jpg" : denied
I added myappid#appspot.gserviceaccount.com in the Team tab in Google APIs Console with Can View permission and I used GSUtil to get and set ACLs on both mybucket and myimage.jpg to add a READ permission for myappid#appspot.gserviceaccount.com but that didn't help.
What am I doing wrong?

I'm not really sure how flex works or how it is trying to access the blobs.
However, if you want to respond to a http request with the content of a Google Storage object then you can use the serve method.
https://developers.google.com/appengine/docs/java/blobstore/overview#Serving_a_Blob

Are you authorizing the URLRequest call with an OAuth token? If not, then even though the request is initiated from an app engine app, it'll look to Google Cloud Storage like an unauthenticated, public read. I don't know if flex has a trace option but if there's a way to examine the request details, I'd check to see if you're setting up the proper authentication.
If it turns out to be too difficult to get flex to play nicely with OAuth, you could also use signed URLs (a.k.a. query string authenticated URLs). This gives you the ability to create a URL with a special signature that implicitly conveys your authorization but only people with that link can access the object. The object's ACL can be be set to disallow public access but your signed URLs will be able to read the object. You can also time limit a signed URLs, if you like. Here's the documentation on how to use this technique.

Related

Authenticate to autodesk

We are developing a Java application that is supposed to show models from users store.
initially, I'm trying to allow users to login using their autodesk account, and check if they are entitled to access my app.
I couldn't find any good example to show how it is done, I just want to confirm that what I will be doing is the recommended thing or if there is better options.
First, on app start, I will show an embedded webbrowser that will open
"https://developer.api.autodesk.com/authentication/v1/authorize?response_type=code&client_id=XXX&redirect_uri=XXX&scope=XXX"
the app will get the url from our server (so not saved locally) and the call back is pointing to an api on our server. then as user login and consent, will get the code from the url, close the login dialog and continue to get the bearer token using plain rest apis to /authentication/v1/gettoken.
As I said, not 100% sure if this is approved way or not or even if it is doable or not. so thought to check before we implement it.
After that I will just use rest apis to browse and get the model.
any thoughts or complains ?
Thanks in advance
Rest assured that the workflow being proposed here is actually orthodoxical and well “approved” by our official tutorials:
https://forge.autodesk.com/en/docs/oauth/v2/tutorials/get-3-legged-token/
http://learnforge.autodesk.io/#/oauth/3legged/
Unfortunaly the code sample for that bit is in node and we are still working on a Java equilvalent
Some of our endpoints require 3-legged oauth to access personal data - see here for an example and you can always refer to the authentication context section of each endpoint for the oauth flow required.

Google Drive API Access my own account

I wish to run a simple process on my server/laptop that will upload files to my google drive on a daily basis, once a day. I don't wish to share this, allow other users to use it etc.
All examples I find seem to involve browsing to an address to gain permission from the user (me) and then getting an auth code etc and proceding
ref: Java quickstart
Is there a way/example to do this without need of a browser, getting permission getting unique auth code each time as I only want to do this for my account?
Can I use a bash script with CURL commands rather than having to use Java?
Yes. See How do I authorise an app (web or installed) without user intervention? (canonical ?)
Yes. It becomes a complicated script if your file is large and you are doing resumable uploads, but for small files it's perfectly feasible. You'll need to play around a bit to get the correct encoding, multipart mime body, mime type and content size, but it's all eminently doable. You'll start by calling Google's auth api with your stored refresh token to get an access token. Then you'll set that access token into an Authorization bearer header as part of your content upload call.

Is there a way to do multi-part uploads to my S3 bucket on an android app without using the AWS SDK for android?

This might seem strange at first considering the easiest way is to work with the SDK, but it's not an option for me. The reason being, I'm actually building a Third Party API and allowing for the upload of files to my bucket.
The first person consuming my API is an android application and I'd like to get some idea as to the best way to make this possible.
I can't give 3rd party developers my AWS credentials.
I've authorised this on my website with Cross Origin Resource Sharing and signed requests. Is there a similar way to do this on android?
Ideally I'd like the flow to be:
3rd party app sends me the file info, key, etc.
my API service signs the request and sends it back.
The app then uses the request to upload the file.
Is this possible on Android?
I've read up on STS and creating temporary credentials, but that's still not nailing down permissions to a per-request level like the signed request method allows me to do.
You can use Browser based Form Upload feature offered by AWS for S3. Even though use case is described as browser upload, but it can be easily used by any http client.
Third Party Client (Android etc) calls your server to create a upload policy
Your server creates a signed policy by making AWS S3 API Call (YOu may use SDK to do that). This policy may allow upload for a particular key in S3.
The Android Client can submit the multi-part data using S3 key, signed policy.
Here is an example for HTML Form (You can easily use any http client to do for Android App) :
http://docs.aws.amazon.com/AmazonS3/latest/dev/HTTPPOSTExamples.html
This approach will only require your to share IAM Access key but not secret key.
Another alternative is to totally abstract S3 and let your server manage the upload:

Foursquare API usage: /venue/stats

I have couple of doubts regarding the usage and working of /venue/stats Foursquare API.
Q1. I would be using /venue/stats for getting information provided a venue id. So I have registered my app and got the client id and secret values. I went to Foursquare API endpoint and tried using /venue/stats api and I noticed a oauth_token generated automatically by FSQ so is this oauth_token the same token that I am required to use everytime I use this api ? Do I need to do the authentication steps mentioned ?
Q2. Try the api generates a link which has /simulate in the api URL. I assume that this is due to the fact that I am testing the API so FSQ has categorized such api calls as simulate calls. Please confirm my understanding. If this is so then whenever I use the api as mentioned i.e. /v2/venues/venue_id/stats I get an error JSON stating that I am unauthorized to view venue stats. Can you please tell me why ? If this is due to access_token issue then the same issue should have been with simulate call also ?
Hoping to get a reply soon.
Right underneath the API Explorer bar it says "OAuth token automatically added". You do not use this token. I am sure it is either temporary or created using your log in info if you are loggged in while using the API Explorer. You will still have to use the authentication process to get a valid access token. However, you can save this access token and use it again skipping the Auth process. An access token serves as a key unique to a user and app. Read more about it here: https://developer.foursquare.com/overview/auth
The simulate feature is used mostly for API calls that normally would require you to be a manager of the venue. There are certain calls that can not be done unless the app is by a user that is the manager or unless you make the call using an access token of a manager.

Is it compulsory to register our web application on Google Apps before implementing OAuth?

I am developing a Java application that needs to access personal account Google Data of a user. The development is currently in netbeans on my localhost. I am implementing 3-legged OAuth. And while sending Grant request, it sends me Unauthorized Request Token and then redirects to Callback URL.
While trying to access Access Token, it gives me Error "Error Getting HTTP Response". Now, as per it given in Google Documentation, it is given that "If the application is not registered, Google uses the oauth_callback URL, if set; if it is not set, Google uses the string "anonymous"." Does it mean that I must register my application on Google Apps Engine before granting authorization & accessing request ? Please Help.
For reference : OAuth for Web Applications, OAuth in the Google Data Protocol Client Libraries
Based on your question, it's probably not the registration piece that's causing you trouble. It sounds like you just haven't implemented OAuth correctly — not that doing so is easy. The OAuth process is roughly as follows:
Get a request token. You must pass in a bunch of stuff that declares what kind of stuff you want access to and where you want Google to send the user when they're done granting you access to that data. This is where you pass in your consumer key, which you get by registering. The consumer key will be the string anonymous if you are developing an installed application (i.e., mobile app, desktop app, etc). This is a work-around; the alternative would be to embed your client secret or RSA private key within the application itself, which is a very, very bad idea. If you use 'anonymous', you should absolutely be setting the xoauth_displayname parameter. (Actually, everyone should set this parameter, but it's especially important if you're using anonymous.)
Once you have a request token, you then redirect the user to the special authorization endpoint, passing along the request token key in the query string. Assuming the user grants access, Google will redirect the user back to the callback URL that you associated with your request token. The request token is now authorized, but it can't be used directly just yet.
Once the request token is authorized, you can exchange it for an access token key/secret pair. The access token key/secret can then be used to sign requests for protected resources, such as the private data in the API you're trying to access.
For web applications, registering is almost always a good idea. It makes it much easier for users to manage their access tokens and revoke them if your application misbehaves or if they don't want you to have access anymore. If you don't register, your application will probably show up as a fairly scary-looking 'anonymous' in that list. It's really only installed applications that you wouldn't want to register for. You probably also want to register for an API key. An API key will dramatically increase your rate limit and it will also allow Google to get in touch with you if your application starts to malfunction.
I'd link to the OAuth docs, but you've already found them. Hope my explanation helps!
If you're developing on your local machine, you'll continue to get the same result as above.
For more interesting tests, then yes, you'll have to register your app and push it to the app engine.
Google will check if the domainname of the return-url is registered. You could also modify your dns/host-file to point the domain-name you're using to localhost.

Categories