Origin Without Authorization

[Spent123]

Hi,

I'm wondering if it is possible to POST to a bucket, using either AJAX
or preferably URLRequest (AS3 - Flash) with CORS without having to set
the 'Authorization' header ?

It seems in my case (if I've understood things correctly) that setting
up a OAuth2 token is over kill as I have no need for getting user
info / having them login.. so on. The goal is to simple check if the
user is uploading to GCS from my domain's referral/origin and if so
allow the upload.

I guess I'm hoping the bucket's ACL can be set to FULL_CONTROL for all
users but have the CORS origin set to my domain.

Does that sound possible, or am I way off on how this stuff works ?

[Navneet (Google)]

Hi,

When you POST to a bucket, the method you follow is, in summary:

- The Authorization header is NOT required.

- You create the form (or the POST body if you're creating it programatically)

- One of the fields is a policy document that is only required if you bucket does not allow anonymous WRITEs. I think you'll likely want to do this, since leaving your bucket open to anonymous writes lets anyone write to it, and you're responsible for the charges they run up. The policy document lets you expire the POST authorization, and specify some conditions that must be fulfilled on upload.

- You sign some elements of the form and the policy document using a service account Client ID's secret key.

- Then, you can use this form to allow an anonymous user to upload data to your bucket.

For details, please see:

https://developers.google.com/storage/docs/reference-methods#postobject

Hope this helps,

Navneet

--
You received this message because you are subscribed to the Google Groups "Google Cloud Storage" group.
To post to this group, send email to gs-dis...@googlegroups.com.
To unsubscribe from this group, send email to gs-discussio...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gs-discussion?hl=en.

[Navneet (Google)]

I forgot to mention - the CORS config works fine with anonymous requests as well. Once you set up your bucket to serve the right CORS headers, they should be served whether or not the Authorization header is included in the request.

[Spent123]

Hi Navneet,

Thanks for the info, I'll look into it more.

I figured if I was setting the CORS origin to my domain that I could add restrictions via my site, in terms of checking file types, size and upload count per IP/user, as I do want to allow anyone to write with a few conditions.

I may have to bug you more later, because right now when I use the "setcors" and "getcors" in gsutil I get an ''CommandException: Invalid command "getcors"/"setcors" ...'' error, maybe I need to update gsutil ?

Thanks again.

To unsubscribe from this group, send email to gs-discussion+unsubscribe@googlegroups.com.

[Spent123]

O.k,

The update to gsutil 3.0 did fix the the command issues, although something isn't quite right.

When I create a new test bucket and set WRITE for allusers I'm able to set the CORS xml for my allowed domain, but when I upload and test the post form/script on one of my domains that isn't in the CORS it also gets uploaded. Shouldn't that request be rejected ? Maybe I've set something incorrectly or missed something.

[acl_xml.txt]

<?xml version="1.0" ?>
<AccessControlList>
     <Entries>
        <Entry>
            <Scope type="AllUsers" />
            <Permission>
                WRITE
            </Permission>
        </Entry>
    </Entries>
</AccessControlList>

and

[setcors_xml.txt]

<?xml version="1.0" encoding="UTF-8"?>
<CorsConfig>
  <Cors>
    <Origins>
      <Origin>[MY_ALLOWED_DOMAIN_HERE]</Origin>
    </Origins>
    <Methods>
      <Method>GET</Method>
      <Method>POST</Method>
    </Methods>
    <ResponseHeaders>
      <ResponseHeader>x-goog-meta-test1</ResponseHeader>
    </ResponseHeaders>
    <MaxAgeSec>1800</MaxAgeSec>
  </Cors>
</CorsConfig>

[Navneet Joneja]

Hi,

There are two separate mechanisms at work here:

CORS configs are served back to browsers to meet the Cross Origin Resource Sharing specification, which is a browser-based security mechanism that controls scripting behavior (i.e. Primarily JavaScript, and *I think* possibly ActionScript too) behavior within a browser. For example, the CORS policy will be enforced by the browser if you try to do a POST from JavaScript using the XMLHttpRequest call. 

The POST (browser upload) mechanism when you create a form and submit it is different. The browser does not enforce any CORS behavior on straight HTML form submissions. The server will reject any attempt to POST to the bucket if the request is not accompanied by a valid signature (that your app generates) unless the bucket is anonymously writeable. This is why my original recommendation that you do *not* make your bucket anonymously writeable but instead use the security mechanisms offered by the POST method.

Hope this helps!

- Navneet

To view this discussion on the web visit https://groups.google.com/d/msg/gs-discussion/-/gzYBkBQo6kEJ.

To post to this group, send email to gs-dis...@googlegroups.com.

To unsubscribe from this group, send email to gs-discussio...@googlegroups.com.

[Srikanth Pagadala]

Hi Navneet

I have to say that these concepts are *not easy* to grasp in first few readings. I think it would really help if Google would consider writing a sample application which demonstrates *all* these concepts. Benefits are obvious.

Thanks for considering the suggestion.

[Navneet Joneja]

Srikanth,

Thank you for the suggestion. We'll see what we can do.

Thanks,

Navneet

[Spent123]

Ahh, I see.

I'm guessing there's no other way of managing by the domain referral in GCS otherwise I'm sure you would have mentioned it. I'll just upload to my host for now, I just know from experience that when/if switching hosts that transferring a shed load of ogg files from one to the other is a painful process and the beauty of GCS is that I'd only have to move the DB over.

Thanks again for the info, much appreciated.

[Navneet Joneja]

Hi,

Could you share a little more about what you're hoping to do from a user experience perspective? We might be able to offer some suggestions...

Thanks,

Navneet

To view this discussion on the web visit https://groups.google.com/d/msg/gs-discussion/-/lyKhj8Rfk5wJ.

To post to this group, send email to gs-dis...@googlegroups.com.

To unsubscribe from this group, send email to gs-discussio...@googlegroups.com.

[Spent123]

Sure, from the users perspective it's fairly straight forward. They load the recorder flash app, allow access to their microphone and record a message. After they have the message they want, they click a button to encode the WAV data to OGG (for better compression/smaller file size) and it uploads so that any other user can listen to it from their browser.

I did take a quick look at the OAuth2.0 page, but 1.] there are no classic asp (which I'm currently using for this) libraries ( https://developers.google.com/accounts/docs/OAuth2#libraries - I'm not surprised), 2.] if I was to connect to GCS to grab a token then I'd have to use the "MSXML2.ServerXMLHTTP" object which I've had issues with in the past (maybe the host wanted to block proxy type scripts) so I tend to avoid that and even if I could get a token through AS3, it wouldn't be safe to put the secret key in it.

