So I have a React/Redux application that is being served through Amazon s3 currently. We have configured s3 to render the index.html page on a 4xx error and serve our bundle.js. This allowed the react router to be bootstrapped and take over from there. Until recently this worked without issue. Now when I try to visit the page in IE or Edge I get the IE or Edge 404 page.
If I turn off the "Show friendly HTTP error messages" option on the IE browser everything works without issue. From the research I have done this is my theory on what is happening:
When the client hits the requested route the react router has not been bootstrapped yet. This results in the 404 that has to be rescued by rendering the /index.html page. When the 404 is returned IE/Edge steps in and renders their own 404 page which prevents the index.html from ever being rendered.
I am kind of at a loss as to how to solve this issue without actually using a full on backend. I can configure a redirect in the s3 settings to replace the root url with the index.html but this will break all of the sub-routes off of the main route. Is there a way to configure the application so that it works on all major browsers without actually implementing an actual backend?
EDIT: So I found this article which shows how this issue can be solved using cloudfront by rendering the index on a custom error: https://medium.com/#omgwtfmarc/deploying-create-react-app-to-s3-or-cloudfront-48dae4ce0af. Does anyone know if this is possible using cloud flare? I don't actually have the access to cloudflare personally so I am not sure of the possibilities.
If it works with "Show friendly HTTP error messages" disabled, then the issue can also be fixed by making your error pages longer. By default, IE will show those pages if it is less than 512 bytes.
OK so I discovered:
1) You cannot rescue this error in cloudflare.
2) You can put cloudfront in between S3 and cloudflare and simply implement a custom error rule.
3) Do not use the standard dropdown option when selecting the bucket for cloudfront. If you give the bucket name when configuring the error rule, cloudfront will treat it like a normal file not a static site and thus it fails to intercept the error. You have to use the fully qualified url for the bucket. I hope this saves someone some time. I lost some sleep over this issue.
Related
I made a simple weather app using react. It was working well. But when I hosted it on Github, it gives the error and is not working properly. Do someone know how to resolve this error?
Mixed Content: The page at '' was loaded over HTTPS, but requested an insecure resource ''. This request has been blocked; the content must be served over HTTPS.
my errors
2nd screenshot
To fix the error you need to make sure that all external resources are all running over HTTPS.
So in this instance, you just need to change the openweathermap.com resource to load from https rather than http. If you leave it as http, then it just won't get loaded and then you'll end up with a ton of js errors as the code wasn't loaded properly.
use https instead of http as the protocol of your base url
My apologies if the information that I have provided is vague as I am not so experience with AWS and React.
I have a React Application being deployed on S3 and CloudFront as per what is suggested in the following link.
Use S3 and CloudFront to host Static Single Page Apps (SPAs) with HTTPs and www-redirects
So most of the things are working fine. I have 403 and 404 errors being redirected to index.html. However the issue comes in where I have query parameters in my url. eg. https://example.com/example?sample=123 when I enter the url in my browser the query string gets removed from the url. The end result I got is https://example.com/example I have read some articles about forwarding query parameters but it's not working for me.
AWS Documentation - Query String Parameters
Hope I will be able to get some advise here. Thanks in advance.
The example?sample=123 is redirected to example because S3 sees example?sample=123 as path (a folder named example?sample=123), it will throw 404 as there is no such folder.
As you have mentioned, you have configured 404 -> index.html, the browser then goes back to example, which is very likely the default page of your react app.
Overall it looks like your query string is being cleared, actually it is lost during the redirection.
The solution includes three parts:
React
You can follow these two great tutorials, one for NextJs and another for RCA.
The way it works is to detect #! in the path, keep and store the query string after redirection.
S3
As included in the two links above, you have to set the redirection rule of the S3 Bucket, to add a #!/ prefix before the path on 403 or 404, it helps React to determine which parts of the url include query string. You can configure it in Properties -> Static website hosting -> Redirection rules – optional. You need to also set index.html as the Index document and enable static web hosting with the correct permission configured.
CloudFront
In General, set Default Root Object to index.html, make sure you don't make it as /index.html.
In Origin, set Origin domain to the S3 Static Web Hosting URL (http://[bucket-name].s3-website.[region].amazonaws.com, do not choose the bucket itself.
In Behavior, change Viewer to Redirect HTTP to HTTPS, set Origin request policy - optional to AllViewer to let all query strings go through.
Hope it helps.
I have spent a bit of time making this and it works well locally but on the server it breaks due to the below error. The API I am using seems to be on an insecure 'http:' address so the browser won't allow it's connection as my website is on an 'https' address. Is there any way to get around this with some kind of proxy/heroku thing?
Github
The broken app website
Mixed Content: The page at
'https://agwebdesign.net/react/petadoption/' was loaded over HTTPS,
but requested an insecure script
'http://api.petfinder.com/pet.find?key=920cf4ddd938497ba32bef47b7f35080&format=json&output=full&location=Seattle%2C%20WA&animal=&breed=&callback=jsonp_jfg1sgfprug5jl1'.
This request has been blocked; the content must be served over HTTPS.
This is what worked for me on react 16.12 hosted on vercel with a backend using an insecure 'HTTP:' address
Step 1. Go to the website's information section (the "i" button on the left-right corner, beside your URL)
Step 2. Scroll down to the "insecure content" and choose "allow" from the dropdown
step 3. Refresh your page and you're good to go
Why would you want to do this? You should be using HTTPS everywhere. With tools like Let's Encrypt there's no longer any excuse not to.
In any case, that particular URL seems to also be served over HTTPS. Simply change the protocol from http:// to https:// and it should stop getting blocked.
We are using AWS cloudfront to store our translation locale JSON files. Our Angular application gets these files via StaticFilesLoader in angular translate module.
In most cases it works perfectly. However after an environment is freshly created AWS could responses redirect to other location to get translation files. It is normal cloudfront behavior. But StaticFilesLoader is not able to follow this redirect and crashes with error:
XMLHttpRequest cannot load https://some.cloudfront.net/3...9-a...0-1..c-9...f/i18n/locale-en.json. Response for preflight is invalid (redirect)
Is there any known solution of this issue? Could you please give me some suggestion how to solve it?
A workaround could be to write interceptor to catch the redirect and fetch data with provided URL. But I decided to ask community before.
The users of our website run our Chrome plugin which, amongst other things, performs cross-origin requests via XMLHttpRequest as described on the Chrome extension development pages. This has been running just fine for a few years now. However, ever since our users upgraded to the latest version of Chrome (v38), these requests have failed. Our site runs on HTTPS and some of the URLs loaded via our content script are on HTTP. The message is:
[blocked] The page at 'https://www.ourpage.com/' was loaded over
HTTPS, but ran insecure content from 'http://www.externalpage.com':
this content should also be loaded over HTTPS.
The reported line where the error occurred is in the content script where I'm issuing the HTTP call:
xhr.send(null);
I have no control over the external page and I would rather not remove SSL from our own page. Question: Is this a bug or is there a workaround that I am not aware of?
(Note: The permissions in the manifest were always set to <all_urls> which had worked for a long time. Setting it to http://*/ and https://*/ did not help.)
If possible, use the https version of that external page.
If that is not possible, use the background page to handle the AJAX request (example).