I have been trying to migrate my site from divshot to firebase, since firebase has taken over divshot and shut it down.
Mine is a simple read only site that does not need https. It also contains links to external sites which do not support https. The site worked perfectly on divshot but it looks like firebase forces all sites to use https. Unfortunately, this causes the external sites that my site references to fail loading. The error being:
Mixed Content: The page at 'https://mysite.firebaseapp.com/' was loaded over HTTPS, but requested an insecure resource 'http://www.externalsite.com/'. This request has been blocked; the content must be served over HTTPS.
I tried to remove the http: so the external site is just //www.externalsite.com/, but this causes certificate errors. I can't change it to https since this external site doesn't support it.
Is there any way around this problem?
The short answer is no. This is completely by design. It's a security flaw to allow http on a https site. Therefore it's blocked.
However,
Solution 1: Find a https version of resource This might not be possible in your case.
Solution 2: convert resource to https It might be possible to host the file or resource yourself with https. This may require you to copy a file or something, which I say carefully, don't pirate stuff that you shouldn't.
Solution 3: Redirect This one is probably the most involved solution to do but if you are trying to access some service then you could make your own service to redirect it. You are on firebase which means you could probably hack together some cloud function to make a http request (How to make an HTTP request in Cloud Functions for Firebase?)
Solution 4: Don't use Firebase Don't want to do any of the above and you can't live with out the http call? You might just dump firebase and move to some other hosting service.
Hope you find this helpful it might not be the answer your looking for but it might point you in the right direction.
Related
It's unclear for me and I haven't attempted yet, but would like to know if I can have a NGINX server routing traffic to a Firebase instance. I can't find relevant articles on internet and neither here so, maybe some fo you already tried this.
Background:
Our React app is running on Firebase already. But, we also have a landing page/website which is backed by Webflow.io to allow quicker edits with less developer frustration. They are also running on separate domains.
We already have an instance of NGINX(inside a docker container) as part of our API gateway so, would be good to use the same instance.
Result:
What we are looking to achieve, is to put both React app and landing page on the same domain. Then, use NGINX to route to required instance wether the user is logged-in or not. Anyone attempted something like this? If not this doesn't work, I'm open to general ideas on how to make it better from your experience.
You can totally do this, for example if you're using OAuth you can perform a token introspection from nginx whose result will determine the route to use, take a look at this https://www.nginx.com/blog/validating-oauth-2-0-access-tokens-nginx/
Alternatively you can use something similar to the google IAP that is probabely more easy to secure for production, i know that ory/oauthkeeper is easy to use, open source and hightly customizable.
I have seen that Google Firebase offers a static files hosting solution (for the front end) which is served in SSL and by CDN. That means, I can serve customers all around the world with a server located probably close to them and enjoying good speeds.
Now I want to do the same with my Node.js backend code.
That means, instead of hosting my backend code in my own VPS, that will be probably fast only for who lives close to my server, I want to deploy the same server to Firebase's CDN and ofcourse, over HTTPS.
What I have found for now is the Firebase Functions which is probably a Node.js server. However I am not sure if its running uppon a CDN, so it will be fast just as the static files serving, or that its just a server located somewhere in US that has to serve worldwide.
In addition, if there is such a service - where I can host my back end code with SSL, may I have the "standard" express configuration I have now on my VPS?
And what for about clusters/workers? How many workers I can have when using the Firebase solution (if there is one like that).
Thanks.
SSL and firebase functions & hosting?
You get HTTPS by default for hosting and functions. If you need functions to served from your custom domain and not https://us-central1-[projectname].cloudfunctions.net, you will need to configure your firebase.json file to rewrite your routes to your firebase functions. The main thing to flag here is both options you get HTTPS and certs issues directly from google/firebase.
When you bring a custom domain over it can take up to 1-2 hours for firebase to issue the certificate, but all this happens automatically without you having to do anything.
Does firebase functions integrate with a CDN?
Yes, but you need to set the correct s-maxage header in your response to ensure the firebase CDN will store it. See here for more info on this.
Cache invalidation is still hard with firebase so I would keep this in mind before you set anything.
How many workers I can have when using the Firebase solution (if there is one like that).
One benefit of using firebase functions is that you don't need to really give much thought to the resources behind the backend. If you have heavier workloads you can increase your ram/ cpu power in the google console for your selected function. The endpoint will scale up and down depending on how many requests it gets. On the flip side if it doesn't get any requests (usually in non prod environments) it'll go to an idle state. You need to be aware of a cold start problem before you fully commit to using this as a replacement to your current nodejs VPs hosting solution.
I personally use the cache control headers to ensure the functions responses are pushed into the CDN edge, which takes the edge off the cold start issue (for me and my use case).
I recently moved a website from https://www.ezacu.com to http://www.ezacu.com and I'm finding that the website loads for people who have never visited the https version, but not for people that have.
I believe that this is either because their browsers keep autocorrecting http to https (since it used to be https) or because their browser is trying to use a cached version. Im not sure how to find out or how to fix the issue, but it is especially difficult for me because it works on my computer/phone; The issue is with other users.
I am hosting the website on amazon S3
The simple solution is to create a CloudFront distribution with your domain name as its Alternate Domain Name, attach a free SSL cert from Amazon Certificate Manager, type the web site hosting endpoint from your bucket as the Origin Domain Name (don't select the bucket from the drop-down list -- that won't enable the web site hosting features of S3), then point your DNS to CloudFront.
When you use CloudFront with S3, you pay bandwidth charges to CloudFront instead of to S3, so the cost difference is negligible and in certain cases, bandwidth can actually cost slightly less.
There isn't a way to convince browsers not to try to use HTTPS once they believe it's available.
My app is remotely updated with image URLs from tons of different sources, most of these on HTTP servers. Now, these HTTP URLs won't download because of App Transport Security.
Apparently I have two options.
Allow all HTTP URLs: Bad practice, possible App Store rejection
Allow specific domains: Not possible because this would mean I can't remotely add images
How can I download the images without disabling App Transport Security?
What if you programmed your own web based API that downloads and stores said images - then you can retrieve them with a call to it. Secure your API with HTTPS. This also gives you more fine grained control in that you own the server you are querying instead of accessing someone else's.
We provide a third-party site to clients. Frequently when we are handling an RFP, we are asked if it is possible to embed our site within our client's site. Many of our prospective clients have unusual limits or requests, such as 'do not use iframes'.
To that end, I've been asked to ensure that our upcoming redesign of our site makes it practical to embed in client's sites in at least two ways.
The methods of embedding a full-functioning website (as opposed to a cross-site image or piece of static content) within another are as follows:
iframe - Much used, frequently maligned, and some of our
previous RFPs have specifically excluded this as a possiblility.
Object/Embed tags - going way back, it's possible to embed a
full-functioning HTML page into another the same way you would embed
a flash object.
Ajax - Supposedly capable of loading a full
site into an HTML object (such as a div tag), but there seem to be additional security hoops to jump through, due to the dangers of cross-domain requests.
Are there other methods for placing a full site within another from a different domain? Are there any caveats or limitations to any of the above three (for instance, our site uses AJAX calls for login and to update some user-defined settings, will those all function correctly in each of the above embed strategies?) that I might be unaware of?
Thanks in advance.
X-Frame-OptionsResponse Header
If you are embedding your site to somebody else's site, you must be careful about the X-Frame-Options response header. Make sure your site does not send SAMEORIGIN as the value for X-Frame-Options. If you do, it will cause problems for iframes and embedded objects. You can do two things:
You absolutely do not send the header: Any site will be able to display your site in an iframe or as an embedded object. This can cause security problems like clickjacking. See this article for more info and defense on clickjacking.
You can make sure only the site you authorize will be able to embed your site: This is done by sending ALLOW-FROM url value for X-Frame-Options header. You can sniff the HTTP-referer to identify which site is requesting your page. This is really secure than option 1 (unless users' browsers are malicious, of course). NOTE: Not all browswers support ALLOW_FROM. See linked reference for supported browsers
Same Origin Policy
Same Origin Policy will not affect you as far as your site and your clients site do not access each others DOM.
CORS
Cross-Origin Resource Sharing should be considered if a script from your clients' website makes an AJAX request (XmlHttpRequest) to the resources in your site. But as far as your question is concerned, this is not the case, I think.
I gave an answer explaining CORS some time back, you can read it if you want to get a basic understanding of CORS.
Plugins for third party sites
It seems like you are trying to embed some functionality in clients site. Consider offering site plugins like those Facebook and Disqus does.
I am not sure if Same-Origin Policy or CORS applies here. I will find that out and get back to you.
Note: X-Frame-Options, Same-Origin Policy, and CORS is implemented by browsers. There's nothing you can do if the users browser does not implement these things, or if the browser is hacked to not respect these security policies.