Hello, i am totally noob about this topic but i need to getting working this functionality and i don't know how to resolve it. i will apreciate a lot any idea, contribution or advise.
Lets say:
One site named:
appointmentsserver dot com
(IP 1.2.3.4 )
And my customers sites are:
Customer1 dot com
(IP 5.6.7.8)
Customer2 dot com
(IP 6.7.8.9)
(I am admin of these three websites/servers)
I'd like to configure them for get working something like this:
if a visitor click a link with below addressor write at browser address bar this web address:
booking.customer1 dot com
or
booking.customer2 dot com
the visitors browser goes to
appointmentsserver dot com
and it serves a webapp for booking.
BUT visitors browser address bar keep showing customers booking subdomain like this:
booking.customer1 dot com
or
booking.customer2 dot com
and hides real appointments server name.
To keep easy and simple the whole process for visitors, all the time real appointment server name (appointmentsserver dot com) is hiden.
i think that how to resolve this configuration gona be a lil' bit tricky 'cause maybe includes dns configuration, IPs redirection and some mod_rewrite rules.
You mention in your thread title wanting to use mod_rewrite to do re-direction. Whilst it's true that mod_rewrite can certainly do this, it would fall down on one of your specific requirements: that you hide the URL of the server you're re-directing to, and make the end user still believe they're talking to the original Web site on its domain name.
Used on its own, mod_rewrite cannot do that, without also being combined with other Web server modules such as mod_proxy. It can certainly re-write URLs however you would like, and Apache also has far more straightforward mechanisms for re-directing traffic from one URL to another. But in each of these cases, unless you also combine it with a proxying setup, the end user will always see the "real" URL they are actually talking to in their address bar when the re-direct is done.
If you want to hide the re-directed URL from the end user, you either need to combine modules as mentioned above, or use a far more straightforward HTML frame-based re-direction technique. This is where in your Web page content you have an embedded frame that loads content from a Web page on another Web site. In this way, your content actually comes from domain number two, whilst the end user is loading domain number one in their browser.
However, there are trade-offs there too. These days, hiding information - any information - from users is generally seen as a bad thing to do from a security and privacy standpoint. The end users' privacy (in most typical circumstances anyway) is always more important than the privacy of the Web site or server that they are connecting to. The balance of power here, so to speak, lies strongly in your favour as a Web hostmaster. By definition you know all kinds of things about the clients connecting to your server, and have the means to retain that information more or less indefinitely (technically, at least).
And most modern browsers and search engines tend to take a very dim view of Web sites that behave in what could be a deceptive fashion. I'm sure you can easily imagine how frame redirection or its functional equivalents could be very simply used by people running phishing sites, spamvertising sites and other such abusive content, to make users think they are talking to one Web server when in reality they are talking to another. Your search engine rankings can also take a heavy hit if you are using frame re-directs.
In general, if you are going to re-write or re-direct your clients from one site to another, it is best to use the simplest mechanisms available to do so, and to be totally up-front and honest with your end users about where they are being re-directed to, and when. A customer has to be able to trust that what their Web browser is telling them is true. And if they feel that your site is lying to them - or if their browser or Google pop up a nice big warning screen telling them that it might be - they're not likely to stick around for long.
This is not tricky at all if you follow a "normal" approach for building a web application.
First of all, each of your "subdomains" should have an API which you can query from the "main server" and pull, modify, etc. the data as required.
The approach you are using was popular around 15 or so years ago before all web developers move to using RESTful APIs to manage data between servers and sites. You are attempting to do something at the "visual layer" which should be done at the "data layer".
So, when you query your "appointmentsserver dot com", the web application on that server should do a RESTful query to the appropriate "Customer dot com" API and pull the data required to be displayed for the user. Likewise for all RESTful functions such as GET, POST, PUT, and DELETE.
I'm sorry to tell you; but your approach is not the way modern web apps are designed (and when I say "modern" I use this term to mean "in the last 10 to 15 years"). We don't use HTML redirects, hiding URLs, etc. to accomplish what is done with having APIs at each service (app) so you can just call those APIs when you want to GET, PUT, etc data from one server to display on another.
Because you are the web admin of all those servers, then it should be no problem for you to build / expose an API for each app and build a basic RESTful web app.
This is a very basic "web developer" task, to be honest; and is not "tricky" because it is just a basic web dev function / task for a web developer.
Cheers.
See also:
@Haxo, your web apps are written in what web-dev stack? Ruby on Rails? Django? PHP?
You should be working at the web-dev layer to get these apps to interact, not at the "hack the web server and create redirects" level. That is not how interactive web apps are built. We generally strive for a MVC or a MVVC architecture where the model (the database structure, validations, basic DB check, some business logic), the controller (where the bulk of the application logic happens) and the view (the presentation of the data) and independent of each other. You, @Haxo are trying to manipulate the web server configuration to do what is done at the API level using a RESTful approach.
Hi @drysdalk
Thank you for your answer so full of common sense and honesty.
Certainly the transparency and veracity with which a site is driven is not only valued by the visitors, prospects and customers of a site, but is also analyzed, classified and even penalized by Google. The ethical approach that you mention is very valuable advice.
Although it was a surprise to receive a response with the absence of technical information, I value your advice and must take it.
Within the scope of ethics, including in an iframe the site that makes the booking service, without warnings or mentions seems incorrect. But, how about using the same iframe technique and making it highly visible (for example):
this booking service is
Powered by
appointmentsserver dot com
I want to do things right and I think that would help to be truthful and transparent.
hi @Neo, so long time ago!
your advice is very useful.
now I begin to see how important it is that I learn to build correct and secure modern communication between servers by developing an API.
Honestly, I had not thought of doing it like that, because my knowledge is not that extensive. As a simple and basic webmaster I am more familiar with the frontend of the websites (what is seen in the browser) it is clear and evident that I have minimal and limited knowledge of sysadmin, just enough to install and configure a new server and design the website that is needed.
I appreciate your kind invitation to develop API work and modernize my way of doing things. your post invites and motivates me to learn techniques and methods that before I had not been concerned or interested in learning. I am going to deepen to begin my modern technological education, that is to say to update myself.
As for your proposed approach: that would certainly be an improvement over the users having no visibility of the re-direct behaviour, yes. Another approach, however, if your site is dynamic rather than static (which from what you say about it being PHP-based appears to be the case) is to have the site show different content depending on what URL it is loaded with, which is one element of the solution that Neo mentions.
So, for example, let's say you have two domains that you want to show content for. In reality, you set one of these up on your Web server as the primary domain (again, assuming you're using Apache, this would be the ServerName domain used for the virtual host entry). Your additional domains, you bind to the same Web site, but as ServerAlias configuration entries. You also ensure DNS for each of the Web sites points to the Web server that this Apache virtualhost is configured on.
Now, when users visit either the ServerName domain or one of the ServerAlias domains, your code controls what content they see. You could do this by looking at the URL the user has arrived at, which domain name they are using, and then return the content for the appropriate site. So whilst you have one single Web site entry in Apache, and one single set of content in the Web root for the site, the content returned to the end user is controlled by your code, and determined by the URL they used to load the site.
In this way, you avoid re-directs altogether, and avoid needing to maintain multiple Web sites, Apache virtualhosts, Web roots, and so on. Everything exists in one place, with all your domains bound to it, with your code controlling what content gets returned by an HTTP request.
Hope this helps ! If you have any questions or if anything about this doesn't quite seem like it would work for you, please let us know and we can take things from there.
@Neo
thanks for your kind contribution and advice. I have nothing left but to work on developing the solution, but the most important thing is to follow your opinion regarding modernizing my methods and technologies for web development and administration of my machines.
Please keep in mind that just about all "modern" web applications which expect to share data with other web applications are built with an API for sharing data at the data level.
The most basic way to do this is to simply render two different formats for each URL. One renders in HTML (like you are seeing, the standard "user" view) and the other renders in JSON, which is the "machine-to-machine" API view).
If you look at this topic, you can see this in action in these forums. (Click on both of these links below)
Here is the link for the HTML view:
Here is the link for the same page in JSON format:
You can see that the URL is only different in that one has the .json extension. As @drysdalk mentioned, the underlying application (in this case Ruby on Rails) detects the .json extension and renders a JSON version of the same page.
So, when building any web app these days, most web designers insure that each page (which has any chance of having data that is required by another application) is rendered in both HTML (end user view) and JSON (the machine view for other machines and applications).
However, this is not the end of the story.
For many applications, like embedding the weather from one web site into another web site, this kind of simple JSON rendering / parsing is enough. The same is true for showing the flights available for a particular route or the number of concert tickets available for your favorite rock band.
However, what happens when you want to actually book a hotel or a flight from that travel website on your own web page or you want to sell concert tickets on your own web page? These days most sites have an API which you can register for which will permit you interact with their website and do the RESTful web calls you need to "do the deed". You register with that site and get an API key which uniquely identifies you and also provides some basic API security (your API key and your password, for example) and of course you can only access these APIs using an encrypted link (HTTPS) to keep these keys and shared secrets encrypted in transit.
We generally don't use Apache2 configuration settings (server aliases, virtual hosting, redirection, etc), for most of this. That is the way it was done in the "dinosaur days" of the web; and that was a long time ago. However, we might use information from URLs to instruct the application what services (or servers) to render and how to display that data.
In your case, it is the same. Regardless of your applications, for example, if you are providing a service to "play a game" or a service to "book appointments" the core concept is the same. Each site which offers a service generally renders in both HTML and JSON formats; and the underlying application will specify what is rendered for HTML calls and what is rendered for JSON calls.
This works for all RESTful methods so you can view, create, destroy and update records as required.
The data is rendered in JSON because JSON stands for "Javascript Object Notation" (off the top of my head) and so JSON can be read "out-of-the-box" with both Javacript running in the browser or for by a web server or other server side app (which man be any programming language like PHP, Ruby/Rails, Python, etc). JSON has become the "de-facto standard" for machine-to-machine communication on the web.
If you render your data in this manner, you generally don't need to use IFRAME tags, aliases etc (I never use these older techniques anymore, BTW). IFRAME'ing is not used very often these days; as it is a kind of "relic of the past" although there are isolated cases where IFRAME'ing one web site into another is used; but this is rapidly growing obsolete for many reasons (including cybersecurity reasons) because IFRAME'ing has been abused by spammers and bad actors for so long. For some "big tech" providers (like Google), IFRAME tags are a red flag.
@Haxo, since you already know how to to render a web page in HTML as a very basic web developer, it is easy to learn to render these same pages in JSON so you can easily pull that data and process any way you want (based on URL, IP address, server alias, time of day, phase of the moon, country, city, zip code, weather report in your area, how many stars in the sky... well you get the idea).
The days of viewing web sites as rendering in only HTML are long past us, and most everyone who builds a web application these days render in both HTML and JSON if they want to share data between applications (which most people do, after all that is what the web is really all about).
