I know if you make a ajax call from example.com to yahoo.com, it is a cross domain call. But I'm not sure about the followings situations.
1) One web application in IIS with domain name "www.test.com" and I also host a web service in IIS with domain name "api.test.com". Now if I make a ajax call from "www.test.com" to "api.test.com", will this be considered as a cross domain call?
2) Same as case 1 but if I host web application ("www.test.com") on a windows server and if I host host web Service ("api.test.com") in a Linux server, and now if I make a ajax call from "www.test.com" to "api.test.com", will this be considered as a cross domain call?
You can not do cross domain calls using javascript. This also includes calls between subdomains.
However getting a work around to make call to a subdomain easy. You need to set same document.domain in both the pages. You can read more about it here A question about cross-domain (subdomain) ajax request
Update:
Forgot to mention that cross domains are independent of backend server serving your requests. So it doesn't matter if server is IIS or Linux, it is all same.
Related
I've been trying out Application Gateway, and have managed to get to the point where hosting 2 applications in different pools, albeit with same port is possible using the "host" header to choose where i intended to be directed.
However, what i actually intended to do was route subdomains to certain applications.
For example, my application gateway is "app-gw.example.com", and i have 2 Azure Functions sat behind that, for simplicity, func1.example.com and func2.example.com. (They actually have distinct domains themselves, not subdomains).
I would like to route "func1.app-gw.example.com"'s traffic to func1.example.com, and "func2.app-gw.example.com" to "func2.example.com".
However, i can't seem to figure this out. Can someone explain how this can be done?
I've had also some success hosting on different ports and using the listener + routes to direct to each individual site, but they should rather be on the same port, which rules this out.
I've also tried messing with URL Rewrites, but wasn't able to get something useful from that either.
EDIT: I think maybe i'm missing something here. Perhaps i need something that points the domain names to the application gateway, and then route on that? For example:
Site 1, reachable at func1.example.com may have an entry called "func1-gw.example.com", which actually just points to the application gateway, however, the application gateway now knows that it's really supposed to be going to "func1"?
Sounds like a DNS record pointing to the gateway may work, but then i wonder how to do the routing, hmm.
Thanks.
As you are already aware of Application Gateway multiple site hosting, you can enhance the Application Gateway to route the traffic based on the URLs.
Below references might help you configure the URL based routing.
URL Path Based Routing
Application Gateway redirection
Configure URL redirection on an application gateway
in our company we need to implement a self hosted Rest Service that has to be deployed in the client workstations in order for our internal web applications to interact with them.
The web applications are in https, and we are not using, at the moment, the CSP headers.
Our concern is whether it's necessary to call the local service also in https or this can ne avoided (and so we can avoid to manage a certificate to deploy in every single workstation).
We made some trials with Chrome and Edge and it seems that the ajax calls are working also in plain http, but we would like to know if that is actually supported or not. Our internal web applications are not using, at the moment, the Content Security Policy headers.
Thank you!
On an HTTPS connection browsers will block HTTP content as mixed content, CSP will not change that. However, Chrome will allow mixed content on http://127.0.0.1 and http://localhost while Firefox will allow it on http://127.0.0.1, see note on https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content.
When you implement CSP you should include http://127.0.0.1 (or http://localhost) for the appropriate directive.
I have a MEAN app which responds to multiple domains. Domains are pointed to same IP and port.
Is there a way to get domain name from client request, without express.js?
So that I can load different database based on request domain name. I tried using process.domain and os.hostname which does not work on Windows OS (not sure about other OS).
Try picking it out from the header:
request.headers.host
Here's the basic situation:
I have an application on AWS which needs to serve assets to and create 'share' links for content hosted on my AWS servers. I need to figure out a way to still use the URL/domain from another clients infrastructure, so it will essentially whitelabel our application as coming from their services. I was thinking of using Route53 and a CNAME, but things like the dynamic 'share' urls will create a huge problem for redirects. Does anybody have any ideas on how this could be accomplished?
I think that you will have to set up your server at the "whitelabeling" location to have a web server that can call the other URLs and return their content. Ie, you create a server that responds at whitelabel.com, which then calls myAWS.com and passes the result back to whoever called whitelabel.com. You could make this flexible by allowing whatever the end destination URL needs to be to be passed in as a parameter (so, if you call whitelabel.com/foo, it will call myAWS.com/foo), though this has some security ramifications, and also requires a lot of knowledge by the consumer of exactly where things will reside.
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.