I'm trying to create a manifest like :
CACHE MANIFEST
CACHE:
offline.jpg
http://externalSite/cacheDemo/offline.jpg
FALLBACK:
/ offline.jpg
http://externalSite/ http://externalSite/cacheDemo/offline.jpg
and then in my html
<img src="unavailable.jpg" />
<img src="http://externalSite/cacheDemo/unavailable.jpg" />
I get the fallback for the local unavailable image to work, but no for the external... is it possible to specify fallbacks for external resources? Cant find documentation about this in particular...
It's unfortunate that it's outside of the specification, and I haven't found any solid justification on why. This is a legitimate need for anyone using a CDN, or for developers developing as 12 factor style application (e.g. for hosting on Heroku), where uploaded images can not modify local state, and instead need to be saved to an attached resource.
Luckily, we can still accomplish what we need in Javascript, but it varies depending on the type of resource you're trying to fallback for.
For images specifically, you can rely on the onError attribute:
<img src="http://externalSite/cacheDemo/unavailable.jpg" onError="this.onError = null; this.src='offline.jpg'" />
Note that we're wiping out the onError to prevent infinite loops if the fallback image isn't available. You can read more strategies about this at: jQuery/JavaScript to replace broken images
For .js or .css, however, this technique is not as reliable, because their onError attribute isn't as supported. However, situations for falling back on offsite .js and .css are less common, since normally you can explicitly cache all of those resources in advance.
Related
I use Rails 4 with rack-offline to cache my pages. I also want to cache (dynamically generated) html pages for offline browsing. Problem is, with the way HTML5 works, they stay stale until the application manifest is updated.
The docs say:
In production, it generates a SHA hash once based on the contents of
all the assets in the manifest. This means that the cache manifest will
not be considered stale unless the underlying assets change.
Is there any way I can trigger a new hash generation when one of my html pages change? This would, for example, after a database update.
Probably not, because AppCache is meant for static resources. Best to use a static HTML page, and use JavaScript to load in dynamic content.
Check out appcachefacts.info for more information.
Can someone show a complete example of application cache with html, css, js, appcache file including CACHE, NETWORK and FALLBACK section. Also updating the manifest. Where should the coding be written?
http://www.html5rocks.com/en/tutorials/appcache/beginner/#toc-updating-cache
As per updating cache from the above link, where should the coding been written?
The code for updating the manifest is written by your sever somewhere.
Either in PHP or Node.js you must write and serve this file with the correct mime type as specified in the link you posted.
You can auto generate this from the css and js files on your server. Don't include html files unless they are dynamic pages.
The first line in the file must be CACHE MANIFEST
Now it assumes your are putting things into the CACHE section, which is where you need to include all the paths to your css and js that you want the user to be able to use offline.
To create a NETWORK section, simply print out the word on it's own line.
Under this section you should include pages that should only be used online.
Under the FALLBACK section include a page to show if there is no offline version available.
This is a brief explanation but you should be able to easily find a tutorial that will help you auto generate this file.
For more details about the cache manifest itself:
http://diveintohtml5.info/offline.html
Offers the best explanation IMHO.
Im trying to wrap my head around Cloudfront. We notice some video sites don't allow us to download the video. I.e. there is no physical link to the file. Or at least, I am not able to locate it in the flash player's source code using Firebug.
On some sites, a typical block of code could look like the following:
<object width="496" height="24" type="application/x-shockwave-flash" id="media_player" name="media_player" data="/flash/jwplayer/player.swf" ....>
<param name="flashvars" value="file=http://some_bucket_name.s3.amazonaws.com/uploads/users/1/foo.mp3&title=Test&author=Foobar&plugins=&autostart=true&controlbar=bottom&repeat=none&screencolor=000000">
</object>
Above, you notice, from the html source code, that the file can be 'cleverly' downloaded through the physical link: http://some_bucket_name.s3.amazonaws.com/uploads/users/1/foo.mp3.
I understand what a CDN is. A good explanation can be found here.
If we use Cloudfront, will this disallow end-users from 'cleverly' downloading media files directly from our app since the files will be streamed?
As Wukerplank suggested: "You can make it difficult, but you can't make it impossible."
Actually, the only thing CloudFront would do is not make S3 / EC2 requests. It's not designed for adding security, but caching and speed. Here's something that should make it harder to download the contents of the link: How do I prevent hotlinking on Amazon S3 without using signed URLs? (checking for a correct referrer).
Using rtmpe adds another layer of protection. Most download apps have difficulties with it, but as Wukerplank says, nothing is bullet proof.
I built a photo gallery which uses Paperclip and validates the content-type using validates_attachment_content_type.
The application runs on a shared host with Passenger.
Is it possible to bypass the validation and run malicious scripts from the public/pictures directory? If so, is there anything that I can do to avoid evil scripts from running or from being uploaded?
Is it possible to bypass the validation and run malicious scripts from the public/pictures directory?
Yes. You can have a perfectly valid renderable image file that also contains HTML with script injection. Thanks for the bogus content-sniffing, IE, you have ruined everything.
See http://webblaze.cs.berkeley.edu/2009/content-sniffing/ for a summary.
If so, is there anything that I can do to avoid evil scripts from running or from being uploaded?
Not really. In theory you can check the first 256 bytes for HTML tags, but then you have to know the exact details of what browsers content-sniff for, and keeping that comprehensive and up-to-date is a non-starter.
If you are processing the images and re-saving them yourself that can protect you. Otherwise, do one or both of:
only serve user-uploaded files from a different hostname, so they don't have access to the cookie/auth details that would allow an injected script to XSS into your site. (but look out for non-XSS attacks like general JavaScript/plugin exploits)
serve user-uploaded files through a server-side script that includes the 'Content-Disposition: attachment' header, so browsers don't attempt to view the page inline. (but look out of old versions of Flash ignoring it for Flash files) This approach also means you don't have to store files on your server filesystem under the filename the user submits, which saves you some heavy and difficult-to-get-right filename validation work.
Does anyone know why there are question marks (with a number) after the images and css files (when looking at the html code)? And how can I turn them off?
From Rails API documentation:
By default, Rails will append all
asset paths with that asset‘s
timestamp. This allows you to set a
cache-expiration date for the asset
far into the future, but still be able
to instantly invalidate it by simply
updating the file (and hence updating
the timestamp, which then updates the
URL as the timestamp is part of that,
which in turn busts the cache).
Hope it helps.
It is to be able to cache the file on the client and still making sure the client receive the newest version when there is a change. So each file modification results in a new timestamp which the client will do a new request to the server to receive the modified file.
If you do not want to use (though I cannot see why - it is a good thing) simple do not use the rails helpers for including javascripts or stylesheets. Just include the normal HTML tags: link and script.