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.
Related
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.
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?
We have a domain name with DNS management facility. We also have a web application developed in a GlassFish server hosted in a virtual server with a path is
http://198.98.103.233:8080/pemis/
I want to direct to the home page of that application when some one type the domain name. After navigating through the pages, we must be able to see
http://www.pemis.lk/faces/public.xhtml
in the browser rather than
http://198.98.103.233:8080/pemis/faces/public.xhtml
How can we configure that.
Thanks in advance.
You need to install your application as the root application in Glassfish, as explained here. But it's not hard:
asadmin deploy --contextroot "/" your-webapp.war
or set the context-root property in the sun-web.xml or glassfish-web.xml depending on the version of Glassfish you use.
To change the port Glassfish listens on you need to modify the HTTP Listener configuration. On default installations you'll want to change http-listener-1's port. You can do so using the console. But you can also directly edit the domain's domain.xml:
<network-listeners>
<network-listener port="80" protocol="http-listener-1" transport="tcp" name="http-listener-1" thread-pool="http-thread-pool"></network-listener>
...
</network-listeners>
Last, to make www.pemis.lk point to that server you need a DNS entry that points to the address the server is attached to. The details of how to do that depend on the comapny that sold you the domain, quite often they have online tools that allow you to enter or modify the name-address mapping. In case of doubt it's best to contact them by phone or mail.
I'm on the same path and, as you don't posted the solution that you found (if you found it), I'll add here some future reference for anyone facing this problem.
I'll break the question in two parts: Eliminating host:port and changing how the URL behave.
I don't have a complete response to the first, however if you chose to listen at port 80, by HTML standard, you will supress the port on the URL, getting half the solution you want.
The second part, changing the URL behavior and/or shortening it can be achieved by either using mod_rewrite in apache or Tuckey's URL Rewrite Filter (http://www.tuckey.org/urlrewrite/). A google search using URL Rewrite can achieve you a more in depth explanation and there's a guide on the website.
You should, however, update your question with an answer, if you found one.
Background context: ASP.NET / IIS (not sure if it matters)
I have a web app at example.com, and a user of my app gets his own content page at an address like example.com/abc-trinkets. I would like to offer the user the ability to point his own registered domain at my web app so his content is accessed at abctrinkets.com. Initially looking on the order of 10-100 users with custom domains.
Ideally, I would like my user to just have a single hostname or IP address that he needs to know to configure properly with his registrar, and if I change the setup of my servers (different host, change addresses, load balancing, etc.) the user will not have to change his settings.
I have no trouble handling the requests once they hit my web app, but I am looking for input on the best way to set the routing up so requests actually come to my app/server. I would like a "catch-all" type of behavior that does not require me to individually configure anything for each domain a user might point to me.
I assume I will need some kind of layer between the address I give my user and my actual server ... is this like a managed DNS service or some other type of nameserver thing I would set up with my host? Is this something simple that should already be handled by a few simple settings on my webserver? I worry that I am making this more complicated than it needs to be.
Write a script that examines the Host header in the request. In your example, if it's abctrinkets.com, then you'd either redirect or forward the request to /abc-trinkets. You'd still need a database or something for mapping the domain names to the URLs; if you're going to allow arbitrary domain names for each user account, then there's no possible way to avoid that.
a mirroring CDN can't have the same hostname as you application server, because you need a way for the CDN to explicitly reference the application.
Why, in general, do sites like facebook run their CDN on a totally seperate host, not just a subdomain like cdn.facebook.com? example: http://profile.ak.fbcdn.net/hprofile-ak-snc4/173706_6103645_790537_q.jpg
Is the reason, that they can construct resource URLs with many different hostnames, to avoid the 4-connections-per-host limit on some browsers?
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies.
From: http://developer.yahoo.com/performance/rules.html#cookie_free
Because user generated content can contain nasties that may be able to access data hosted on the primary domain.
It also stops things like cookies and authentication getting sent in the request to CDN content.
Preventing users from inserting
scripts, and at the same time allowing
user submitted html is extremely
difficult to do on the server side -
ergo we must have sandboxing.
Borrowed from a fairly old whatwg post