Localhost crossorigin issue - Unsafe attempt to load URL - Domains, protocols and ports must match - html5-video

I have a video control on a localhost with closed captions. I have the virtual host static defined that points to the same directory as localhost. Static feeds my media files and has worked forever... except it seems with video caption files.
If the track src is set to static, the captions won't show. Chrome console gives the error:
Unsafe attempt to load URL https://static/file.vtt from the frame with URL
https://localhost/page.php. Domains, protocols, and ports must match.
I've tried the advice at the post issue-with-loading-vtt-from-cross-domain and set both values for cross-origin with no luck. Is this a localhost only issue? Any solutions to this?
video.crossorigin="anonymous";
video.crossorigin="use-credentials";

Related

How to configure SSL for a URL that is present in my HOST file to redirect to localhost?

Hard to explain in the subject what's my problem, but it will have sense I promise.
I debug locally with an URL different than localhost (due to azure AD redirect), I have all the HOST configurations in place, everything works fine except for this "Not Secure" warning, that sometimes annoys my UI while calling the BE.
But if I navigate my page by using LOCALHOST:same port, the issue is not present.
What steps should I configure in order to prevent this warning while using an URL? So it works similar to LOCALHOST.
I tried so far to include the certificate in the Personal folder (following several tutorials) but did nothing.
Regards.

DNS resolves correctly using command line tools but fails on browser

Dig, wget, nslookup and curl commands work perfectly for a specific URL I have pointed to another server less than 24 hours ago.
Problem is, it just refuses to be resolved by the browser (Chrome, Safari and Firefox). The strangest part is that it is being successfully resolved by Postman (by testing the OPTIONS and the GET methods separately), but still doesn't return a proper response on the browser side of things.
DNS checks are returning positive, so this is when I started suspecting that the problem is actually within the headers of the HTTP protocol's requests which are sent - alongside the fact that different responses are being returned for the requests that don't include the default browser headers (being issued through the different command-line tools & Postman) and the ones who do (being issued by the browsers automatically or manually using the dev tools).
After fully flushing the current local system's DNS cache, including the browsers's and even trying another device on another network - I still get still no response on the browser.
Kept going, and attempted to verify that with a VPN (locally - which didn't work), and an online web proxy tool (which did work).
Finally, I extracted the router's default DNS server address, used nslookup to look up the URL again, this time specifically mentioning the desired DNS server (the one stated above), and after getting a successful response with the correct values, I am now pretty much sure the HTTP request is causing the problem.
The URL is hosted on Amazon S3 Static Hosting option, which I used many times before, and didn't have a problem with, with that exact same configuration. Looking up the recent changes/features that were possibly added, pointed out that I may need to explicitly set a CORS policy for the newly created bucket, on top of the usual public access policy that is needed.
After applying that as-well - it still doesn't seem to work.
As a quick change in direction that may possibly make some parts clearer about what's going on (and as I started to think that the browser might not be getting the correct Content-Type header in the response, which should be text/html header as its response, and therefore, possibly doesn't resolve the URL with the expected behavior), I went ahead and applied a 301 redirection on the S3 bucket, instead of the static files hosting, and again, it all works perfectly through the command line tools, but not through the browsers.
Anyway, the browser just doesn't seem to complete any of the requests being sent to the URL.
That might be the OPTIONS pre-flight request failing to respond correctly, and the browser just doesn't continue to issuing the GET request, or the URL is not being found by the DNS route the browser is taking, which is unclear to me currently if that is the option.
Any ideas? (besides the fact that sometimes it just takes longer time for some DNS servers that happen to be on the chosen route to update/refresh their cache, which doesn't appear to be affecting my local machine's DNS route specifically for this case. That, being said with caution, was verified by validating the different parts of DNS configuration and prioritization throughout the different possible parts on my system (Mac OS X), including the fact that the response gets back with the correct address successfully).
Found my answer here:
https://serverfault.com/questions/942030/aws-s3-static-hosting-how-to-debug-connection-timeout
As linked there, more details can be found here:
Non-Authoritative-Reason header field [HTTP]
Solution & Explanation: Because of the nature of the domain extension I have purchased (.dev extension) Chrome was silently using HTTPS because of the URL being part of Chrome's HTTP Strict Transport Security (HSTS), because all .dev domains should be using HTTPS only. Therefore, the issue was still showing up, even when explicitly typing http:// into the URL address bar.
This can be overridden by applying a CloudFront distribution with HTTPS support on top of the S3 Static Hosting, as usual (but still, it should be noted as HSTS listings can cause that for different cases, including this one as part of them, because of the .dev domain extension).
Useful Resources (for debugging purposes)
In addition to what is stated here:
https://gist.github.com/stollcri/7c09bafc97223481920e
You can issue a lookup query (and also add or delete your local set of HSTS listings) through the following Chrome's settings URL:
You can also check the current listings here: https://hstspreload.org/

