I am new to coding and am trying to set up a streaming audio option so that visitors may listen to a weekly live broadcast directly from a website but most browsers are blocking it from running.
The live stream is coming from Shoutcast as an HTTP:// not an HTTPS:// which is causing an insecure mixed content issue.
The stream works fine on Firefox on the live site, but will not work on any other browser tested.
I do get the console message on Chrome that it was automatically upgraded to HTTPS://, and from what I understand I should just have to change my code to HTTPS:// for it to work, but it is not, and I could be wrong.
Here is my original code:
<audio
controls
src="http://djefo.lightmanstreams.com:8020/;"
type="audio/mpeg"
></audio>
Are there any suggestions on how I can make the stream work on Chrome at least?
Well, unless you upgrade your shoutcast streaming package, you will not be able to use https to avoid mixed content issue. From my experience of shoucast/icecast streaming, I can say you have to upgrade your package to the certain package which provides SSL for your streaming URL.
Two options:
Latest Shoutcast version (2.6.1 build 777: https://yp.shoutcast.com/v/2_6_1) does support SSL out of the box on Linux, so you can get a free SSL certificate from Letsencrypt and use it with Shoutcast.
You can configure Apache or Nginx as SSL proxy for your non-ssl SHoutcast stream, see this answer: Web radio stream proxying
Related
suppose I have an mp4 sitting on a remote server that I can SSH into. can this file be streamed using the video tag? what would the URL look like?
Very theoretically:
ssh://example.com/path/to/some.mp4
… but browsers don't implement SSH clients or support for the SSH protocol, so that won't work in practice (although it might be possible to write a browser extension to add support).
If you want to embed the video in a webpage, then make the MP4 available of HTTPS (or HTTP).
I can't intercept requests made by Chrome version 73.0.3683.86 to my localhost site.
Local host site is running on IIS on http://127.0.0.3:80
Burp proxy lister is default one on 127.0.0.1:8080
Interception rules are default one as well
In my LAN settings, "Bypass proxy server for local addresses" is not enabled
When Interception is turned ON and I reload page in Chrome browser, no request is "caught" by Burp, my local site loads and only the external requests are intercepted, such as loading external scripts from CDN.
Also under "Proxy" > "HTTP History" there is only request to external sites, and all requests to http://127.0.0.3:80 are not recorded.
When I reload same page by Internet Explorer 11, initial GET request is intercepted by Burp, as expected. Also "Proxy" > "HTTP History" shows all the requests to local site http://127.0.0.3:80
What is the problem with the Chrome? Thanks!
Found the solution late yesterday. I am using the Chrome extension ProxySwitchy, but it doesn't matter if you use that or the system proxy configuration. The solution works the same way.
You can solve this problem by adding an entry in /etc/hosts file like below
127.0.0.1 localhost
127.0.0.1 somehostname
Now burp will intercept request from somehostname
Which version of Chrome are you using?
Have you tried using the FoxyProxy Chrome extension?
As a workaround, you could modify the hosts file on your machine.
I experienced the same issue when I upgraded from Opera 58.0 to 60.0. I think that this is Chrome related, because I've also experienced it in all other Chrome browsers. Opera 58 utilizes Chrome 71.0.3578.98. Opera 60 utilizes version Chrome 73.0.3683.103. Something was definitely updated in Chrome between these versions to cause this problem to happen.
You have to subtract the implicit bypass rules defined in Chrome (https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Implicit-bypass-rules)
Requests to certain hosts will not be sent through a proxy, and will
instead be sent directly.
We call these the implicit bypass rules. The implicit bypass rules
match URLs whose host portion is either a localhost name or a
link-local IP literal. Essentially it matches:
localhost
*.localhost [::1]
127.0.0.1/8
169.254/16
[FE80::]/10
https://chromium.googlesource.com/chromium/src/+/master/net/docs/proxy.md#Bypass-rule_Subtract-implicit-rules
Whereas regular bypass rules instruct the browser about URLs that
should not use the proxy, Subtract Implicit Rules has the opposite
effect and tells the browser to instead use the proxy.
In order to be able to proxy through the loopback interface, you have to add the entry
<-loopback>
in the list of hosts for which you don't want to a proxy. It is a bit confusing, indeed.
Make sure you haven't enabled socks proxy option, it happened with me too and i found the solution when i disabled the socks proxy option, just make sure it's disabled!
Example:
It helped me
I turned on this settings
Our system uses an AWS Elastic Load Balancer.
We are encountering a maddening issue where our HTML video tags are failing to play randomly. I can't reliably reproduce the issue unless I bypass the ELB, which makes me suspect it, naturally.
I've verified that the same files are on both of our IIS servers, and I have verified that the MIME types are the same on both.
The video files are H.264 MP4s, but they will sometimes work, so I don't think it has anything to do with Chrome's support of the codec.
Anybody have an idea on what I can do, or where to look next?
This is a session issue on the AWS ELB. Enable the Sticky Sessions on the ELB and this issue will be resolved. Here is the developers guide.
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html
I would enable full logging on both IIS and the ELBs, and carefully check the access logs on each to confirm.
You would expect to see a 200 http response code on the ELB and the IIS server for each request made. Check for any requests that result in a 400 or 500 error. You need to pair each individual request from the ELB to the IIS server and review.
See Monitor Your Load Balancer Using Elastic Load Balancing Access Logs
I'm working on a project about a streaming server (Linux, Apache, Squid, DHCP) that works on LAN. Clients connect to the server through web browser and watch videos with HTML5. Using HTML5 is very simple, but clients can also download videos easily with right-click menu (or with a browser extension). Is it possible to prevent users from downloading videos with squid proxy server while they can play videos with browser? I tried to block video file downloading (with squid), but with this method HTML5 video won't play either. Squid config for blocking file download that i used:
acl BlockExt url_regex -i \.mp4$
http_access deny BlockExt all
Thanks.
sadly there is no way to differentiate from the server between a browser requesting the video to play and requesting the video to download.
you could add an annoyance factor by disabling rightclick via javascript (that's only going to stop really basic users) or split the video into multiple fragments and use the ended event to jump to the next piece (potential for buffering delays of course, but for this sample dealing with Audio it's been fairly reliable - https://gist.github.com/1266499)
I have a HTML5 webapp which is running perfectly when served via the IIS without authentication.
Is is using a cache.manifest file.
Both when running in safari, and as an "add to homescreen" fullscreen app, once I update the manifest file on the server, and the app will update.
When I turn on authentication on all files except the cache.manifest, then I only see the update when running it in the safari browser.
If I add it to the homescreen, I am not able to make the app update the cache.
If I wireshark the traffic on the server, I can see the manifest file is fetched without problems, but all the files in the manifest file hits a 401 Unautorized error.
Any idea how I can fix this? Running it in the safari browser is working..
Any help is highly appreciated.
Safari is much more aware of HTTP Basic Auth, but web.app (the home screen web app handler, which is basically a UIWebView wrapper) isn't as full-featured and doesn't appear to support basic auth.
It seems you may need to work around this with either a server-side solution to append an authentication key to the filename (such as application.css?longhexkey) to bypass basic auth, or go with a more traditional login form (which may require significant changes to your app)
Same issue on Sencha forums: Unanswered: Forcing re-authentication after offline usage on iOS devices?