I am storing images of one user(owner) in google cloud storage bucket. I wanted to grant read permission for this image to a group of users(contacts of owner).I am planning to use Access Control List for this purpose; e.g., Owner will have full permission to his bucket and the contacts will have read permission on the images. There are chances that owner will have a very huge number of contacts, say 1 million.
So,
will there be any performance issue, if ACL contains a huge number of users?
Will this be the right approach for access control? Or should I consider signed URL?
Regards,Remya
This approach is not going to work for you. There are some significant limitations and downsides to trying to serve content like this. First and foremost, there is a limit of 100 ACL entries on a given object. You could get around this by granting permission to a group for which every user was a member, but even so, it still means that viewing the images will require that every user be logged in to their Google account in addition to however they authenticate for your site.
The canonical way to accomplish this would be to keep all images private and owned by your site's own account. When a user loads a page, verify however you like that they have appropriate authorization to view the images, and if so, generate signed URLs for the images. This allows you to use any authorization scheme without limitation while serving images directly from GCS.
Related
In our project, we have a group of people which should have full access to ONLY a bucket and they should not see other buckets or the object on the other buckets.
so, i changed the permission of the bucket, and i added the users as Storage Admin for that specific bucket (not for whole project).
In this case, when they use console/Storage they see the following message:
But when they open cloud Shell and they use Gsutil, they can access to the bucket objects (no access to other buckets).
Is this a bug on the interface of Console/storage?
This is not a bug, but it is a subtlety of the Console. In order to access a bucket from the Console, you typically navigate to it using the Browser, which is what appears you attempt in the screenshot. This fails, though, because to do this you need permission to list buckets for a project, even if you otherwise have free reign to work within the bucket.
There are three ways to deal with this:
1) Give your users the Viewer permission for the project that contains the bucket. There are pros and cons to this. I'd say it's probably not worth going this route (though not as much because your users will see other buckets - bucket namespace is publicly viewable anyway - but because doing so brings up some additional permission nuances you probably don't want to deal with).
2) Link directly to the desired bucket, thus avoiding the "listing buckets" portion of the Console. The URL for a bucket has the form: console.cloud.google.com/storage/browser/[BUCKET_NAME]. I believe this will work without any additional modifications to your permissions.
3) Create a custom role that only contains the storage.buckets.list permission, and use that role on the project for affected users.
I use the Dropbox Datastore in an app that uses both the iOS and JavaScript SDKs. Aside from the 10MB datastore limit, it works pretty well.
But nearly every support request I get makes me wish I could have access to the user's data for debugging. Being able to see exactly what the user sees helps me to find and fix bugs very quickly.
Is there any way for me to access a user's data without logging into their account? Can I maybe store their access token and gain access to just their Dropbox Datastore data?
This is one of the attractive things about Parse: you can see all user data. While there is a lot of wisdom in sharding user data across Dropbox user accounts, it makes app debugging crazy-hard.
Any ideas? What do you do to get around this?
Dropbox datastores, like files, are considered the user's private data, and as such there isn't a way for an arbitrary party to gain access to said data without some sort of authorization (e.g., access to the account, having the data explicitly shared with them, etc.) Likewise, even the developer of an API app that a user happens to be using doesn't automatically get access to the data.
That said, if, as the developer of the app, you want to troubleshoot using your user's data, the most straightforward method would probably be to get an access token for that app/user pair from the user. That would replicate their setup most accurately. (Unfortunately, the Sync/Datastore SDK doesn't make it easy to extract/insert arbitrary access tokens like that though. So, in that case, this would be a bit of work to build some flow to get an access token, e.g., a small web app, and then some work to read data directly from the API.)
Alternatively, you may want to make it possible for the user to share the datastore with your own account.
In any case, it's very important that the user not be misled or confused as to what is happening or what the developer is requesting. That means being clear with user with regards to what the developer is requesting and what will be done with the data. In addition, apps should provide privacy policies in general.
I'm quite new to Cloud Storage solutions, and I'm currently researching options to upgrade our current solution (we currently just upload on a SVN server).
What I have is a native application running on client computers, which will upload data to the Cloud Storage. Afterwards, client should be able to download and browse their data (source is not set in stone, could be a website or from other applications). They should not be able to access other user's data.
I'm not sure how I'm supposed to proceed. As far as I understand, the native application will upload using a Native Application Credential, using JSON.
Do I need multiple credentials to track multiple users? That seems wrong to me. Besides when they come back as 'users' through the web interface, they wouldn't be using that authentification, would they?
Do I need to change the ACL of the uploaded files afterwards?
Should I just not give write/read access to any particular users and handle read requests through Signed URLs, dealing with permission details by myself using something else on the side? (not forcing a Google Account is probably a requirement)
Sorry if this is too many questions, and thanks!
Benjamin
The "individual credentials per instance of an app" question has come up before, and unfortunately there's not a great answer. If you want every user to have different permissions, you need every user to be associated with a different account.
Like you point out, the best current answer, other than requiring users to have Google accounts, is to have a centralized service that vends signed URLs to the end applications. That service would be the only owner of all of the objects and would give out permission to read or upload as needed.
I have a newbie question regarding google cloud storage. I'm looking to create a website where people can upload files (similar to Flickr in concept) and view them. I was looking at google's cloud storage option and it seemed interesting. I got a little hung up on the authentication process. Do all users need a Google account or did I just misread it? I guess my question is can I create a site where everyone doesn't have to sign up for a google account?
Thank you for your patience and help
Nope, there's no need for customers to have their own Google accounts. Google Cloud Storage supports that, in case you want to say "these accounts have access to this data", but you can also let your app grant access on a per-request basis using whatever logic or authentication scheme you like.
This is usually accomplished with signed URLs. Basically, you'd use your credentials to sign a very specific request (download object X, upload an object with name Y) and pass that URL to the user for them to use. Signed URLs are only valid for as long as you like (one of the parameters is how long the URL is good for).
Documentation on signed URLs are here: https://developers.google.com/storage/docs/accesscontrol#Signed-URLs
It's not strictly necessary to require a user to be logged in in order to write to your bucket (e.g., we have a public-read-write canned ACL for buckets), but it's generally a bad idea. Any data stored in your bucket will ultimately be charged to you, so allowing anyone to write without authentication opens you up to a great deal of abuse.
Likewise, you could make all of your objects public-read, but then you get charged for the bandwidth costs and have no control over it (though this is a much more reasonable thing to do than public-write).
A safer option would be to proxy bytes for your users - i.e., only you/your app can write to your bucket, and your users hand their bytes to you.
Generally speaking, though, the only types of authentication we support are Google accounts, signed URLs, and anonymous users.
I'd like to use Amazon SimpleDB to store data for my iPhone app. Different users will own items within the same domain. I'd like for users to be able to delete their own items but not each others', and for this restriction to be enforced server-side.
I am hoping to use anonymous TVM.
What is the best way to do this?
Using IAM User Management you can create a custom policy for each user or group to allow or deny access to delete items in SimpleDB. If each user has their own domain you can restrict access to the domain by using the arn format arn:aws:sdb:<region>:<account_ID>:domain/<domain_name>
I think that you can't use IAM - you seem to say that you have one domain where all user data is stored.
One way to achieve what you want is to use item name prefixes that are user based, e.g. user jimsmith would have all items stored under an item name that beings with 'jimsmith' or some random string, unique to jimsmith (which could be stored somewhere).
Then you are in charge of security, so you would not be able to have the phones directly query AWS - they would need to talk to your intermediary server which would handle security. You have to assume that people could run the app on a jailbroken phone, and decompile, etc.
You can use IAM to restrict a single user to a small portion of an S3 bucket though. You could then index the bucket using a server app of your design. Then the DB could be used for searching purposes with your own code, so that iPhones only deal with S3.
From what I have researched the simpleDB user right policies aren't designed to be used in such a way you are proposing (meaning undisclosed number of users of the app) and the way to handle this might be to use some server application in-the-middle as was suggested here: Mobile app and SimpleDB direct 'Access Policy'