ngx-translate access json file in different port

I am using ngx-translate for translating content in my angular app. But this is running in different port ( for example: 8090). I have done setup referring translatehttploader by referring https://www.codeandweb.com/babeledit/tutorials/how-to-translate-your-angular-app-with-ngx-translate
once I build and serve the app, it is throwing error as the json file not found ( Error 404).
The url it displays as
http://localhost/assets/i18n/en.json
if I add the port in the url (i.e.)
http:8090//localhost/assets/i18n/en.json
I am able to see the json content in browser. What I infer that it is referring default port 80. But it should refer the port 8090. So Can some one help me where I should configure the port to read json file by app to make translatehttploader serve from it?

s3 never-ending pending audio requests

I have an mp3 file on s3 (and have experienced with many other mp3 files) that is not playing in chrome (and other browsers as well: FF, safari, etc). The network dialog in chrome shows that there is a pending request that is seemingly never responded to by s3, however if I do a wget to the URL, I get an immediate response.
Additionally, if I serve the exact same file off of a server running nginx, I can access the URL in chrome as well instantaneously. I know that S3 does support byte range requests, so there should be no issue with chrome's byte range queries. Additionally, I've verified that the file is accessible, and that its content type is audio/mpeg.
Here is the file in question:
http://s3.amazonaws.com/josh-tmdbucket/23/talks/ffcc525a0761cd9e7023ab51c81edb781077377d.mp3
Here is a screenshot of the network requests in chrome for that URL:
I solved this by creating a CloudFront distribution. You need to create a distribution for your bucket. For example if you have a bucket named example-bucket, go to CloudFront and click on create distribution. Your bucket will appear in Origin Domain Name as example-bucket.s3.amazonaws.com
Now you can use example-bucket.s3.amazonaws.com url to load content.
This worked for me but I am not sure if it will work for others.
Had same exact issue with files.
Original url looked like this =>
https://my-bucket-name.s3-eu-west-1.amazonaws.com/EIR.mp4
Added CloudFront distribution and it solved all my issues.
Url changed only a bit:
https://my-bucket-name.s3.amazonaws.com/EIR.mp4
(but you can modify it a little while creating distribution / even setting your own DNS if you wish).

Accessing Apache Server from the internet

I have installed Apache on Xubuntu and I am have a problem accessing it from the internet.
If I access it via localhost I can reach the home page plus pages in the subdirectory. How if I access it from the internet I can get the home page but nothing else. When I type in the subdirectory and page, no links at this point, It either never leaves the home page or gets rerouted back to it.
I have no .htaccess files in place, I have tried adding an alias and entries in the conf file and I have checked ownership and permissions. I have gone as far as wiping the machine and starting with the same results.
I feel like it is going to be a case of missing something simple but I cannot think of what. The log files have indicated that an IP tried to access the subdirectory but shows no error in doing so. When typed into the URL the /Directory/Index.html shows in the address bar but it displays the home page.
Can anyone point me in the right direction?
Thanks,
Most likely the issue is contained either in your apache.conf file or your firewall. I would have a good look at your apache.conf to see if there is anything restricting access to your sub-directories.
if you want to use default http port (80), so long story short www.abc.com without explicit port number, you must allow this on your server because 80 is privileged on most system, this could be a problem