I'm trying to play a .mp4 video hosted on my NGINX server with the Default Receiver App for Chromecast.
I'm able to cast the videos used in their example apps just fine, but my own video fails without returning any error. I'm guessing this has to do with the CORS configuration on my server.
I'm using this config to enable cors on my server. I've tried adding gstatic.com to allowed origins aswell but it doesn't help. I took a look on the headers one of their example videos and tried to reverse engineer what headers I'm missing and still can't get it to work.
What headers do I need to enable for the Chromecast to play my files?
The server that hosts the content needs to set the necessary CORS headers for playback to work.
Related
We are using AWS Amplify for our NextJS web app and keep receiving error when ever I try to load the application once deployed to Amplify. Locally there is no issue.
I am using Amplify's default Auth configuration, with basic email and password auth. It looks like it could be related to the Amplify cookie being set in the header but I cannot find any documentation within AWS to prevent this or reduce the amount of information passed with the header. Any help would be appreciated.
I have faced the same issue and was able to solve it. Here's how -
Identify the CloudFront Distribution ID for your app. You can find it in the Deploy logs of your app build console.
Search & open that particular CF Distribution and go to the Behaviours tab.
Select the Default behaviour (5th one in my case) and hit Edit.
Scroll down to the Cache key and origin requests section.
Here you will find settings to control what's included in the headers of the request that goes to the server. In my case, I didn't need any Cookies so I chose None, and it solved the issue for me.
In your case, you can do the same or pick what all info needs to be in the headers.
Check to see if there are any unnecessary cookies for that domain.
I was getting this error (on a site I don't own). I took a look at the request headers and found a very large number of cookies (several dozen) for the site's domain. I cleaned up the cookies which seemed non-critical and the error went away.
As the error implies, the size of the entire request header section is above 8192 bytes. Request headers include the accept headers, the user agent, the cookies, etc. and all combined can get rather large. Large headers look malicious to some WAFs. I once had a single user having trouble with our site. Turns out they were a polyglot and had configured their browser to accept several dozen languages causing their accept-language header to be suspiciously long, and the WAF refused to proxy the request.
I faced the same issue using Nextjs, amplify and an external Auth provider.
The problem is that AWS S3 service has a request header maximum allowed size of 8192 bytes, so when ever you try to access the static generated pages of Nextjs it returns that error. This has already been asked here
In my case, I was using an external Auth provider and I was able to solve the issue configuring the cookies only for the '/api/' path. That way the Auth cookies are sent only to the Nextjs api endpoints, so your request header is lighter whenever you try to get the static pages.
I installed Nginx on my laptop. My web server contains DASH streaming on-demand using the dash.js player which only hosted on localhost. I want to restrict only DASH dataset from localhost that can be used in that player. Can I use CORS for my purpose? I tried adding
location /{
add_header 'Access-Control-Allow-Origin' 'http://localhost';
}
but still any DASH dataset can still use the player which hosted on localhost. How to enable simple CORS features on Nginx? Is my understanding about CORS is wrong?
Thanks
I want to restrict only DASH dataset from localhost that can be used in that player. Can I use CORS for my purpose?
Not really. CORS is used for getting at resources cross-domain. If a player can natively play DASH (which none of the browsers do currently), then the content will play on any page, CORS support or not. The way DASH players work in-browser today is by loading the resources via XHR requests and sending the data with the media source extension API. To do this, the CORS headers are needed.
Cross-origin request blocking isn't really meant to prevent access to a resource. It's to prevent scripts on one page from accessing resources belonging to another page, effectively impersonating a user. Access-Control-Allow-Origin headers enable other pages to access those resources by effectively saying that the resource queried is safe for use.
If you want to actually block access to something, you should use allow/deny. http://nginx.org/en/docs/http/ngx_http_access_module.html
we have a website on IIS 7 , with Akamai CDN
A feature to download images is implemented in our website. This feature is implemented using a customhandler to look for forcedownload=true appended with image URL's.
Intermittently , the download feature doesnt work. On our analysis , we found that the content-disposition header tag is removed from the httpresponse. The feature works fine or our developer , integration , QA servers with same configuration
Akamai says , the origin server is removing the content-disposition tag. Can you tell is if if you have faced this issue before.
Questions:
Can firewall/load balancer settings remove the content-dispostion tag ?
IIS server Configuration
Is this because of any configuration at Akamai.
Is this scenario plausible - Server receives multiple requests for a image resource to download. Intial requests , have content-dispostion tag added , In subsequent requests the tag is removed. ?
Please suggest some debugging steps to resolve this problem or has anyone faced this issue with akamai
Until you are able to replicate the issue by capturing headers, it hard to tel where the issue lies. But if Origin is causing the issue then why don't you to take advantage of Akamai? I mean based on file extensions you can set headers from Akamai configuration.
Solved with help from akamai support.
Since the tags were getting stripped from akamai end. They made sure to add the tags from their edge server/.
The configuration was done by akamai on their servers and is now live .
I'm thinking about my website architecture that's using https.. I now have a CDN server hosting images , css and more static files.
The website itself is using HTTPS for securing sensitive costumer data. Will using the static images , loaded by for example 'http://cdn.example.com/images/test.jpg' on a website 'https://www.example.com' popup a "Loading insecure data" message?
So loading external NOT SECURED data on a SECURED website.
Will this be causing a popup warning "Loading insecure data, continue?"?
Thx!
Yes.
If a page is loaded over HTTPS then every resource it uses should also be loaded over HTTPS.
Otherwise a man-in-the-middle could replace images with misleading ones (or ones that exploit buffer overflow issues in browsers to execute code) and scripts with ones that do different things (such as leak data to the third party).
You have to load every resource over https to get rid of that warning. You can either move the resources to your server that supports encryption, or link to an external resource over https.
If you really want to load http content in https, you can follow this method using a backend handler in charge of downloading and exposing the required content with self forged links including a hash. The security issue is then fixed and you get the content accessible through https.
Dealing with HTTP content in HTTPS pages
I did this recently.
I have a raspberry pi loaded with nginx, and PHP.
I us Https to handle requests from the web to the PHP code which in turn sends http requests to my local network to assemble the page. Works well.
we have nearly 13 domains within our company and we would like to serve images from one application in order to leverage caching.
for example, we will have c1.example.com and we will put all of our product images under this application. but here I have some doubts;
1- how can I force client browser's to cache the image and do not request it again?
2- when I reference those images on my application, I will use following html markup;
<img scr="http://c1.example.com/core/img1.png" />
but this causes a problem when I run the website under https. It gives warning about the page. It should have been used https//c1.example.com/core/img1.png when I run my apps under https. what should I do here? should I always use https? or is there a way to switch between auto?
I will run my apps under IIS 7.
Yes you need to serve all resources over https when the html-page is served over https. Thats the whole point of using https.
If the hrefs are hardcoded in the html one solution could be to use a Response Filter that will parse all content sent to the client and replace http with https when necessary. A simple Regular Expression should do the trick. There are plenty of articles out there about how these filters are working.
About caching you need to send the correct cache-headers and etag. There are several of questions and answers on this on SO like this one IIS7 Cache-Control
You need to use HTTP headers to tell the browser how to cache. It should work by default (assuming you have no query string in your URLs) but if not, here's a knowledge base article about the cache-control header:
http://support.microsoft.com/kb/247404
I really don't know much about IIS, so I'm not sure if there are any other potential pitfalls. Note that browsers may still send HEAD requests sometimes.
I'd recommend you setup the image server so that HTTP/S is interchangeable, then just serve HTTPS Urls from HTTPS requests.