Project ASP.NET
I will use Azure for my storage. Questions (requirements):
In my project I let my registered users download files. But I don't want the user to share this download link to unregistered people (example : the download link what I gave the registered user shall only be downloadable on their computer) .
I show only for registered users the download link, the registered users can download the files that I gave them
No one can delete my files
Question 1: This is really up to your app but... if you're giving direct links to blobs in Azure Storage, you would need to protect them with a Shared Access Signature (or policy). This way, you can give someone a link that expires (for example, 10 minutes after you issue the link). Then, if someone gives away the link, it won't work for very long. There's no way to limit a link's use to a specific computer. Now, if you simply stream content from blob to your app, and then from your app to the user, you will probably have a bit more control, since you wouldn't really be generating a reusable link. But this will have downsides (such as running all content through your web tier, requiring more resources in your web tier).
Question 2: This is completely up to your app, how you manage assets and present them to a registered user. No way to answer this for you, since we know nothing about your app.
Question 3: Azure Storage is accessible by a secret key, which should stay secret, and only you should ever have access to it (for example, it would be used by your code on the server). As long as you don't publish this key anywhere, then nobody would be able to delete your content.
Related
Is it easy for people to find "public" google sheets/docs?
Context: Storing some semi-sensitive data (individual user info, of non-sensitive nature) for an app beta-test in google sheets. Planning to migrate to some DB in the future, but for now, just using JavaScript to pull the data directly from the google sheets (since there are visualizations being dynamically updated by the sheets).
Yes, it's easy to get information. Search engines may index and cache the information. Then, there are bots, crawlers and scrapers. Do NOT put (semi)sensitive information in public. Implement google-oauth properly with google-sheets-api to get information. You can also use service-accounts
Yes, it can be easily accessed.
According to the official Google article Share files from Google Drive: when you set your file's General Access setting to public:
Anyone can search on Google and get access to your file, without signing in to their Google account.
What you can do:
In the case of your app beta-test in google sheets data, you may want to reconsider to change your file's General Access setting to one of the following (in descending order of security):
Restricted - Only people that you manually give access to can view or edit your files. When you click the share button, a prompt will show and you may manually add the users who can view or edit your files:
Afterwards, you may select a role for those users and then they can be notified afterwards through email.
On the other hand, you can share the link to others. A prompt will show like the one below if you send the url through Google Chat:
You may opt to select Don't give access which will result in the following view on the other user's end:
This would mean that if unauthorized users get hold of the file URL, they will still need to send an access request. If other users submit the request, an email notification will be sent to your mail inbox. Other users who also own the file will also be notified by mail.
Your Organization - If you use a Google Account through work or school, anyone signed in to an account in your organization can open the file. If you are an administrator in a work or school workspace, you may set how members can share content within the organization. The administrator can prevent the sharing of content with group members outside your organization. If external sharing is prohibited, only group members who are in your organization can access the group's shared content.
Anyone with the link - Anyone who has the link can use your file, without signing in to their Google Account. This option is least recommended because if the URL is leaked to unauthorized users, they can easily access the file.
References:
Share files from Google Drive
Share content with a group
Don’t make it public unless you want the public to see it. Use oauth to access.
I'm not sure if this is a good question, but I know Azure Media Services has content protection for video and audio, and I know Azure Rights Management exists for documents and email, and seems to use a special client to view protected documents.
If I were to build a web application that lets users view sensitive documents, like CVs or financial histories, is there a way to let users view those documents (pdfs, word documents, whatever, they'd be uploaded as Azure blobs) in an ordinary web browser like Chrome etc. but without being able to download them (most importantly), print them, copy portions from them, and so forth?
Any type of content protection would need to be built by you. Blobs simply contain data that you put there.
You can make a blob private so that only your app can get to it, unless you generate a temporary Shared Access Signature (or policy). However: If you provide a link via SAS, there is no stopping someone from downloading it (until the link expires).
If you want to do something related to web-based browsing with content protection, you'd need to download the content from blob to your web app first, and then serve that content from your web app with whatever protections you wish to implement / take advantage of, without ever providing a blob's direct link to the the end-user.
i have an Azure Blob Storage with blobs that are pdf that are categorized by client number. So for each client, they have multiple pdf reports. I only want the client to be able to access the blobs for their client number. (There are hundreds of clients.)
I've researched, but only see shared access signatures, but this doesn't look like what i need.
There is no user-level blob permissions, other than Shared Access Signatures (and Policies).
It's going to be up to you to manage access to specific user content (and how you manage that is really up to you and your app, and how you manage a user's content metadata).
When providing a link to a user's content: if you assume all content is always private, then simply create an on-demand SAS link when requested. There's no way for the user to modify a SAS link to guess sequential numbers or neighboring blobs, since the SAS is for a specific URL.
As Andrés suggested, you could also use your app to stream blob content, and never worry about SAS. However, you will now be consuming resources of your web app (network, CPU, memory), and this will have an impact on your app's scale requirements. You will no longer be able to offload this to the storage service.
Sounds like you already have the users authenticate, and you know which pdfs belong to them. My suggestion is to add to your current application a simple proxy (for instance if you have an MVC application, you could add a new controller and action method that will retrieve the pdfs on behalf of the user).
This way you don't need to use shared access signature and can keep the blob container private. Your controller/action method would simply use the storage SDK to retrieve the blob. An added bonus is that you could check to make sure that they are requesting their own PDF file and reject the request if they guess the ID of someone else's file.
I am developing an application that requires to share files between users using Microsoft Live sdk. But only resource that I came across is by providing a shared link or embed link which expires after some time and are open to public usage. Instead, I want to share files among only certain group of one drive users and that too, permanently. This functionality is already present in one drive itself. Is there any way of doing it using one drive api ?
UPDATE: google drive api supports these.
The OneDrive API support the creation of sharing links, which would be easy to send to the group that you want to give access to a specific file or folder. These links do not expire, however they can be revoked.
Here is an example of the kind of request you can use to create one of these links
POST https://api.onedrive.com/v1.0/drive/items/{item-id}/action.createLink
Content-Type: application/json
{
"type": "view"
}
I'm creating an application that will be hosted in Azure. In this application, users will be able to upload their own content. They will also be able to configure a list of other trusted app users who will be able to read their files. I'm trying to figure out how to architect the storage.
I think that I'll create a storage container named after each user's application ID, and they will be able to upload files there. My question relates to how to grant read access to all files to which a user should have access. I've been reading about shared access signatures and they seem like they could be a great fit for what I'm trying to achieve. But, I'm evaluating the most efficient way to grant access to users. I think that Stored access policies might be useful. But specifically:
Can I use one shared access signature (or stored access policy) to grant a user access to multiple containers? I've found one piece of information which I think is very relevant:
http://msdn.microsoft.com/en-us/library/windowsazure/ee393341.aspx
"A container, queue, or table can include up to 5 stored access policies. Each policy can be used by any number of shared access signatures."
But I'm not sure if I'm understanding that correctly. If a user is connected to 20 other people, can I grant him or her access to twenty specific containers? Of course, I could generate twenty individual stored access policies, but that doesn't seem very efficient, and when they first log in, I plan to show a summary of content from all of their other trusted app users, which would equate to demanding 20 signatures at once (if I understand correctly).
Thanks for any suggestions...
-Ben
Since you are going to have a container per user (for now I'll equate a user with what you called a user application ID), that means you'll have a storage account that can contain many different containers for many users. If you want to have the application have the ability to upload to only one specific container while reading from many two options come to mind.
First: Create a API that lives somewhere that handles all the requests. Behind the API your code will have full access to entire storage account so your business logic will determine what they do and do not have access to. The upside of this is that you don't have to create Shared Access Signatures (SAS) at all. Your app only knows how to talk to the API. You can even combine the data that they can see in that summary of content by doing parallel calls to get contents from the various containers from a single call from the application. The downside is that you are now hosting this API service which has to broker ALL of these calls. You'd still need the API service to generate SAS if you go that route, but it would only be needed to generate the SAS and the client applications would make the calls directly with the Windows Azure storage service bearing the load which will reduce the resources you actually need.
Second: Go the SAS route and generate SAS as needed, but this will get a bit tricky.
You can only create up to five Stored Access Policies on each container. For one of these five you create one policy for the "owner" of the container which gives them Read and write permissions. Now, since you are allowing folks to give read permissions to other folks you'll run into the policy count limit unless you reuse the same policy for Read, but then you won't be able to revoke it if the user removes someone from their "trusted" list of readers. For example, if I gave permissions to both Bob and James to my container and they are both handed a copy of the Read SAS, if I needed to remove Bob I'd have to cancel the Read Policy they shared and reissue a new Read SAS to James. That's not really that bad of an issue though as the app can detect when it no longer has permissions and ask for the renewed SAS.
In any case you still kind of want the policies to be short lived. If I removed Bob from my trusted readers I'd pretty much want him cut off immediately. This means you'll be going back to get a renewed SAS quite a bit and recreating the signed access signature which reduces the usefulness of the signed access policies. This really depends on your stomach of how long you were planning on allowing the policy to live and how quickly you'd want someone cut off if they were "untrusted".
Now, a better option could be that you create Ad-hoc signatures. You can have as many Ad-hoc signatures as you want actually, but they can't be revoked and can at most last one hour. Since you'd make them short lived the length or lack of revocation shouldn't be an issue. Going that route will mean that you'd be having the application come back to get them as needed, but given what I mentioned above about when someone is removed and you want the SAS to run out this may not be a big deal. As you pointed out though, this does increase the complexity of things because you're generating a lot of SASs; however, with these being ad-hoc you don't really need to track them.
If you were going to go the SAS route I'd suggest that your API be generating the ad-hoc ones as needed. They shouldn't last more than a few minutes as people can have their permissions to a container removed and all you are trying to do is reduce the load on hosted service for actually doing the upload and download. Again, all the logic for handling what containers someone can see is still in your API service and the applications just get signatures they can use for small periods of time.