In my rails app I have used attachment_fu to upload images and stored it on s3.
I want to display these images on browser without retrieving it.
How can I display images by giving s3 path?
Thanks,
Jayashri
You just need to link to the correct S3 path for you images.
For public files they are in the format:
eg http://s3.amazonaws.com/[bucket]/[key]
If your content is private you'll need to create a signed url but all the SDKs and libraries make this easy.
Then use the url to display the images:
<img src="http://s3.amazonaws.com/mybucket/myfile.jpg" ... ></img>
It may help you to install the S3 organizer in Firefox so you can browser your directories. Then I believe the URL's are structured kinda like this...
http://BUCKET.s3.amazonaws.com/FOO/BAR.png
Related
I am developing an iOS app that uses a large amount of images that are needed for animations for short videos. I want to save my application assets as static files in cloud and once they are needed download them using secure API call (either JSON, XML or any other alternative for that matter).
What is the best option for that. I have checked Parse, Dropbox, iCloud, Google Drive, but I am puzzled since I see only instructions for dynamic data that lets users access content they have created and not static assets.
What would be best option for that?
If you just want an easy way to serve static files I would take a look at Amazon S3. You can just upload files through the online console and then get the public URL to those files to use in your app. You can also use the S3 API to upload files through your web service or iOS app.
Hope this helps!
I'd go for Parse (basically because it is fast to learn and develop), you can create a table with the images and change the writing permissions if you are afraid somebody could modify the table.
Another option that you can check it's the special Config table so you can upload custom files (zip files i.e.) and download them in demand.
I have a rails app, in which i store some images in AWS, and show them in a PDF report. When there is no images to be shown, i show a placeholder, like this one here: .
The problem is: the image is not show in the PDF file. When in debug mode, the image is shown as usual, but never in my PDF! The link to the image is like this: https://dl.dropboxusercontent.com/u/4096865/missing.png
Edit 1:
I tried to include the image like this: image_tag("https://dl.dropboxusercontent.com/u/4096865/missing.png")
The solution i've found was simple, but prevented me from using dropbox for storage: it must be a http url. So, when i uploaded it to AWS S3, it worked!
So, this here works perfectly: image_tag("http://s3-sa-east-1.amazonaws.com/base-fisc-prod/missing.png")
This is an issue with images stored in a HTTPS link, the easiest way to solve this is to store the images in a HTTP link.
If you must store them in HTTPS, use this solution provided here
For my Rails application, I download a bunch of files from a remote URL to my application. I would like to directly upload them to Amazon S3, without needing a form to do the upload, since I will temporarily cache the file I downloaded on the EC2 instance.
I would also like to retain the links to the files I uploaded so I can download them later.
I am essentially reposting the files I downloaded.
I looked around, but most of the solution seem to involve form uploading to S3 with a user.
Is there s direct upload solution?
You can upload directly to S3 using the AWS SDK for Ruby. The easiest way is:
require 'aws-sdk'
s3 = Aws::S3::Resource.new(region:'us-west-2')
obj = s3.bucket('bucket-name').object('key')
obj.upload_file('/path/to/source/file')
Or you can find a couple other options here.
You can simply use EvaporateJS to achieve this. You can also take advantage of sending ajax request to update file name to the database after each file upload. Though javascript exposes few details your bucket is not vulnerable to hack as S3 service provide a bucket policy.
Just set the <AllowedOrigin>*</AllowedOrigin> to <AllowedOrigin>specificwebsite.com</AllowedOrigin> in production mode.
I've successfully uploaded, via Paperclip, images to the RackSpace cloudfile storage, and they appear correctly within subsequent webpages when I'm using the CDN url.
However, I can't figure out why Paperclip is not showing the files if I do not use CDN enabled cloud files.
Paperclip returns (via its 'url' method for the attachment) the more usual /attachments/fred/1/image/123.jpg path, however that results in a broken image as there is no actual file stored at that url - its in RS cloud file storage.
I'm not sure whether
a) Paperclip is supposed to give me a url to non-cdn location
b) Paperclip provides a url which results in it then responding at that url to provide the raw image data
c) Something completely different to a) and b)
If someone could please shed some light on what url I'm supposed to get back from Paperclip for non CDN enabled RackSpace stored files I think it would help steer me in the correct direction.
Thanks.
Rackspace Cloud Files has the ability to download files without a CDN, but after researching it paperclip and fog do not currently support this.
Paperclip supports both CDN access as well as downloading files using a temporary url (sans CDN). I was going to suggest using a temporary url, however, the get_http_url method paperclip uses to retrieve this url isn't currently implemented for Rackspace.
I have created a fog issue to address this https://github.com/fog/fog/issues/2103.
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.