As I say, it isn't really a problem. I'd just like to use GCS for convenience and to save me any possible bigger transfer jobs in the future.

Thanks.

[Navneet Joneja]

Hi,

Hmm. This should be doable, although you'd have to write the ASP code yourself. Here's one way to make it work.

1) The Flash app contacts your ASP webapp.

2) The ASP webapp creates a pre-signed PUT URL and sends it back to the app (or alternatively the data needed to POST the form).

3) The app uploads the data to the requisite location.

4) The bucket default object ACL gets applied to the object if you used the PUT operation, or the ACL in the policy gets applied if you used the POST form.

Did I miss a complication that would prevent this from working for you?

Thanks,

Navneet

To view this discussion on the web visit https://groups.google.com/d/msg/gs-discussion/-/greP2G8wxjYJ.

To post to this group, send email to gs-dis...@googlegroups.com.

To unsubscribe from this group, send email to gs-discussio...@googlegroups.com.

[Spent123]

I've read a couple of posts in this group about signed URLs and I never knew that it was even an option or anything about it at the time of making this post, but I think you're right that it looks to be an option.

I do have a question in terms of security/restrictions though. If I was to create a signed URL for a user and let us say that they grab the signature via the network panel in Firebug (or whatever), is it possible for them to then use that in a custom made HTML FORM - taking the variable needed (within the time limit) - and upload/post/put data to the bucket ?

I've downloaded the private (p12) file and I'll have to look more into how this all works. If I get stuck I'll create a new post, considering this one is drifting away from CORS origin.

####
I doubt this is even on your radar, but I still think there would be some benefit to referral restrictions... maybe in the ACL like...
 <Referral>
    <Domain>test.example.com</Domain>

 </Referral>

Obviously it'd be harder to add on your side of things, I'm not suggesting it's simple. I just think it offers an extra level of security and some additional/alternative authorisation.... I'll stop twisting your arm about it now :D
####

Thanks for the time.

[Spent123]

Actually, scratch that ### referral ### stuff, if PHP's ''$_SERVER['HTTP_REFERER']'' is anything to go by, then it seems that that too is exploitable.