views:

317

answers:

2

(I tried asking this on the GAE forums but didn't get an answer so am trying it here.)

Currently to upload blobs, the app engine's blob store service creates a unique one- time URL that a user can post blobs to. My requirement is that I only want authenticated / authorized users to post blobs in my application. I can achieve this currently if the page that includes the multipart form to upload blobs is in my application.

However, I am looking to providing a "REST API" for my users to upload their blobs. While it is true that the one-time nature of the upload URL mitigates the chances of rogue use but it's still possible.

I was wondering if there is anyone on the app engine team here that can consider a feature where developers can register an upload listener. (Or if there is already a way, I'll be all ears). A standard servlet filter could also potentially do the job. This will give us an opportunity to authenticate / validate / decorate requests before the request gets forwarded to the blob store service.

Thanks, Keyur

+1  A: 

Since, as you point out, it's only possible to upload blobs if you have a valid upload URL, you can simply issue valid upload URLs only to authorized users. The only way an unauthorized user could then get an upload URL would be if an authorized user gave it to them, or it was intercepted - and in either case, the same caveat would apply to regular credentials.

In any case, it's still possible to check a user's credentials after the upload, at which point you can immediately delete the blob if you're not satisfied. If it were possible to regularly upload unauthorized blobs, this could lead to a denial of service vulnerability, but due to the restrictions on handing out the encoded URLs I mentioned above, this is only likely to apply if, for example, a user's access was revoked after you generated an upload URL for them.

Nick Johnson
Thanks, Nick. I was kinda hoping that this was not the answer but I think I will live with it :)As you mentioned, yes, I'll be handing out the upload URLs only to authenticated users. But if the authenticated user himself was a rogue user who hands out the URL generated for him to someone else then we have a problem. I can of course delete the blob during post-processing as you mentioned but I was looking to see if I could reject it even before it was persisted in the blob store.
Keyur
If the authenticated user is 'rogue' and hands out the URLs to someone else, how will you determine that he did so? He could just as easily hand out his credentials, or his login cookie.
Nick Johnson
Yes he could hand out his credentials but if I could authenticate the upload URL, the upload will at least be in his name. Today once he gets the upload URL, he can upload blobs anonymously.
Keyur
There's no reason that has to be the case - just record what URL you gave out to what person. Alternately, when you hand out a URL, also hand out a hashed token, and refuse to accept uploads if the token isn't valid.
Nick Johnson
A: 

I'm not sure whether it would work (i.e. GAE might not let you do it), but a servlet filter which wraps the /_ah/upload pattern could first check whether the POST came from same IP address as the authenticated client.

Richard Nichols