I have a website and users create their own app. But i can't embed these apps on my website via iframe, because my website has SSL certificate and got this error:
Mixed Content: The page at 'https://domain' was loaded over HTTPS, but requested an insecure resource 'http://IP_ADDR'. This request has been blocked; the content must be served over HTTPS.
My workflow is like that:
Click create button
Deploy EC2 instance from AWS
Get IP EC2 address from AWS
Embed this app via iframe
I want to embed these IPs to my website, IP addresses are dynamic. Anyone can create machine anytime.
What is best practice solution for this issue?
Best practice (and also the only I can think of) solution IMHO would be to use proper HTTPS for the iframe content also. You'd need a possibility to automatically create DNS records though (you can do so with AWS Route 53). Regarding SSL you could use a wildcard certificate (e.g. Let's Encrypt). Nginx could be configured to proxy_pass by DNS name as opposed to IP. Then your workflow would become this:
Click create button
Deploy EC2 instance from AWS
Get IP EC2 address from AWS
Create DNS record
Embed this app via iframe
Related
I'm trying to put a simple Wordpress site on Google Cloud with SSL.
I set up a load balancer using an instance group, as described here: https://docs.bitnami.com/google-templates/how-to/configure-lb-ssl-google-templates/
except I used one-click deployment instead of bitnami.
unmanaged instance group with the vm as a member
load balancer with the instance group on the backend, port 80
front end HTTPS, port 443
The front end works, this is my test site: https://thescanclub.com
However, insecure access is still possible to the backend I.P. and also the database! I must have left out a firewall or something. How would you fix this?
Back end IP to the vm: 34.150.136.72
PS... this is a small test site and may get a new vm if I have to redo it.
The Google Managed Certificate that you created resides within the Front End of the Load Balancer. This means that it will only use the Google's SSL certificate, and redirect from HTTP to HTTPS when you access your Wordpress site through the Load Balancer's front end IP address or through the domain (thescanclub.com).
Digging the A record of your domain, you'll see that it is not pointed to the VM's public IP but rather to a different one which I presume is the HTTPS Load Balancer's front end IP.
If you wish to access the website directly from the VM's public IP, then it will be best to set up a letsencrypt SSL certificate within the Bitnami instance and set up the HTTP to HTTPS redirection through it. Hope you find this documentation helpful.
I have a full working Lightsail instance.
I successfully configured and bind to it my custom domain and, in order to use SSL, I created a Distribution with the associated certificate. Since I want to avoid using HTTP, in the DNS records I mapped my domain not to my static IP, but to my distribution.
Everything is working fine and if I navigate to www.exemple.com I am redirected to https://www.exemple.com
The problem is that my server is still accessible from outside the distribution through HTTP and if I navigate to its IP xxx.xxx.xxx.xxx, I reach it via HTTP.
Is it possible to avoid to reach the server from outside the distribution or to avoid it allow HTTP?
Thank you in advace!
I have a front-end deployed on Netlify and a back-end is deployed on localhost which is exposed using ngrok.
Is it possible to link them so that when I click on the Netlify link, it would send request to my localhost server exposed from ngrok ?
Netify can proxy to a dynamic backend, that is an intended use case. The problem we'll have is using "localhost" - netlify needs a valid hostname to connect to. So, if your ngrok is exposed (not firewalled) at some public IP, you can put that into your redirects configuration:
/backend-stuff-in-this-path/* https://1.2.3.4/:splat 200!
will send all requests to the path /backend-stuff-in-this-path/ANYTHING to the server at 1.2.3.4/ANYTHING
This may not be incredibly useful since your machine will change IP addresses sometimes one presumes, but if you were using localhost anyway, you weren't planning to put it in production quite yet. Note that redirects are deploy-specific, so you do need to redeploy to change the location if your IP changes.
Here is the situation:
I have a static website hosted by AWS S3(www.mysite.com), however, I want to also attach a blog to a sub-path with in my domain (www.mysite.com/blog) which uses wordpress on an EC2 instance.
How would I go about it?
Yes, this can be done, but you need to understand why the solution works the way it does.
A domain name points to a single logical endpoint, which handles all requests for the domain. If certain paths are handled by one system and other paths are handled by another one, then a single system must be in charge of routing those requests, and routing them through itself.
You cannot configure how paths are handled using DNS.
In my answer to Can I use CloudFront to serve a WordPress blog from the same domain, but a different server? (at Server Fault), I gave an overview of how this can be done in an AWS-centric solution. CloudFront, in addition to providing caching, is a reverse proxy, and that's fundamentally what you need, here: a reverse proxy to examine each request and select the correct back-end server. There are other solutions, such as using HAProxy in EC2 to handle request routing but they are more complex and may not perform as well in all cases.
You configure a CloudFront distribution with two origin servers (your bucket's web site endpoint and the Wordpress server), and use two cache behaviors so that /blog* goes to Wordpress and everything else goes to the bucket. Then you configure your domain name as an alternate domain name on the CloudFront distribution, and point your domain name to CloudFront in DNS.
The slightly tricky part here is that the wordpress site must be rooted at /blog and not at / because CloudFront will actually send the /blog (at the beginning of the path) to the WP machine, so it needs to expect that. CloudFront uses the path prefix to select the origin server (by finding the matching cache behavior for that path), but it can't remove the path prefix.¹
Wordpress is not my specialty, the this appears to require some WP configuration changes that appear to be fairly straightforward.
¹ CloudFront can't remove the path prefix. This will change when Lambda#Edge launches, which is an integration of CloudFront and Lambda functions, allowing server-side examination and manipulation of request and response headers from within the CloudFront infrastructure, but even when that is a available, it will still be advisable to configure WP to not be at the root, for simplicity.
By a different subdomain, I'm assuming that you want the blog to be at blog.mysite.com. I think that is the only way to go (you cannot use a /blog but will have to use a subdomain). In that case, following steps should work:
Create an Elastic IP and attach it to the EC2 instance
Configure the EC2 WP instance to respond to blog.mysite.com
In the DNS provider of www.mysite.com, point the A record of blog to point to the Elastic IP of the EC2 instance
I've developed a web app, which uses HTTPS and which works fine when I access is it (live). Yet some customers, who use proxy servers, can't access the site. I already tried to use a real certificate (a cheap one and only a trial, but yet valid), but that didn't help.
Everytime one of these users tries to access the site the browser tries to load it until a timeout occurs. One user even was shown an authentication (but I'm not 100% sure if this was due to a proxy, still waiting for response from the customer)
For which reasons can this happen and what can I do about it?
I'm using IIS, ASP.NET (C#) and JS. Sideinfo: The URL contains a port, the internal structure of the network the IIS is running in (not mine) doesn't allow it otherwise.
443 is dedicated port for HTTPS connectivity. Add type 'HTTPS' with default port 443 in Site bindings of hosted site directory. Check after whether SSL is enabled or not? in IE(browser)->Tools->Internet options->Advanced->Security.
If the HTTPS port in your web app's URL isn't port 443, you'll have a problem with corporate proxies that don't like non-standard HTTPS ports.
i.e. I hope your URL looks something like this: http://example.com:443/...