I have a Rails 3.0.x app, which displays a page containing the Yahoo Web Player. The player plays an audio file served by the Rails app, the controller that handles the file request uses send_data to send the mp3 file:
send_data content, :filename=>dsLabel, :type=>mimeType, :disposition => 'attachment'
(*) I’ve also tried disposition inline
This works fine on Safari, IE, and FF. However, in Opera you click the play button and the audio never plays, Yahoo’s code is minified and a bit difficult to tell exactly what’s wrong, but I’ve concluded this isn’t javascript problem as far as I can tell.
One thing to note about the site is that when I’m locally on the same network at work, our DNS server resolves the site to a 10.x.x.x LAN IP, otherwise it resolves to a public IP.
In Opera if I open Preferences and add the hostname under Trusted Websites->Secure Internal Hosts then reload the page the audio plays fine. If I change my DNS to OpenDNS it also plays fine. I seem to be hitting a Opera security policy issue that I don’t fully understand.
It seems to me that although internally my host resolves to a LAN IP, once loaded Opera thinks its a public site, and so the MP3 won’t download, however it too resolves to the LAN IP so it doesn’t seem like a public/private divergence.
I was hoping someone in the Stackoverflow community with better understanding of Opera security could explain the policy I’m seeing enforced here.
You may have ran into a “network type pinning” policy. Basically Opera will try to remember whether some site first resolved to a public or private IP.
This policy is meant to guard against attack where a site first sends you some code, then later re-configures itself to claim its IP address is internal. Say, attack.example.com serves a page that links to attack.example.com/intranet/menu.js , later when you re-visit attack.example.com pretends its IP is 10.0.0.1 where your intranet is running, and your intranet also happens to reference an /intranet/menu.js file. If menu.js now runs from cache it can do whatever it wants to on the intranet site. Attack completed.
Hence, Opera may not be applying the security policy according to what IP you’re currently connecting to, but according to what IP it first saw the hostname resolve to. Sorry that this is a pretty obscure piece of state, but you’re in a pretty small minority when you have some hostname that might resolve either to a private or a public address 😉