I have found documentation for uploading an image from iOS to a blob container in Azure - https://learn.microsoft.com/en-us/azure/storage/blobs/storage-ios-how-to-use-blob-storage
using the https://github.com/Azure/azure-storage-ios library
But I wish to upload directly to a file share. Is there a way to do this?
It needs to be implemented using SAS authentication.
Unfortunately I am not familiar with iOS programming thus I will not be able to provide you any code. However you can use the steps below to write code.
Assuming you have a SAS URL for the file share in which you wish to upload the file, you can simply use Azure Storage REST API to upload the file in a file share. You should be able to use built-in HTTP functionality in the programming language of your choice to do that.
Let's assume that you have a SAS URL for the file share in the following format: https://<account-name>.file.core.windows.net/<share-name>?<sas-token>.
First thing you would need to do is insert the file name that you wish to upload in this SAS URL so that you get a SAS URL for the file. Your SAS URL would look something like: https://<account-name>.file.core.windows.net/<share-name>/<file-name>?<sas-token>.
Next you would need to create an empty file. You will use Create File REST API operation. Do not worry about the Authorization request header there as it is already included in the SAS. Only request header you would need to include is x-ms-content-length value of which should be the size of the file you want to upload. This will create an empty file having size as that of the file you want to upload.
Once this operation completes, next you would need to upload the data in the empty file you just created. You will use Put Range operation. The request headers you need to include are x-ms-range (value of which should be bytes=0-file-length - 1) and Content-Length (value of which should be the length of your file). The request body will contain the file contents.
Using these steps you should be able to upload a file in a file share.
Related
I can easily create a URL File through the O365 OneDrive web UI. Right click > New > Link. Enter the URL and save. The new item appears in the UI and when clicked, it will take you directly to the new URL, let's say it's www.google.com.
I'm attempting to duplicate this with the Graph API.
GET /me/drive/items/{folderId}/children
with:
{ name:'www.google.com.url',
file:{}
}
It creates what appears to be a link in the OneDrive UI but when clicked, it will not take you to the URL, it attempts to download a file. I've tried creating it with and without the .url suffix. The API looks pretty limited and there aren't many options to pass. I've also tried the beta API, same issue.
Links are actually a file with a special syntax similar to an INI file. From the sample you included here, it looks like you're creating an empty (0 byte) file named "www.google.com.url". Since the empty file doesn't match the format expected for a .URL file, OneDrive doesn't know what to do with it and just downloads the file.
To create a link programmatically, you would need to make a request like this:
PUT https://graph.microsoft.com/v1.0/me/drive/root/children/ShortcutToBing.url/content
Content-Type: text/plain
[InternetShortcut]
URL=https://www.bing.com
This will create a file named ShortcutToBing.url, and fill the contents of the file with the text below the request, which is the contents of a .URL file, pointing to www.bing.com.
I prefer iOS code but the solutions in other languages may refer to this question too.
I use LiveSDK to access to OneDrive. Here is a link to the example which uses upload action (onClickUploadButton:)
But I can't understand how to specify the custom upload path - only default "me/skydrive" works. How do you solve the problem when you need to upload a concrete file to a concrete path which may not exist? Should I create all the folders separately and/or get their IDs to place a file exactly into them?
Is the only way to download a file through Google Drive through the download_url that is provided? I have the file_id and would like to make one simple call to download the file. Right now it looks like you have to make one call to fetch the file metadata and retrieve the download_url, then another to actually download the file. Is this the only way?
Also, the download_url is described as a "short lived url". How long will this url be available for?
Thanks
Using the download_url is the correct way to download a file from Drive. I'd strongly advise against trying to build the download urls yourself as the resulting code will be likely to break.
A download_url is usually available for hours, but instead of relying on that you should always retrieve the updated file before downloading a file from Drive. More information at this other question: How long does the Google Drive SDK "short lived" download URL exist for?
I have a website that shows galleries. Users can upload their own content from the web (by entering a URL) or by uploading a picture from their computer.
I am storing the URL in the database which works fine for the first use case but I need to figure out where to store the actual images if a user does a upload from their computer.
Is there any recommendation here or best practice on where I should store these?
Should I save them in the appdata or content folders? Should they not be stored with the website at all because it's user content?
You should NOT store the user uploads anywhere they can be directly accessed by a known URL within your site structure. This is a security risk as users could upload .htm file and .js files. Even a file with the correct extension can contain malicious code that can be executed in the context of your site by an authenticated user allowing server-side or client-side attacks.
See for example http://www.acunetix.com/websitesecurity/upload-forms-threat.htm and What security issues appear when users can upload their own files? which mention some of the issues you need to be aware of before you allow users to upload files and then present them for download within your site.
Don't put the files within your normal web site directory structure
Don't use the original file name the user gave you. You can add a content disposition header with the original file name so they can download it again as the same file name but the path and file name on the server shouldn't be something the user can influence.
Don't trust image files - resize them and offer only the resized version for subsequent download
Don't trust mime types or file extensions, open the file and manipulate it to make sure it's what it claims to be.
Limit the upload size and time.
Depending on the resources you have to implement something like this, it is extremely beneficial to store all this stuff in Amazon S3.
Once you get the upload you simply push it over to Amazon and pop the URL in your database as you're doing with the other images. As mentioned above it would probably be wise to open up the image and resize it before sending it over. This both checks it is actually an image and makes sure you don't accidentally present a full camera resolution image to an end user.
Doing this now will make it much, much easier if you ever have to migrate/failover your site and don't want to sync gigabytes of image assets.
One way is to store the image in a database table with a varbinary field.
Another way would be to store the image in the App_Data folder, and create a subfolder for each user (~/App_Data/[userid]/myImage.png).
For both approaches you'd need to create a separate action method that makes it possible to access the images.
While uploading images you need to verify the content of the file before uploading it. The file extension method is not trustable.
Use magic number method to verify the file content which will be an easy way.
See the stackoverflow post and see the list of magic numbers
One way of saving the file is converting it to binary format and save in our database and next method is using App_Data folder.
The storage option is based on your requirement. See this post also
Set upload limit by setting maxRequestLength property to Web.Config like this, where the size of file is specified in KB
<httpRuntime maxRequestLength="51200" executionTimeout="3600" />
You can save your trusted data just in parallel of htdocs/www folder so that any user can not access that folder. Also you can add .htaccess authentication on your trusted data (for .htaccess you should kept your .htpasswd file in parallel of htdocs/www folder) if you are using apache.
I have a upload text file field, and with it I plan to save the file somewhere and then store the location of the file in a database. However, I want to make sure the file they uploaded is a .txt file, and not, say, an image file. I imagine this happens in the validation step. How does one validate such a thing? Also, how do you get the filename of the uploaded file? I could always just check if it said '.txt' but for future reference knowing how to validate without just the filename would be helpful.
Trying to validate the contents of a file based on the filename extension is opening the door for major hackerdom. It's trivial to change the extension and upload the file.
If you are on a Mac/Linux/Unix-based system the OS "file" command is the standard because it looks inside the file for key bytes that flag file types. http://en.wikipedia.org/wiki/File_(Unix) I'm not sure what's available for Windows, but this might help: Determine file type in Ruby
One way of doing it, the simple way really, would be to pass the file through an image loader, preferably one that handles multiple common formats, and see if it throws an error.
The other way is to manually check the file header for common image format headers. For example, .bmp files start with BM. Other formats have their own specific markings you can use.