I have a situation where there are two versions of the same website live at the same time; only differentiated by sections. As we launch a new section, we route traffic to the newer site and remove access from the old site. Im wondering if Application Request Routing (or similar routing software) can be used to specify url patterns, and forward to a binding (same host) with a specific IP address?
Related
Say we have an internal URL https://my.internal.url (in our case a Liferay Portal) and from a web application firewall an external URL https://my.external.url pointing to this internal URL.
The internet user is using the external URL.
PrimeFaces extends attributes like for example
onclick="...;window.open('https://my.interal.url'..."
This leads to CORS problems.
The HTTP header Access-Control-Allow-Origin is not an option, since the internal URL is internal.
We'll talk with the WAF people about URL replacement, but I'd like to know wether or not we can tell PrimeFaces to use the external URL (or maybe relative URLs in case this would work).
The portal doesn't know about the external URL but of course we could implement this as a configuration option.
(watching the source code, there are more occurences of the internal URL outside of the jsf/PrimeFaces portlet, so I add the liferay tag too)
Update
The question is obsolete, WAF has to handle this correctly (an old SSL environment did it, a new WAF environment doesn't)
You say
The portal doesn't know about the external URL
however, any properly configured reverse proxy (or WAF) should forward the actual host name used to request the current page.
On Apache httpd's mod_proxy_http, this is done with the option ProxyPreserveHost On. When forwarding with AJP, the host is automatically forwarded. Other WAF/Proxy configurations - of course - differ. But the proper way to generate the URL is to let the generating server know what URLs it should generate.
If you need to worry about the proper host name, you'll need to do so by request: Liferay is well able to use Virtual Host names to distinguish between different sites - and if they're completely different, you might be signed in to one of them, but not to the other. This has a repercussion on the permissions.
Have the infrastructure handle it for you. Don't write code (or application configuration) for it.
I'm moving from Apache on Linux to Azure Web Apps and I have a specific url (mysite.com/blog and everything under it) that is configured with a reverse proxy so the end user doesn't know that the content is actually coming from another service.
I'm sure I can do this within Web Apps (which runs on IIS) but I can't find any documentation on how to do this. As a backup I'm open to putting another service in front of my Web App.
How can I accomplish this in Azure?
Update: I did try using another service - Functions. My architecture looks like this:
This works in production but I'm hitting snags in development. /blog may or may not work depending on the entry point. In prod, our DNS will be configured so mysite.com points to mysite-proxy.azurewebsites.net and, therefore, any URI the user hits will work. In dev, however, we may want to browse to hit /blog from the Traffic Manager which will route us to /blog on the webapp which doesn't exist. Same problem, of course, if we go to /blog directly on the webapp. I tried to show these examples on the right side of the diagram.
I would like to find a solution so the webapp itself can handle the /blog proxying and then we can determine whether it's worth the speed and cost tradeoff compared to the existing solution.
You might want to checkout Azure Functions Proxies: https://learn.microsoft.com/en-us/azure/azure-functions/functions-proxies
Sounds like you want an Application Gateway (caution, costs like $15/day)
The AGW can have multiple listeners against multiple hostnames, including path-based routing.
You will want to add two backends, one for the /blog endpoint and one for the non-/blog stuff. The backends just take the IP or FQDN of the target resource, in this case you will have:
blogBackend: myblog.com
defaultBackend: myWebapp.azurewebsites.net
Then you need to add listeners for your public-facing domain, it would be like:
myHttpListener: port 80, hostname=mywebsite.net
myHttpsListener: port 443, hostname=mywebsite.net
Then you need an HTTP setting
myHttpSetting: protocol=HTTPS, port=443, useWellKnownCACert=Yes, HostnameOverride=Yes,pick from backend target
Then you need rules, one for http=>https redirect, and the other for handling the pathing
myRedirectRule: type=basic, listener=myHttpListener, backendtargettype=redirection, targettype=listener, target=myHttpsListener
myRoutingRule: type=path-based, listener=myHttpsListener, targettype=backendpool, target=defaultBackend, httpSetting=myHttpSetting, pathRules=
path=/* name=root backendpool=defaultBackend
path=/blog name=blog backendpool=blogBackend
You can create additional http settings and assign them to the path rules to change the behaviour of the reverse proxy. For example, you can have the user's URL be https://mywebsite.net/blog, but have the path stripped on the request to the blog so the request looks like myblog.com instead of myblog.com/blog
There's a lot of tiny parts, but the app gateways can handle multiple applications at scale. Biggest thing is to watch out for the cost since this is more of an enterprise solution.
Here's the situation. Website.com is an ASP site which needs a blog that is to be Wordpress. So the website.com/blog needs to be hosted onto a php-friendly server. The company hosting the ASP site doesn't want to have anything to do with Wordpress so we have to use some of the shared hosting providers.
How do I have the Blog section placed onto an entirely different server? I've heard this is done with CNAME, but I've never used it. Most of the research I've done revolves around subdomains, but I need a subfolder mapping, and there's not much to read about putting subfolders onto different servers with a different IP and everything.
Thanks.
There are a few different options:
you can bring the traffic to your own server and then redirect to
the correct location
you can bring the traffic to your own server and then proxy it to the correct location
you can direct the traffic to the correct location either via full page or an IFRAME type mechanism
Each option has some benefits and drawbacks depending your devs knowledge level and your infrastructure. Regarding subdomains, you could use a combination approach where you, for example, use subdomain.yourdomain.com to point to a server instance (can be the same server or a totally different one) that maps the subdomain.yourdomain.com name to a specific path, usually via Host header.
A CNAME is a function in DNS that says "Whatever thing you wanted to find for this name, use the same thing for that other name instead". When you're working with web stuff the "thing" in there is nearly always an IP address.
That is, what a CNAME can do for you is to say that when a user's web browser tries to look up the IP address for website.com, it will use the IP address for someotherwebsite.com. Note the total absence of anything web-related, like subfolders, in this. CNAMEs work on whole domain names, nothing else. Since you want to serve only a part of the stuff at a particular name from another server, CNAME cannot help you. CNAME is the wrong tool for you problem. Do not taunt happy fun CNAME.
In order to serve website.com/blog from another server than website.com, you pretty much have to do some sort of reverse proxying (where the ASP site's server relays requests between the user and the Wordpress server). It's probably easier and more robust to give the Wordpress site its own name (blog.website.com or something), and redirect to that from website.com/blog, but only you can know if that's politically possible in your case.
Our company has two sites
www.mysite.com -- Wordpress site
www.mysite.com/portal -- asp.net mvc site
We want to move the wordpress site (www.mysite.com) to Azure and the other site stays local. We need to url stay the same. How can we achieve this?
Since you state that you need the URL to stay the same, this can be achieved through a reverse proxy. You would set up a web server (typically nginx or IIS) answering on www.mysite.com.
This web server would have reverse proxy rules to forward requests for /portal to your on-premises server (in a given, non-public IP and port) and all other requests to another web server running WordPress (on the same server/cluster that runs the reverse proxy, or a separate one), also with a given IP and port.
All user requests, then, would reach the reverse proxy, that would serve them from cache if possible, or forward them to the internal web servers, and send the response back to the user, transparently. Notice that this is an internal operation, not a redirect response.
Although this setup is more complex than the simpler solution of using different subdomains (www.mysite.com for website and portal.mysite.com for application), it comes with certain advantages that are described in the referenced Wikipedia article, such as security and acceleration.
Alternatively you could create separate subdomains as described above, and use a redirect rule to redirect requests for www.mysite.com/portal/x to portal.mysite.com/x. In this case, the user would see the updated URL in their browser, but the old ones would still work.
I have a site that lets people have their own e-stores, for ex- mysite.com/clientname
What I want is, if somebody opens store.clientname.com or clientname.com/store, the content is pulled from mysite.com/clientname. [ So that their users feel that they are browsing on their site ]
I know this is possible because site'e like tumblr let you do that by changing a CNAME entry for your domain to their IP address.
I do have a dedicated IP address.
Also, can this be done by editing the .htaccess file at clientname.com, and if yes, which method is better/easy?
You'll want to solve the problem in a completely different way for http://store.clientname.com/ versus http://clientname.com/store.
In the first case, you can serve the web site as a virtual host. Just set up a virtual host called store.clientname.com and set its DocumentRoot to be the existing directory that contains the files for http://mysite.com/clientname. If you have other web server configuration directives that apply to http://mysite.com/clientname then you'll also want to apply those in the virtual host. Finally, the client can set up a CNAME record in DNS for store.clientname.com pointing to your web server.
If you are using Apache, you can also use a default virtual host and mod_rewrite to dynamically translate URLs of the form http://store.{whatever}/ to http://mysite.com/{whatever}/. However, this won't work if you are using HTTPS.
In the second case, you don't want to serve the web site at http://clientname.com/ because the client presumably is already hosting that and presumably http://clientname.com/otherstuff has to continue working and come from their server. So the second case is easier for you because all the work has to be done on the client's web server. But it's simple: they will just have to configure their web server to proxy http://clientname.com/store to http://mysite.com/clientname.