we have an apache reverse proxy in front of our meteor app. there is no firewall between the proxy and meteor so users who can hit the proxy can also hit meteor. i want to restrict meteor app access to ONLY the reverse proxy. the meteor app and the apache proxy are hosted in OSE 3
i thought of 2 main possible solutions.
1) use OSE3/kerbenetes to restrict meteor access to ONLY the apache proxy
2) include a signed http request header value in proxy to meteor request so meteor can verify the request is from the proxy. - could not figure this one out
i prefer option 1 to option 2. how can i leverage services in OSE 3 to accomplish option 1? if option 1 is not possible how can i do option 2? if both are impossible, what alternatives do i have?
Routing in ose3 exposes a service to the outside world. So if we remove a route then the service is only available internally through its cluster ip. Thus remove any routes associated with the meteor app and only leave a apache proxy route exposed. Then in side the apache httpd.conf proxy using the meteor app's ip address.
Related
I want to share access to a website e.g abc.com which is protected with login. I don't want to share passwords so I want to add cookies to the request using a proxy server. After some research I found that we can use ngix or apache to proxy forword requests.
But now I need guidance or a tutorial how to set things up on a apache or ngix server
I have a Website that runs on a web farm (4 servers) behind a load balancer. The load balancer is the one that has the ssl certificate for https and decides to what server the requests go to.
In the code for the website, using .net Core I have in the startup.cs file logic in the Configure method to force the https redirection with app.UseHttpsRedirection(); So when we access the site without https the .net core permanent redirect the user to the https version (this is importand bc the web app is a PWA, so we need it for use service worker)
Imagine the url to access the website is https://production.website.com, again if the user try to go to http://production.website.com, it will redirects to https version. But you can also access each server in the web farm directly using these subdomains http://prod1.website.com, http://prod2.website.com, http://prod3.website.com, http://prod4.website.com (we have this set bc we want to test individual servers in case a deployment error happens on a specific server).
The problem is, bc the ssl certificate is in the load balancer (production.website.com domain), when you try to go directly to a individual server (prod1, prod2, prod3 or prod4) the .net core will redirect it to the https version and that server doesnt have a ssl certificate and the user will see an error on the browser, so we need a way to control that with a condition. So what the problem is? that at the startup.cs code we dont have access to the site url bc we dont have a request yet, I have research a lot and some workarounds that use to work in the past now with .net core 3.1 dont.
So how I can make that the code in the configure method doesnt force a https redirect if the users is accessing the individual servers and not the main domain for the web site?
Where I work theres an web app that is hosted on windows servers, all users access the application using HTTP, not HTTPS. This is due to some restrictions that the dev team could not solve.
So I thought that i could solve this issue using HAProxy and SSL Termination, so the users would communicate with the proxy first using HTTPs and then the proxy would communicate with the app servers using HTTP. This would be inside a private VLAN so the HTTP traffic cannot be sniffed.
The users access the app using this schema --> http://servername:port/path/to/app
So instead of this, the users should type https://haproxy.domainname:port/path/to/app
and the haproxy should handle the communication against the app servers.
Is this possible? or should i think of another solution to this?
I came up with this:
frontend haproxy.domain.name
bind ipaddress:port ssl crt /home/cert.pem
acl is_bdc path -i -m beg /path/to/app
use_backend web_servers if is_bdc
default_backend web_servers
backend web_servers
balance roundrobin
server server1 ipaddress:port
I can access the app server using this configuration, but the app fills some variables using the URL of the web browser, and as im accessing the app using another URL (haproxy.domain.name instead of the app server hostname) its causing some errors. Is possible to maintain the app server hostname on the url but also keep the SSL termination? The used certificate its a wildcard so adding the domain name would be enought (i think)
Thanks you in advance!
Well there are several options to solve your issue.
1.) Tell the app server that it runs behind a reverse proxy and configure the app engine to use haproxy.domain.name as Domain/Host part, something similar to tomcats Proxy Support How-To
2.) you can use the http-response replace-header or replace value to rewrite the URL. This will not work with links in the body of the response.
As you haven't mention the HAProxy version I link to the latest one.
Maybe you will need also to configure the IIS to know that it works behind a reverse proxy, in case you use IIS.
Ant-Media-Server is running on an IPAdress without any domains. We just set up this server to be used for streaming in order to use it from different domains pointing to different servers.
Since all of our domains use ssl, we face the typical connection problem:
mixed Content: The page at 'https://SOMEDOMAIN.com/QUERY' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://1.2.3.4:56'. This request has been blocked; this endpoint must be available over WSS.
Ant-Media already offers tutorials on how to install a Let's Encrypt SSL Certificate but sadly it is not available for pure IP-Addresses.
Apart from the Ant-Media Service, the server doesn't has any NGINX, NodeJS, Apache or other http Servers installed - the plan was just to use it for streaming by calling the IP-Address.
Do you have any ideas on how to solve that problem?
Unfortunately, this is not possible.
The goal of having a SSL is ensure you are requesting the right domain name besides encrypting the content between your users and your server.
Here are some alternatives:
create an endpoint in your own app that proxies data to your server.
Instead of playing the IP address, you can play:
/your-proxy-url?stream=http://yourIp.com:port/....
Note that using a proxy will make all the traffic pass through your web app.
As a reference, if you are using PHP on your website, you can have some ideas from here: https://gist.github.com/iovar/9091078
Create a reverse-proxy in front of your web app that redirects the traffic to your IP address.
Both solutions does not change your Ant Media Server, just adds a new resource between your users and your streaming server - adding the SSL on it.
I have build a saas product with angular 4 integrated with golang rest api and uploaded the build on aws ec2 instance. My project is a multi-tenant based app which loads customers dashboard on merchant-name.mystore.com subdomain but some of the customers asking for custom domain feature like they should be able to load the app on mydomain.com .
I have done the the subdomain part with following code in apache2.conf file so all subdomain loads from apps folder where the angular app files located
<VirtualHost *:80>
ServerAlias *.mystore.com
DocumentRoot /var/www/html/apps
<Directory "/var/www/html/apps">
AllowOverride All
Require all Granted
</Directory>
</VirtualHost>
For custom domain feature I have a section in admin to save custom domain but not sure how should I implement it.
possible method I thought about are
Create virtual host file and update it on each merchant signup with his custom domain
Do it somehow with htaccess file and mod_rewrite
Shopify do it but not sure how they load merchant specific store. Another point kept me busy thinking about is what values should I ask to update
IP address on domain registrar
Name servers ( not sure what it will be for my on aws )
Ask to create CNAME or A record as some of the article suggest
I have a similar setup on a number of SaaS platforms I develop and manage. This type of setup is certainly desirable, as your clients suggest. You should plan to serve each customer site on its own domain, probably also with *SSL, from the begining. In my opinion, this is best practice for a well architected Saas service today.
In reading your question, I think you are over engineering it a little.
For a custom domain Saas app on the same server, you simply open port 80 to all traffic, regardless of domain name. Point all customer domains to app.mystore.com, which is a CNAME to your app endpoint.
The app then reads the HTTP request header, and in that way determines the host name that was requested.
Finally the app looks up the host name in its client database, and locates the client record for the give customer domain.
For example, in Nginx all you need is:
server {
listen 80 default_server;
server_name _;
root /var/www/myservice/htdocs;
}
This server configuration provides a catch all for any domain that points to this endpoint.
That is all the web server should need to allow it to answer to any customer domain. The app must do the rest.
* When you serve a custom domain on an app on this domain, you should plan to serve the SSL endpoint for the domain, eg https://www.mycustomdomain.com. Consider this in your architecture design. Consider also the DNS issues also if your app fails over to a new IP.
The accepted answer is satisfactory but it only skims over the most important part, and that is enabling HTTPS by issuing certificates for third-party domains.
If your customers just CNAME to your domain or create the A record to your IP and you don't handle TLS termination for these custom domains, your app will not support HTTPS, and without it, your app won't work in modern browsers on these custom domains.
You need to set up a TLS termination reverse proxy in front of your webserver. This proxy can be run on a separate machine but you can run it on the same machine as the webserver.
CNAME vs A record
If your customers want to have your app on their subdomain, e.g. app.customer.com they can create a CNAME app.customer.com pointing to your proxy.
If they want to have your app on their root domain, e.g. customer.com then they'll have to create an A record on customer.com pointing to your proxy's IP. Make sure this IP doesn't change, ever!
How to handle TLS termination?
To make TLS termination work, you'll have to issue TLS certificates for these custom domains. You can use Let's Encrypt for that. Your proxy will see the Host header of the incoming request, e.g. app.customer1.com or customer2.com etc., and then it will decide which TLS certificate to use by checking the SNI.
The proxy can be set up to automatically issue and renew certificates for these custom domains. On the first request from a new custom domain, the proxy will see it doesn't have the appropriate certificate. It will ask Let's Encrypt for a new certificate. Let's Encrypt will first issue a challenge to see if you manage the domain, and since the customer already created a CNAME or A record pointing to your proxy, that tells Let's Encrypt you indeed manage the domain, and it will let you issue a certificate for it.
To issue and renew certificates automatically, I'd recommend using Caddy, greenlock.js, OpenResty (Nginx).
tl;dr on what happens here;
Caddy server listens on 443 and 80, receives requests, issues, and renews certificates automatically, and proxies traffic to your backend.
How to handle it on the backend
Your proxy is terminating TLS and proxying requests to your backend. However, your backend doesn't know who is the original customer behind the request. This is why you need to tell your proxy to include additional headers in proxied requests to identify the customer. Just add X-Serve-For: app.customer.com or X-Serve-For: customer2.com or whatever the Host header is of the original request.
Now when you receive the proxied request on the backend, you can read this custom header and you know who is the customer behind the request. You can implement your logic based on that, show data belonging to this customer, etc.
More
Put a load balancer in front of your fleet of proxies for higher availability. You'll also have to use distributed storage for certificates and Let's Encrypt challenges. Use AWS ECS or EBS for automated recovery if something fails, otherwise, you may be waking up in the middle of the night restarting machines, or your proxy manually.
Alternatively, there have been a few services like this recently that allow you to add custom domains to your app without running the infrastructure yourself.
If you need more detail you can DM me on Twitter #dragocrnjac