I would like the root of my domain uses cloudflare page static website and to have some dynamic directories which use cloudflare Tunnels.
Ex.
x.com/index.html (static)
x.com/submit (tunnel to a backend)
Configuring tunnels with two different paths works well (ex. submit.x.com/submit and x.com).
Is it possible ?
Related
I am trying to integrate the liferay tomcat with apache web server.I successfully integrate the liferay with web server.
Condition:
Life ray deployed on ip say : 10.10.10.70
Apache web server on ip say: 10.10.10.80
I provided all the requirement virtual host requirement in httpd.conf file..and provided the web.server.host in portal-ext.properties file.
Problem: When i run liferay portal i can open it on ip: 10.10.10.70
but when i click on any page link (let say /home)that is present in my portal it moved the request to
10.10.10.80:8080/home instead of 10.10.10.70:8080/home
I want to know how to handle this condition.
Because i dont have any page resource on web server doc folder only contain static css..
You might be a bit more precise what "all the required virtual host settings" are, e.g. what did you configure?
Note that by explicitly configuring hostnames/IP-addresses, you're explicitly overriding the autodetected settings from the request - no matter how you get to your portal, Liferay will generate URLs based on the explicitly configured hostname/port.
What's the point in having an Apache in front and then trying to reach tomcat through the non-apache IP/Port? Typically you might have static resources, rewrites, caches on Apache, so that you'll get different results when you alternatively access tomcat through both URLs.
If you configure Apache to "properly" handle the requests before tomcat sees them, you'll typically not need to configure Liferay at all, because Apache will make the actual hostname that it's requested under available to Tomcat. I'm typically using mod_jk for this and it beautifully handles all the configuration with almost no need to explicitly configure tomcat/liferay. If you don't like this, keep in mind that you're explicitly configuring Liferay for the virtual host setup - naturally this explicitly configured name is what Liferay uses. It would be weird if the explicit value would not be used, right?
I am trying to use CloudBees PaaS (RUN#CloudBees) to consolidate essentially three different distinct uses under the same URL space:
root (/) main landing, marketing page
app (/app) java app running in CloudBees
blog (/blog) another java app running in cloudbees or possibly outside (example.wordpress.com)
If I was doing it myself in a datacenter or in AWS I would setup a reverse proxy (possibly like Varnish and configure reverse proxy to map the URL space as follows:
root (/): www.example.com/ --> CMS running as cloudbees app example-cms.cloudbees.net
app (/app) java app running in CloudBees www.example.com/app -> app.example.com
blog (/blog) similarly www.example.com/blog -> example.wordpress.com or exampleblog.cloudbees.net
How can I achieve the same with CloudBees. Can it be done? Is this too much to expect from a PaaS vendor?
An interesting problem, and a few solutions:
Use domains instead of paths (eg blog.example.com etc) - so you can use DNS to direct things
Build an app that essentially proxies traffic for you (this could run on cloudbees or elsewhere) - there are lots of ways to do this.
Use some routing/proxy service (like CloudFlare) which may let you set up routing rules (so it can proxy traffic).
My preference would always be for number 1 - DNS is a great way to do things like this.
You can with this approach have /blog similar Urls in your paas application, and have it do a 302 redirect to the real blog.example.com - that kind of gives you a bit of both.
I've setup 4 sites on a LAMP stack and pointed a number of domains at the server. Everything is running nicely but for some reason, none of the sites have the http:// prefix.
It isn't a massive problem but down-the-line, these sites are going to run https on secure areas and I want visitors to be able to differentiate.
Why would Apache NOT display the http:// prefix? I'm using named virtual hosts and have modified my /etc/hosts file to point the relevant domains to my server's IP.
It's most likely the browser hiding the http:// prefix. It should be happening on every other web site you visit with that browser, too.
You can't control this with Apache - but don't worry, in https mode, the browser will make sure the user sees the difference.
The setup is:
www.domainA.com
www.domainB.com
both actually hosted on one web server (Apache)
123.123.123.123/domainA
123.123.123.123/domainB
I have setup a hidden forward from the domains to the web server directories which works fine, however, produces duplicate content (since it is also available by addressing the web server directly). I tried setting up 301 redirects to the domains for every request that is targeting the IP address directly (using mod_rewrite),but found that this results in a forwarding loop. Obviously the server does not recognize whether the domain has been requested originally.
If anybody can give me a hint on how this is supposed to be done, I'd be glad to hear.
You can set up virtual hosting on the web-server so that it does pay attention to the hostname that was requested. This is a fairly common practice and should solve your problem. You can do away with separate subdirectories since each virtual host has its own virtual root.
So are you saying that you have pages indexed in google that reference your IP address and a directory rather than the domain name?
Also, I'm not sure why doing a redirect from the IP to the domain name would cause a redirect loop. If the redirect is based on the host header, it should work fine.
We noticed that a hacker created a domain and configured DNS to point it to our server's IP address.
We are using apache2.x on Ubuntu.
There is a "default" file in apache's /etc/apache2/sites-available directory and it looks like the the hacker's domain is using "default" apache configuration file to display our web content in their domain.
How can we prevent this?
Can some one post a "default" apache configuration file as an example?
Unknown domains that come into apache over the specified ip and port will be directed to the first virtual host, thus the 000-default file. Your best bet is to make the 000-default host return a 400 or 500 error (or some explicit message saying the domain doesn't belong) and use explicit virtualhosts for each of your sites.
+1 Jeremy's answer: make the default (first) virtual host for each IP address you're listening on return something useless like a 404 or page saying nothing but “this is a virtual server”.
Allowing your web server to serve a real web site on a non-matching ‘Host’-name (including a raw IP address) opens you up to two particular attacks:
DNS rebinding attacks, leading to cross-site scripting into your real web site.
This affects sites with a user access element (eg. logging in, cookies, supposedly-private intranet apps).
‘Search-hijacking’. This affects all sites (even completely static ones). This may be what is happening to you. By pointing their own domain name at your server, they can make search engines see both the real domain name and their fake one as duplicates for the same site. By using SEO techniques they can then try to make their fake address seem like the more popular, at which point the search engines see that as the canonical address for the site, and will start linking to it exclusively instead of yours.
Most web servers are configured by default to serve a web site to all-comers, regardless of what hostname or IP address they're accessing it through. This is a dangerous mistake. For all real live sites, configure it to require that the ‘Host’ header matches your real canonical hostname.